Когда команда, разрабатывающая новый функционал, приступает к его реализации, жизненный цикл выглядит так:
- Команда создает новый бранч на основе главного бранча исходников для изолирования выполняемых изменений. Таким образом новая работа не смешивается с существующей, а также изолируется от изменений, вносимых другими командами.
- Поскольку работа ведется над новой функциональностью, разработчики имеют две важные контрольные точки. Эти точки нужны для управления проектом, чтобы быть уверенным, что менеджмент не только в курсе выполняемой работы, но и способен передавать информацию выше по иерархии. Контрольная точка №1 касается дизайна: команда показывает как она собирается решать конкретную проблему.
- Контрольная точка №2 касается реализации функционала. Здесь команда демонстрирует что фактически было сделано для решения проблемы.
- Как только заканчивается выполнение заявленного функционала, команда интегрирует все изменения из главного бранча в их собственную ветку.
- Перед тем, как они «закачают» свои изменения в основной бранч, команда должна встретиться и обсудить качественные характеристики. Такими характеристиками могут быть «Без падения производительности» и «70% кода должно покрываться автоматизированным тестированием».
- После того, как команда убедиться, что они достигли установленных характеристик качества, они могут «залить» свои изменения в основную ветку. Качественные характеристики защищают основной код, гарантируя, что он всегда находится в состоянии наивысшей готовности.
ЗАМЕЧАНИЕ: цель — завершить заданный функционал в 4-6 недель (что не всегда удается, но, тем не менее, необходимо выдерживать этот срок как можно более точно).
Мы использовали 16 различных требований к качеству, которые мы должны были выполнить прежде, чем сказать «Готово». Некоторые из важнейших перечислены ниже:
Задание требований к качеству — метод, которым мы пользуемся, когда более 3,000 человек работает над более, чем 700 новыми функциями в базовом коде, насчитывающем *арды строк (я не знаю действительный размер, но вы можете представить сами)… это — все, что мы можем сделать, чтобы децентрализованная работа выполнялась с требуемым качеством.
Пока все команды выполняли собственные задания, все подразделение в целом занималось управлением итерациями. Насколько я помню, там было около 14 итераций. На картинке ниже изображен бранч для нового функционала, выделенный из основной ветки, который в последствии был интегрирован обратно. Команды разработки перекрывают друг друга, как и итерации.
На уровне подразделения мы выполняли интеграционные ревью, на которых все команды докладывали вышестоящему начальству что они планируют выполнить в следующей итерации и что реально было сделано в прошедшей.
Следующая глава: реализация процесса с использованием TFS.