Мы начали говорить про Scaled Agile Framework, гибкий фреймворк, который позволяет использовать agile-методологии в больших командах разработки.
Существует два типа внедрения фреймворка: трехуровневый и четырехуровневый. В командах меньшего размера (примерно 50-125 человек) используется трехуровневый фреймворк, который включает уровни портфолио, команд и программ. Для команд, состоящих из сотен специалистов, применяется четырехуровневый SAFe, который также включает уровень «поток ценности» (от англ. Value Stream).
Наша команда имеет опыт работы с тремя уровнями safe. Про них и будем говорить.
Уровень портфолио
Начнем с уровня портфолио. На данном уровне руководство предприятия обсуждает бюджет, решает, какие направления в приоритете в данный момент, распределяет инвестиции. На уровне портфолио создается бэклог с бизнес-эпиками, о которых мы говорили в прошлый раз. Поскольку тестировщики и разработчики не работают на этом уровне, останавливаться на нем подробно не имеет смысла.
Уровень команд
На уровне команд мы имеем дело со стандартным Scrum’ом, который многим из нас знаком. Есть бэклог, состоящий из пользовательских историй (user stories). В рамках планирования команды набирают user stories, встречаются на ежедневных митингах. В конце двухнедельного спринта команды собираются на ревью, или демо, и демонстрируют объем работающего ПО, который может быть интегрирован с текущим решением на продуктивной платформе.
В конце итерации проводится ретроспектива, на которой команда обсуждает, что прошло хорошо, что не очень, что можно улучшить. Разработчики и тестировщики работают вместе и каждые две недели доставляют определенный кусок работающего ПО. Стоит отметить, что длина спринта ограничена двумя неделями.
Уровень программ
На этом уровне находятся главные отличия SAFe от Scrum. Мы имеем команду гораздо большего размера, нежели в Scrum. Команда состоит из N-ного количества обычных спринтовых команд, работающих над доставкой ПО. Команда в SAFe называется «Team of Teams» и может состоять из 50-125 человек.
Все участники на уровне программ работают над продуктом, который по итогу можно выпускать на рынок. Нужно понимать, что готовность к релизу будет определяться не ценностью для пользователя, а качеством ПО, то есть полным отсутствием дефектов. В SAFe этот кусок ПО называется Potentially Shippable Increment (PSI), и работа над ним длится 5 спринтов.
С каждым новым PSI в продукт добавляются новые фичи. Процесс прироста бизнес-ценности продукта называется «релизный поезд Agile» (от англ. Agile Release Train). Это, пожалуй, одно из ключевых понятий SAFe. Чем больше в организации продуктов, тем больше будет релизных поездов. К слову, у нас на проекте только 1 Agile Release Train. Почему именно поезд? Сейчас поясним.
Представьте себя в роли заказчика. Перед вами стоит задача добраться из Минска в Москву. Вы предпочитаете самолет поезду или автомобилю. Однако вы сталкиваетесь с рядом ограничений и рисков. Вы вынуждены выбирать из предлагаемых дат и подстраивать под них свое расписание. Вам нужно заранее купить билет, зарезервировать место. И даже если вы сами все сделали в срок, существует ряд рисков, которые от вас никак не зависят: рейс могут задержать, багаж может потеряться.
На преодоление этих непредвиденных обстоятельств уйдет время. Поэтому вы не можете быть заранее уверены в том, что все пройдет, как вы запланировали. Схожее чувство испытывают заказчики, работая по итеративной модели.
Теперь представим иную ситуацию: вам нужно добраться с одной конечной станции метро до другой. Вы спускаетесь в подземку, покупаете билет и спускаетесь на платформу. Заранее ничего делать не нужно. Вы знаете, что будете на нужной станции в нужное вам время, потому что поезда приходят часто, с регулярной периодичностью. Пропустив один поезд, вы сможете сесть в следующий, который придет через несколько минут.
Последний пример наглядно иллюстрирует то, как действуют релизные поезда в SAFe.
Поскольку они ходят постоянно (циклы в 5 спринтов), всегда легко объяснить заинтересованным лицам из руководства (stakeholder’ам), что фичи, которые не попали в текущий поезд, попадут в следующий.
Цикл разработки уменьшается, а сам процесс становится более предсказуемым. Заказчик спокоен и доволен. Он знает, что срок релиза не сорвется, а конечный продукт будет представлять собой то, что было запланировано.
Сейчас настал момент объяснить, что разработка одного и того же программного продукта несколькими независимыми командами по Scrum и в SAFe – это не одно и то же.
Перечень всех
услуг представлен на страницах нашего сайта.
