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