Хабрахабр

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

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

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

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

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

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

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

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

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

Переход на 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 минут.

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

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть