Несколько разработчиков и я недавно присоединились к водопадному проекту. Нам сказали, что проект почти готов, но нужно еще несколько программистов, чтобы закончить его (это первая ошибка). Нам всем были назначены разные модули для работы.
Этот этап проекта стал более гибким, поскольку мы каждую ночь выполняли сборки и развертывания в тестовой среде, а команда контроля качества активно тестировала и сообщала об ошибках. Время от времени наши регрессионные тесты новых модулей давали сбой — то, что раньше работало, больше не работало. Мы обнаружили, что были внесены изменения в дизайн, которые затрагивали только разработчика, работающего над модулем, архитектора и проектировщика. Проблема была в том, что это затронуло модули других разработчиков.
Разработчики разочаровались друг в друге, прося сообщать им об изменениях дизайна, потому что это может повлиять на их работу.
Как лучше всего сообщить о дизайнерских решениях, которые могут быть приняты в ходе разговора в коридоре или по электронной почте между несколькими сторонами. Должен ли существовать формальный процесс обработки проектных изменений, даже если они очень незначительны?
Если вам нужно действовать быстро, внося изменения, которые могут затронуть других, то, возможно, вы сможете найти способ изолировать других от ваших изменений, например, с помощью интерфейсов, фасадов или адаптеров.
Другие варианты включают (1) изучение того, как вносить соответствующие изменения, которые могут потребоваться «другим», и либо отправку им исправлений, либо внесение изменений для них, (2) уведомление их перед тем, как вы зафиксируете свои изменения, и запрос «других для экстренной проверки, (3) приглашение «другого» поработать с вами, когда вы чувствуете, что ваша работа повлияет на его модуль.
Я предполагаю, что вы могли бы найти другие подходы, но каждый из них будет работать.
Я бы рекомендовал построить дополнительный цикл
прежде чем приступить к другим изменениям в дизайне или разработке.
Это может быть отдельная веха (полный дизайн) или встроенная в каждую итерацию.
Документируйте свои проектные решения с помощью модульных тестов и начните использовать непрерывную интеграцию . Вам больше не нужно будет говорить о дизайне — вы увидите его в действии.
Возможно, это просто то, как вы это сформулировали, но я бы сказал, что изменения дизайна не являются незначительными, если они нарушают работу модулей других разработчиков.
Если вы не хотите прибегать к формальным формам и заранее проверять каждое изменение, ваши разработчики должны иметь достаточно знаний об общей структуре, чтобы оценить влияние любых изменений и при необходимости привлечь другие команды. Вы упомянули архитекторов — они должны быть идеально подготовлены для этого, так почему же этого не происходит?
Я бы также предложил некоторую форму центрального журнала изменений (ваш инструмент SCM может дать вам это), чтобы, если критические изменения все еще происходят, у вас было больше шансов понять, как они произошли.
Наконец, если есть несколько областей системы, которые можно изменить, не затрагивая других, у вас может быть более серьезная проблема с дизайном.
Я не эксперт по Agile, но я вижу в этом коммуникативную проблему, которая применима к любой методологии. Поможет ли это командам ежедневно встречаться для быстрого обзора изменений, прежде чем они начнут работать? Потом снова в конце смены?
Райкорнелл