Усталость проекта.

Проекты разработки ПО имеют неприятную тенденцию разваливаться со временем. Тут уж ничего не поделаешь – тенденция объективная. Не даром для обозначения этой тенденции используют термин «энтропия» - необратимое и неодолимое рассеяние энергии. Чем дольше длится проект, тем сложнее поддерживать его в тонусе. В проекте накапливается усталость. Это касается как психологических аспектов (усталость команды), так и технических (возрастает доля времени, затрачиваемого на рефакторинг и устранение ошибок), и наконец просто системных - возрастает сложность системы.
Хорошо если проект успевает закончиться до того, как его усталость достигнет критического уровня (не важно с каким результатом). А если нет, если проект достаточно продолжительный? Чаще всего, накопив критическую усталость, проект разваливается. Иногда он рушится с громом и пылью, погребая под своими обломками менеджера, а команда стремительно разбегается, куда глаза глядят. Но гораздо чаще наступает тихая смерть. Проект вроде бы продолжает существовать, но уже как зомби. Команда отчаянно сражается с проблемами, которые растут как снежный ком, но становится все хуже и хуже. Все начинают тихо ненавидеть друг друга, никто уже не понимает, как работает «эта чертова система» («неужели это все мы написали!»). Я не хочу расписывать то, что поддерживает на плаву проекты–зомби, потому что существует и третий сценарий.
Третий сценарий - это когда команде удается найти такие механизмы, позволяющие успешно противостоять проектной энтропии. Такие случаи есть, и когда это случается проект переходит в «промышленный режим» разработки, в котором он может жить годами. Команда продолжает клепать релиз за релизом, без революций и переворотов. Это продолжается, даже если из команды уходят герои одиночки, для которых стиль работы - “mission impossible”.
Как же пережить «критические дни»? По большому счету любая методология, будь то RUP, Agile или XP направлена именно на то, чтобы противостоять энтропии проекта. Но проекты с одинаковым успехом разваливаются под любой методологией (правда, проекты без всякой методологии, все же разваливаются быстрее всех). Но все-таки есть средства, которые действуют против усталости проекта наиболее эффективно. Некоторые из них до смешного просты.
Например, ежедневные короткие митинги (совещания) проектной команды. Эта практика есть в XP и Scrum. Я видел проекты на RUP и MSF, где она успешно прижилась. Надо только придерживаться нескольких простых правил. Митинг должен быть действительно коротким, не более 30 минут. Должен быть ведущий, не обязательно это должен быть менеджер проекта, но кто-то должен следить за соблюдением правил. Каждый должен отчитаться о том, что он сделал вчера. Любая возникшая вчера проблема должна быть обсуждена. Каждый должен получить задание на сегодня (тут зависит от методологии, например, в Agile и XP разработчики сами выбирают себе задачи). Такие митинги очень хорошо поддерживают тонус проекта. Я не знаю точно почему, вероятно дело в психологии. Каждый разработчик знает, что завтра ему надо отчитаться перед командой. С другой стороны он всегда уверен, что не никогда останется один на один внезапно возникшей проблемой. Ежедневные митинги - это пульс проекта.
Постоянная интеграция – это вторая непреходящая ценность, почитаемая адептами всех религий методологий без исключения. Интеграция включает в себя сборку новой версии системы и развертывание ее на тестовом окружении. Но с этой практикой сложнее, чем с предыдущей. Дело в том, что со временем сложность разрабатываемой системы растет, в интеграцию включаются все новые аспекты и соответственно усложняется процесс интеграции. Он требует все больших и больших затрат, а поэтому возникает соблазн проводить интеграцию все реже и реже. Редкие интеграции приводят к тому, что между ними накапливается много изменений, и их становится труднее интегрировать в систему. Возникает порочный круг. Если вы хотите удержать проект от развала вы должны во чтобы-то ни стало поддерживать частую или непрерывную интеграцию. MSF и XP рекомендуют проводить интеграции не реже одного раза в день. Не имеет значения выполняете вы интеграцию в ручную или автоматически. Гораздо важнее то, что процедура интеграции должна быть ясной, четкой и по возможности простой. Плохо, когда знание о процедуре интеграции становится «сакральным» и замыкается на одном члене команды (если, конечно, он не выделенный конфигурационный инженер). Хорошо если интеграцию умеет выполнять любой член команды (как того требует XP).
Модульные тесты (unit tests) я, пожалуй, поставлю на третье место. Если в вашем проекте третью неделю на сборке не проходят модульные тесты, или их вообще выкинули из сборочного скрипта – значит ваш проект начинает разваливаться. Если модульных тестов у вас не было с самого начала – проект, вероятно, не стоило начинать. По моим наблюдениям, после полугода у половины проектов модульные тесты начинают, что называется, хромать. Причины этого - возрастающая сложность и обыкновенная лень. Чем дольше система, тем сложнее писать тесты. Чтобы протестировать класс бизнес логики надо подготовить тестовые данные в БД или написать целую кучу заглушек и мок объектов. Когда объем тестов начинает превышать объем основного кода – это начинает напрягать практически любого программиста. Наконец наступает момент, когда лень берет верх над здравым смыслом, сначала перестают писать новые тесты, потом - поддерживать уже написанные. Все, после этого остается одна надежда на тестировщиков, и на то что, в очередном билде они проведут полное регрессивное тестирование и ничего не пропустят.
Четвертым номером идет дизайн. Грамотно спроектированная система намного лучше противостоит проектной энтропии. Недостаточное внимание к дизайну, слабая сторона многих методологий. Я говорю здесь не об ошибках в проектировании и архитектуре, а именно об отсутствии элементарных общих подходов к построению приложения. Представьте себе систему, в которой настройки хранятся в трех разных местах, а чтение этих настроек выполняется четырьмя разными способами. А если то же самое творится с доступом к данным и бизнес логикой? А если эта система уже в эксплуатации и вам приходится постоянно вносить в нее изменения? Это сущая каторга. А начиналось как обычно все красиво, с энтузиазмом, в стиле XP или чего-то еще в этом роде... В общем, не стоит пренебрегать дизайном.
Бороться с усталостью проекта можно и нужно. И не важно, по какой методологии разрабатывается ваш проект, поддерживайте его тонус, и будет вам удача.