От Kanban к Scrum: выбор гибкой методологии разработки

Почему команда Atlassian Micros Scale перешла с Kanban на Scrum

Nelly Sattari Автор: Nelly Sattari
Просмотр тем

Самоорганизованность является одной из составляющих здоровой команды разработчиков! Такая команда имеет четкие роли и обязанности и стремится поставлять проекты по продуманному плану.

В прошлом году мы набрали новую команду под названием Micros Scale, которая занимается созданием нашей внутренней платформы как сервиса (PaaS), предназначенной для разработчиков. Ввиду фиксированного объема задач и четких сроков, мы стали уделять больше внимания поэтапному, более сосредоточенному, целенаправленному и предусмотрительному выполнению работы.

Раньше команда выполняла большое количество ситуативных оперативных работ, что мешало нам правильно планировать спринты. На ротации для поддержания текущей деятельности было выделено не менее 55 процентов возможностей команды. Так методология Kanban стала наиболее подходящей для нас на тот момент.

Стоит отметить, что согласно модели Такмана команда Micros Scale находилась на этапе формирования и требовались улучшения в ряде областей, включая планирование производительности, планирование спринтов, постановку целей, командный анализ, ведение и доработку историй, оценку, разбивку проектов и так далее.

изображение: модель Такмана

Какая agile-методология нам подошла?

У Micros Scale есть два очень сложных крупных проекта, сроки выполнения которых публично объявлены клиентам. Это означает, что быстрая поставка очень важна. Мы хотели быть уверены в подходе к поставке и хотели работать над планированием как профессионалы в области Agile. Нам хотелось, чтобы наша команда была самоорганизованна, достигла общих целей и опиралась на эмпирические данные.

Мы пересмотрели свой agile-подход, задав следующие вопросы.

  • Можно ли поставить цель для каждой итерации, чтобы решить задачу с помощью уникальной темы?
  • Можем ли мы взять на себя обязательства по выполнению некоторого объема работ, который должен быть готов в течение одной или двух недель?
  • Можем ли мы разработать и зафиксировать требования, над которыми мы должны трудиться?
  • Низка ли частота ситуативных запросов на изменение приоритета заданий? Низка ли вероятность внесения кардинальных изменений?
  • Являемся ли мы молодой командой, которая только осваивает agile-процессы?


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

 

 

 

 

Гибкая методология

Особенности

Поможет ли это нам?

Почему?

Scrum

Scrum — это четкая дорожная карта с расставленными по приоритетам объемами работ, тогда как Kanban — это визуализация работы, которая возникает перед командой от случая к случаю.

Да

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

Истории не следует менять в середине спринта.

Да

Мы можем использовать более гибкий подход. В данном случае это Scrumban (гибрид Scrum и Kanban).

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

Да

У нас молодая команда с новыми участниками. Она все еще находится на стадии формирования и разрешения конфликтов, поэтому методология Scrum помогает ей развиваться. См. модель Такмана.

Kanban

Ограничение незавершенной работы и упор на сокращение времени цикла проекта. Пример использования: у команды нет временных рамок на выполнение работы и установленной хронологии. Команде поступает запрос, который она обрабатывает как можно быстрее (как соглашение SLA, которое соблюдают команды службы поддержки).

Нет

От нас зависят другие команды, поэтому нам нужен примерный график работ, чтобы остальные могли планировать свою работу в соответствии с ним. Нам необходимо учитывать и планировать выполнение некоторых обязательств, о которых мы публично объявили клиентам Atlassian. У нас не очень много краткосрочных запросов типа заявок в службу поддержки.

Отлично подходит для команд с большим количеством входящих операционных запросов, имеющих различные приоритеты и размеры.

Да

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

Мы выбрали Scrum

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

Освоение новых методов Agile

Внутренние учебные ресурсы Atlassian помогли мне улучшить навыки в области Agile. Я прошла объемные курсы по гибкой методологии разработки и проконсультировалась с тренером по Agile, а также побеседовала с несколькими техническими руководителями, чтобы узнать об их опыте работы в других организациях и командах.

Использование DACI

Модель принятия решений DACI, которая расшифровывается как driver (драйвер), approver (подтверждающее лицо), contributor (помощник), informed (информируемое лицо), использовалась для успешного и эффективного принятия групповых решений. Я ознакомила участников своей команды с предложением изменить DACI, чтобы получить их комментарии, согласие и поддержку.

Использование шаблона спринта

Я разработала процесс управления нашими спринтами и создала шаблон для каждого спринта, чтобы планировать разумно и эффективно. Шаблон планирования спринта включал следующие вопросы.

  • Как проанализировать предыдущий спринт, чтобы понять, чего мы достигли, и отпраздновать это событие?
  • Как провести ретроспективу предыдущего спринта и применить полученные знания к следующему?
  • Каковы периодичность спринта, его название, цели и задачи?
  • Сколько историй мы готовы поставить? Каков объем работы в спринте?
  • Как спланировать производительность с учетом доступности сотрудников?
  • Какие действия требуются в середине спринта, чтобы полностью подготовиться к следующему спринту?
  • Как писать истории, формулировать требования и находить решения для выполнения спринта?
  • Как отслеживать состояние историй, которые мы взялись выполнить, и что делать с незавершенными историями?

А еще у нас есть отличный учебник по работе со спринтами в Jira Software.

Выгода от перехода на Scrum

Вот улучшения, которые мы получили после перехода на Scrum.

Повышение скорости

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

Диаграмма скорости команды

Выявление рисков на ранней стадии

Ключ к успешному выполнению проектов заключается в способности выявлять риски на раннем этапе и находить способы их устранения.

Определив цели и темы спринтов, мы выбрали истории, связанные с достижением целей. В середине спринта команда вела, уточняла и прорабатывала истории. На этапе доработки мы задавали следующие вопросы.

  • Что нужно сделать?
  • Почему мы делаем эту работу?
  • Какую пользу это принесет бизнесу?

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

Празднование поставки

Благодаря планированию производительности и постановке целей мы получили ощутимый мотивационный заряд, но при этом столкнулись с задачей обеспечения прозрачности наших обязательств. Мы успешно завершили один из важнейших этапов сегментирования аккаунтов для Atlassian PaaS. Кроме того, мы почти готовы поставить первый этап нашего проекта по хранению данных, который охватывает еще больше регионов AWS для обеспечения надежности, отказоустойчивости и соответствия требованиям.

Переход от формирования к нормированию

Как я уже упоминала выше, команда Micros Scale относительно молода и в соответствии с моделью Такмана находится скорее на стадии формирования.

Определение единой цели вдохновило участников команды. Они сплотились и поддерживали друг друга для достижения общих целей и повышения уровня мотивации в команде. Мы терпели неудачи, анализировали их, делали выводы и становились лучше. Спустя три с половиной месяца мы расширили состав Micros Scale на 50 %, и я по-прежнему с гордостью оцениваю команду как проходящую этап нормирования.

Улучшение коммуникации

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

Как выбрать гибкую методологию

  1. Не бойтесь пересматривать процессы, если обнаружите проблему. Мыслите в парадигме Agile: люди, процессы и инструменты.
  2. Оцените проект и обязанности своей команды, чтобы найти наиболее подходящие для нее методики Agile. Подробнее об этих методиках см. на странице Сравнение Kanban и Scrum.
  3. Если вы решите перейти на Scrum, я предлагаю использовать Scrum-доску Jira либо создать шаблон в Confluence или любимом инструменте.

Создавайте страницу планирования для каждого спринта, чтобы просматривать и анализировать последний спринт, а также планировать следующий с учетом производительности команды и цели спринта. Вот мой личный шаблон Confluence:

Изображение: шаблон для планирования спринта

Вот шаблон планирования производительности, который включен в мой общий шаблон Scrum:

доступность в Scrum

А вот шаблон для целей и объема работы на время спринта:

изображение: цель спринта

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

Ведение бэклога

Каждая команда уникальна, и то, что сработало для нас, может не сработать для других. Оптимальными методиками могут стать Scrum, Kanban или их сочетание, например Scrumban и Kanplan. Очень важно оценить конкретные потребности вашей команды и подобрать наиболее подходящую методологию.

продолжение темы
Руководства по agile