Как мы разбили разработку на команды (и забыли про бесконечные спринты и бесполезные стендапы)

Я — PM в сервисе рассылок UniSender ^[1]. 6 лет назад я пришёл программистом, а теперь отвечаю за взаимодействие между командами продукта. Раньше наша разработка состояла из одной распределённой команды и у нас было 2 беды. Но не дураки и дороги, а задержки по спринтам и скучные стендапы на полчаса.

Расскажу, как мы их решили.

Как я уже говорил, у нас было 2 беды:

1. Спринт мог задержаться по вине одной задачи. QA и Dev работали над одним спринтом, скоуп задач фиксировался в начале работы, и вся команда героически бросалась его реализовывать. Иногда прилетали срочные баги, которые шли в «master» хотфиксами. Задачи в спринте могли быть достаточно объёмными. Когда одни задачи уже были готовы к релизу, другие всё ещё были в разработке. В результате команда могла задержать спринт из-за одной задачи.
2. Стендапы занимали много времени и имели сомнительную полезность. Команда росла, стендапы проводились по скайпу, и в начале ничего не предвещало беды. Мы начали подозревать неладное, когда стендапы начали растягиваться на 20-30 минут. Присутствующие не всегда понимали, чем занимаются другие участники команды.

Некоторое время мы жили с этими проблемами, потом пробовали бороться.

• Сокращали стендапы через введение регламента на человека.
• Уменьшали количество присутствующих — на стендапы ходил только тимлид.
• Пробовали недельные спринты.
• Уменьшали количество задач в спринте.

Ожидаемого результата эти попытки не давали. Пришло понимание, что без радикальных изменений не обойтись.

Тут надо пару слов сказать о продукте.

Мы — SaaS-решение, доступное 24/7. Кроме видимой пользователям части — GUI — у нас есть еще большой пласт системной логики, который работает независимо от времени суток или политической ситуации в стране. То есть, разработка и обновление сервиса идет непрерывно, без остановки.

Переход на Kanban

Первая масштабная революция случилась, когда мы поняли: «Scrum нам не подходит».
Решили переходить на Kanban. Мы, конечно, не Toyota и внедрять полную реализацию не стали. Поэтому «наш канбан» будет отличаться от «вашего канбана».

Спринты и работа команд

В двух словах о нашей версии:

• Единицей работы мы считали спринт (завершённый кусок функционала).
• Команду под задачу собирали в зависимости от загрузки и необходимых скилов. В одной команде обычно было до 3 разработчиков и 1 QA. Постоянных команд не было.
• Количество одновременных спринтов стало больше одного.
• Физической доски и других атрибутов Kanban не было, задачи вели через дополнение к Jira.

При этом команда должна была делать спринт от начала и до конца. Это касалось и этапа тестирования: ошибки исправляли те же люди, которые работали над спринтом.

Результат.

• При задержке больших задач не страдали остальные, разработка которых завершилась.
• Уменьшилось количество проблем при деплоях — в одном спринте стало меньше разношёрстных задач.

Стендапы

Стендапы преобразились — на них ходило по одному представителю от каждой команды, которая работала над отдельным спринтом.

Результат.

• Стендапы стали похожи на стендапы и мы снова начали укладываться в эталонные 10-15 минут.

Таким образом мы смогли решить критичные проблемы.

Но… из-за острова начал выплывать весь айсберг!

После перехода на Kanban у нас появилась выделенная frontend-команда, а в backend и продуктовой команде стало больше сотрудников. Взаимодействие между отделами усложнилось — над одним проектом могли работать несколько команд.

Одни проблемы мы решили, но на передний план вышли новые:

• На стендапах участвовали не все — часто приходилось пересказывать информацию команде.
• У одного QA могло быть 2-3 параллельных спринта с разными командами. Приходилось переключаться: вспоминать особенности спринта и постоянно редеплоить код на тестовых окружениях.
• QA были не до конца вовлечены в процесс работы над спринтами. Часто задача доходила до них в конце спринта и требования изучались уже после завершения разработки.
• Команды собирались под проект и их состав часто менялся. Команда из двух разработчиков могла работать над 3 спринтами одновременно: 2 спринта на тесте плюс 1 текущий спринт.
• Было сложно оценить время разработки. Не понятно, сколько времени съест предыдущий незаконченный спринт.

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

В итоге, мы снова начали подозревать, что что-то идет не так. Новой революции быть.

Разделение на команды, новые стендапы, введение Fireteam

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

Не нужно ломать работающую систему, нужно исправлять моменты, которые причиняют боль.

Вот, что мы изменили в процессе разработки.

Спринты

Мы всё ещё оперировали понятием «спринта». Спринт — это «околодвухнедельный» скоуп работ для команды.

В чём плюс. Код не «протухает» и попадает на прод без существенных задержек. Если команда собирается делать спринт за 2 недели — нужно постараться, чтобы затянуть его до месяца.

Что можно улучшить. Часто «промахиваемся» с оценкой и спринты немного затягиваются. Время на работу над некоторыми спринтами изначально тяжело оценить (например, большой рефакторинг). Эту проблему нам предстоит решить.

Разделение на команды

Мы разбили одну большую команду на несколько команд поменьше. В каждую из них входят 2-3 разработчика и один выделенный QA. Сейчас команды стабильны и не меняются от проекта к проекту. Иногда люди переходят между командами для оптимизации составов или добавления требуемой экспертизы в команду. BA участвует в работе команды, но одновременно может вести 2-3 проекта.

Хотя отдыхаем всё равно одной командой)

При этом вся команда работает над одним проектом от начала и до его завершения. Один проект может состоять из нескольких спринтов.

В чём плюс.

• Команды находятся в одном помещении. До этого все сидели по отделам.
• Команда включена в работу над проектом от начала и до конца, что снижает bus-factor.
• Участники команды присутствуют на всех ивентах: ретро, стендапы, пленинги. Все сотрудники в курсе текущих задач.
• Команда больше не работает над чужими спринтами. Теперь всё своё-родное.

Что можно улучшить. Хотелось бы полноценно ввести BA в команды. Это проблематично, потому что ВА обычно приступает к работе раньше остальной команды.

Работа команды

У команды в работе может быть не больше двух спринтов: «тот, который всё ещё на тесте» и «новый, который будем пилить». Как правило, после окончания разработки, все по мере освобождения начинают работу по новому спринту.

В чём плюс. Работа команды стала более предсказуемой, все знакомы с кодом и могут саппортить спринт во время тестирования. Участники стали реже переключаться между задачами, а сам процесс переключения теперь происходит быстрее.

Что можно улучшить. В идеале — у команды должен быть только один спринт в работе. Но пока идеальный мир — не наш мир.

Fireteam

Каждая команда на одну неделю становится избранной. Эта команда реагирует на все внешние раздражители: обращения других отделов, аномальное поведение сервиса, хотфиксы. Мы называем эту команду «Fireteam».

В чём плюс. Fireteam-неделя не засчитывается команде во времени спринта. В перерывах между тушением пожаров сотрудники могут сосредоточиться на своих задачах:

• Провести рефакторинг.
• Доделать задачу по спринту.
• Написать документацию.
• Провести knowledge transfer с другими командами.

Недостаток. В fireteam-неделю жизнь команды очень насыщена событиями. Этих людей любят и знают в лицо все отделы, особенно техподдержка. Приходится постоянно переключаться между разными задачами: дебажить, вычитывать логи, пилить срочные задачи и тушить все пожары. Делать всё это нужно одновременно.

Стендапы

Мы ввели 2 типа стендапов:

1. Командные. В них участвует команда, которая работает над проектом.
2. Общие. Проходят раз в неделю, в них участвуют лиды от каждой команды.

В чём плюс.

• Команда информирована о состоянии дел по спринту.
• Сотрудники в курсе, чем занимаются другие команды.
• Стендапы не превращаются в «скучные мероприятия по чтению с бумажки каких-то наборов цифр». Все присутствующие понимают, о чём идет речь. Стало проще обнаружить проблемные места в работе.
• Стендапы занимают 5-10 минут.

Недостаток. Информацию до команды по прежнему доносит тимлид.

Итог

Таким образом, постепенно изменяя процесс мы решили большинство актуальных проблем:

• Мы собрали стабильные команды из 2-3 разработчиков и QA. У каждой команды в работе теперь не больше 2 спринтов, участники не работают над чужими проектами.
• Появилась команда, которая обрабатывает сообщения из других отделов, реагирует на аномальное поведение сервиса и хотфиксы. Другие команды на эти задачи не отвлекаются.
• Теперь в компании 2 типа стендапов: командные и общие. Все сотрудники информированы о состоянии дел по спринту, а стендап занимает эталонные 5-10 минут.

Что ж, работаем дальше.

Автор: altersun

Источник ^[2]