Четыре способа взаимодействия Agile команды и Waterfall команды

Published by Асхат Уразбаев, June 4th, 2016

Нет повести полней печали

Чем пост о водопаде и аджайле (С) мое

При Agile-трансформации компании у вас неизбежно какое-то время одновременно существуют agile-команды и водопадные команды. Допустим, есть какая-то фича, требующая совместного участия обеих команд. Как им взаимодействовать? Тут начинается боль.

Есть 4 паттерна такого взаимодействия. Боль при этом распределяется неравномерно: все зависит от того, какую из команд вы хотите обидеть больше.

Паттерн первый. Обижаем agile

Agile-команда ставит задачу водопадной в классическом режиме. Пишет бизнес-требования, функциональные требования, добивается включения в следующий релиз, после окончания релиза проходит совместно с ней интеграционное тестирование, затем приемку с заказчиком и наконец совместно выходит в пром.

У Agile команды появляется куча “пользовательских историй” на создание и согласование большого объема документов. Звучит грустно, выполняется с такой же болью.

В чем боль? Чтобы написать требования, нужно их собрать и зафиксировать. Само по себе это проблема для agile-команды, успевшей отвыкнуть от “плохих” привычек. Раз в 2 недели команда проводит демо заказчику и требования начинают меняться. Эти изменения могут задеть и требования для водопадной команды. И тут начинается настоящая боль. Кто-то должен “занырнуть” в водопад и сказать это. Типичный ответ земноводных — в следующем релизе. Бесится заказчик, бесится команда.

Зато для водопадной команды все стандартно и практически без всяких рисков.

Time to market для фичи получается большим, причем вне зависимости от ее размера.

Паттерн второй. Сдвигаем баланс

Agile команда договаривается с водопадом. Из водопада на время релиза выделяется нужное количество инженеров. Можно действовать в стандартном режиме “вот вам тикет с задачей”, но раз уж выделены “ресурсы”, то почему бы этим не воспользоваться?

На время разработки они присоединяются к Agile-команде: ходят на стендапы и демо, участвуют в технических встречах. По окончанию работ инженеры уплывают назад к себе в уютный водопадик. Далее ждем интеграционного тестирования и выходим в пром одновременно.

Нужна совместная тестовая среда на все время разработки. Ну или хотя бы возможность прокрутить дырки друг к другу.

Agile команде немного полегчало. Не нужно писать и фиксировать требования сильно заранее. Обычно создают простой документ в стиле “Подателю сего выдать 3 инженера в таком-то релизе”. Требования можно менять по ходу работ. Разработчики обеих команд приходят на скрамы, можно все решить напрямую, минуя цепочку “разработчик-аналитик-аналитик-разработчик”.

А вот водопадной команде поплохело. Все вопросы мерджа кода на ее стороне. Требования в agile части отсутствуют заранее, после появления могут поменяться. Регулярно прилетают “нежданчики”-изменения и порождают конфликты в коде и логике приложения. Водопадной команде придется научится часто лично общаться (о ужас!) чтобы вовремя решать такие проблемы у себя.

Time to market улучшился — вычеркиваем время создания и согласования требований.

Паттерн третий. Контратака

Стоп, говорим мы. Зачем КАЖДЫЙ релиз создавать документ “Подателю сего выдать 3 инженеров”. Давайте договоримся отсюда и до горизонта. Мы ВСЕГДА будем занимать трех (например) инженеров.

Agile команде совсем лафа. Никакой бюрократии, все те же самые полюбившиеся земноводные Петя, Вася и Коля ходят нам на скрамы, общаются на демо с заказчиком. Еще чуть-чуть и у них атрофируются жабры.

Вот бы еще и релизиться почаще…

Паттерн четвертый. Печалька для водопада

Нет, релизить чаще нельзя, утверждает ваша водопадная команда. Не лукавство ли это?

Приглядитесь внимательно: Мимо кассы в пром регулярно проскакивают следующие льготные категории тикетов:

• Дефекты в продуктиве.
• Часть срочных “регуляторных” тикетов — “нежданчики” от государства.
• Тикеты от высокого руководства сверхвысокого приоритета. В русском языке они называются “Умри, Но Сделай”, в английском JFDI (Just Fucking Do It).

Давайте просто добавим сюда еще один вид тикетов:

• Тикеты от agile команд. Релизим их сразу, после быстрого ограниченного регресионного тестирования.

Agile-команде совсем хорошо. Проблем практически нет.

Что происходит с водопадом?

По-сути, их работы делятся на 2 стрима — быстрый и долгий. Быстрый генерит код, выходит с ним часто в пром. Долгий стрим страдает из-за быстрого. От них прилетает код, его нужно регулярно мерджить к себе. Логика приложения также плывет. Приходится проводить стендапы, общаться регулярно, совместно планировать.

Их боль — регресс. Полностью его для каждого частого релиза не прогнать, слишком много ручной работы. Приходится приоритезировать и нести соотвествующие риски. Ситуацию немного улучшает то, что релизы по объему небольшие и обозримые. Но в общем, будет иногда постреливать.

Зато Time to market хороший!

Tags: agile, waterfall