Управление изменениями
Учет изменений жизненно необходим, однако наличие хорошей системы трассировки ошибок не означает, что разработчики могут произвольно изменять главные исходные файлы. Такой карт-бланш сделал бы весь учет бессмысленным. Идея состоит в том, чтобы управлять изменениями периода разработки, ограничиваясь лишь определенными типами изменений в некоторых стадиях проектирования, так чтобы можно было ежедневно оценивать состояние главных исходных файлов. Лучшая идея управления изменениями, о которой я когда-либо слышал, принадлежит моему другу Стиву Маньяну (Steve Munyan) и заключается в том, что вся разработка разделяется на три периода. В первом, который Стив назвал зеленым, допускаются любые изменения в главных исходных файлах ("горит зеленый свет"). Самые ранние части проекта обычно создаются именно в этот период, когда команда работает над новыми свойствами.
Второй период — желтый — наступает, когда продукт находится на этапе исправления ошибок или приближается к "замораживанию" кода. Допускаются только изменения, связанные с исправлением ошибок. Добавление новых свойств или другие изменения не разрешаются. Перед регистрацией исправления ошибки ее должен одобрить технический руководитель или менеджер разработки. Разработчик, выполняющий исправление ошибки, должен описать как сам процесс исправления, так и то, на что он влияет. По существу, этот процесс является мини-обзором кода для каждого отдельного исправления ошибки. В некоторых командах, где я работал, "желтый" период начинался с первого дня, потому что разработчикам нравилось составлять обзоры кода на этой стадии. Одобрять изменения мог любой другой разработчик. Такой подход позволял отлавливать массу ошибок прежде, чем окончательно формировался код главных исходных файлов.
На последнем этапе загорается красный свет, начинается этап замораживания кода и для любого изменения кода требуется одобрение менеджера разработки. Будучи таким менеджером, я даже ужесточил ограничение, разрешив доступ "только для чтения" (read-only) к файлам, составляющим проект. На этом этапе разработчики думают: "Это всего лишь маленькое изменение, которое исправляет ошибку и ничему не повредит". Благое намерение может заставить целую команду возобновить тестирование с самого начала.
Руководитель проекта должен неукоснительно проводить в жизнь ограничения этого этапа. Если продукт имеет воспроизводимый аварийный отказ или в нем происходит разрушение данных, решение о внесении изменений принимается, по существу, автоматически. В большинстве случаев, однако, необходимость исправления специфической ошибки менее очевидна. Для того чтобы в этой ситуации принять правильное решение, необходимо, по моему мнению, ответить на следующие вопросы:
- Сколько людей затрагивает эта проблема?
- Вносятся изменения в ядро или в периферийную часть продукта?
- Какие части приложения потребуется повторно протестировать?
