«Трусливая» разработка

Я называю трусливой разработкой состояние проекта, когда некоторые (или все) члены команды избегают вносить изменения в исходный код или конфигурационные файлы.
Такое бывает на завершающих стадиях проекта, когда получена некая относительно работоспособная версия сиситемы. В этот момент аналитик или менеджер приходит к разработчикам и просит внести не очень большое изменение в функциональность. В ответ ему говорят, что "лучше мы ничего не будем трогать, чтобы не сломать". Услышать такие слова перед выпуском релиза - это нормально. Действительно, внесение изменений изменит скоуп (scope) релиза и отодвинет его дату, а все уже хотят поскорей его сдать. Но если такое происходит в начае релиза - это повод задуматься: а владеют ли разработчики кодом в полном объеме?

Разве разработчик может не владеть кодом, спросит начинающий менеджер проекта? Ответ: Да. И дело здесь не в профессионализме разработчиков. Причины могут быть различны, например:

• Отсутствие понимания у разработчика общей картины поведения системы. Невозможность предсказать изменения и оценить "размер бедствия".
• Опасения разрушить взаимодействия между слабосвязанными компонетами: невозможно сказать, на что повлияет сделанное изменение.
• Новые люди в проекте. Они боятся лезть в чужой код, особенно, если его автор больше не работает над проектом.
• Психологическая усталость: нет драйва затевать большую переделку.
• Противоречия внутри команды: один разработчик отказывается работать с кодом другого разработчика.

Осторожность даже может быть признаком профессионализма и наличия негатовного опыта в прошлом. Вот почему необстреляный солдат так рвется в бой, а ветераны не лезут на рожон. Другими признаками "трусливого" процесса могут быть:

• Саботирование изменений
• Неопреледенные оценки времени со стороны разработчиков: разработчики стараются не предоставлять менеджеру информацию, о сроках разработки. На самоа деле, они не могут даже приблизительно определить эти сроки. Возможно, что какие-то сроки все же будут заявлены, но они будут либо взяты с большим запасом, либо будут не честными и не реальными.

Нужно как можно скорее менять ситуацию, переходя от боязни изменений к готовности вносить изменения. В противном случае теряется мотивация (драйв) команды, наступает застой, продукт перестает развиваться.

Итак, как я предлагаю исправлять ситуацию следующим образом:

1. Автоматизировать процесс сборки, автоматического тестирования и разворачивания системы. Да, бывает, что система "собирается на коленке". Нужно как можно скорей добиться воспроизводимости получения работающей версии системы по исходному коду (см. книжку).
2. Уменьшить скоуп релизов. Перейти на короткие релизы (не более 2-3 недель). Это уменьшит нервозность среди заказчиков, менеджмента да и среди самих разработчиков. Начнет что-то наконец получаться в запланированный срок.
3. Начать вносить небольшие изменения, используя техники рефакторинга (см.Мартин Фаулер "Рефакторинг")
4. Агрессивно использовать TDD - покрывать тестами функциональность, которая подвергнется рефакторингу, чтобы гарантировать её работоспособность после завершения рефакторинга.
5. Если возможно, разделить большое приложение на более мелкие модули с более понятной и простой функциональностью.

При этом нужно быть готовым к потерям времени на рефакторинг.

А что бы вы ещё посоветовали?