В этом модуле вы узнаете, что такое гибкие методы разработки и как устроена работа по фреймворку Scrum и методу Kanban.

Scrum

Scrum — сложный фреймворк, его подробное описание есть в официальном «Руководстве по Scrum» (версия 2020 года на русском), поэтому пройдемся по основным моментам.

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

В Scrum три основные роли.

1. Product Owner. Отвечает за ценность продукта и приоритизацию задач.
2. Scrum-мастер. Отвечает за оптимизацию процесса работы и проведение Scrum-событий — встреч.
3. Команда разработки. Отвечает за создание инкремента.

Один из основных артефактов Scrum — бэклог продукта. Это приоритизированный список требований от бизнеса и клиентов, сформированный в виде пользовательских историй (User Stories). Также в новом руководстве Scrum много внимания уделяется концепции Product Goal — цели продукта, к которой должна прийти команда.

В основе продуктовой разработки по Scrum лежат три ключевых принципа.

1. Работа короткими итерациями, в результате которых вы получаете потенциально работоспособный продукт.
2. Фокусировка на отслеживание ценности готового продукта за счет очень короткого цикла получения обратной связи от клиента.
3. Регулярная оптимизация процесса за счет инспектирования различных препятствий и их устранения.

Все это реализуется благодаря Scrum-событиям.

Планирование

Каждый спринт начинается с планирования, на котором команда разработки берет набор пользовательских историй с самым высоким приоритетом из бэклога продукта. Так формируется бэклог спринта. Также на каждый спринт ставится цель — в зависимости пользовательских историй, которые взяты в работу. Цель формулируется командой разработки совместно с Product Owner.

Иногда Product Owner может самостоятельно сформулировать цель. В спринт берутся не только крупные пользовательские истории, но и небольшие задачи. Самое главное, чтобы эти небольшие задачи могли максимально быстро доставить ценность бизнесу и клиенту.

Daily

Чтобы контролировать ситуацию, проходят ежедневные встречи — ежедневный Scrum. Такая встреча называется Daily, на ней каждый участник команды разработки рассказывает, что он сделал вчера, чем он будет заниматься сегодня и какие у него есть препятствия на пути к цели спринта. В новом руководстве по Scrum формат Daily Scrum фокусируется на достижении Sprint Goal и создает план действий на следующий рабочий день.

Обзор (демонстрация)

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

Ретроспектива спринта (ретро)

После демонстрации проходит встреча по ретроспективе спринта. На ней обсуждают внутреннюю кухню — как улучшить командную работу.

Груминг бэклога

В «Руководстве по Scrum» ничего не говорится о груминге бэклога, но в продуктовой разработке это очень важная встреча. Чаще всего она проводится в середине спринта — чтобы бэклог продукта был актуальным, а самые высокоприоритетные задачи из бэклога продукта были готовы к началу планирования спринта.

Чем полезен груминг бэклога? На нем можно добавить в бэклог новые пользовательские истории, удалить неактуальные, пересмотреть приоритеты, оценить задачи, верифицировать уже оцененные пользовательские истории, пересмотреть критерии оценки, разбить пользовательские истории на более мелкие.

Пользовательская история (User Story)

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

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

Структура пользовательской истории
• Роль пользователя.
• Что пользователь хочет от продукта.
• Почему это важно.

Примеры User Story
1. Как покупатель я хочу еще раз проверить состав заказа перед оплатой, чтобы убедиться, что в нем нет ничего лишнего и убрать ненужное.
2. Как пользователь мобильного приложения интернет-магазина, я хочу видеть в каталоге иконки акций, в которых участвует каждый товар, чтобы понимать, какие бонусы получу за покупку.
3. Как менеджер по продажам я хочу видеть отчет по интересам клиентов на курсах, чтобы на их основе разрабатывать новые курсы и приглашать на них заинтересованных клиентов.

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

Для этого команда разработки вместе с менеджером продуктов договаривается о критериях Definition of Ready (DoR), которым к моменту планированию спринта должны соответствовать самые приоритетные истории в бэклоге продукта.

DoR позволяют синхронизировать понимание пользовательской истории внутри команды и не допустить двоякого толкования. Еще есть критерий Definition of Done (DoD) — когда пользовательскую историю можно считать готовой, завершенной.

Kanban

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

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

Классы обслуживания

Чтобы увеличить приоритет определенных типов работ в Kanban существуют классы обслуживания. Их всего четыре.

1. Ускоренный класс — когда проблема не требует отлагательства, ее нужно решить максимально быстро.
2. Класс с фиксированной датой — когда стоимость задержки увеличится в разы после определенной даты. Этот класс часто используют, если скоро вступает в силу федеральный закон.
3. Стандартный класс — когда стоимость задержки растет пропорционально времени работы.
4. Нематериальный класс — такие виды работ не несут прямого влияния, явной прибыли. Это просто работы, которые необходимо выполнять.

Каденции (петли обратной связи) в Kanban

Существует семь типов каденций. 

1. Kanban-митинг. Ежедневная встреча, на которой, в отличие от Scrum, обсуждаются статусы заблокированных (которые  «застряли») задач. То есть команда фокусируется только на проблемных моментах, а не на всей деятельности.
2. Встреча по наполнению очереди. Рекомендуется проводить раз в две недели. На этой встрече берутся обязательства о том, что будет делаться. 
3. Встреча по планированию поставки. Чаще всего проводится раз в две недели — для контроля и планирования поставок заказчикам. 
4. Встреча по обзору сервиса. Чаще всего проводится раз в две недели. Обсуждаются метрики и способы улучшения качества сервиса.
5. Операционная встреча. Проводится реже — примерно раз в месяц. Обсуждаются метрики и улучшение взаимодействия связанных сервисов. 
6. Встреча по обзору рисков. Проходит примерно раз в месяц. Также обсуждаются метрики — с точки зрения того, как заблокированные задачи повлияли на работу всего сервиса и даже связанных сервисов. В Kanban вообще много встреч с обсуждением метрик. 
7. Встреча по обзору стратегии. Проходит примерно раз в квартал. Анализируются метрики и обсуждается необходимость изменять стратегию сервиса.

Scrum и Kanban не всегда достаточно

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

Зависимости могут значительно снижать скорость разработки. Тогда используются подходы, которые помогают масштабировать организацию процессов. Вот список самых популярных: Scrum of scrum, Less, Spotify, SAFe и Nexus. Это сложные комплексные подходы, которые включают в себя большой набор практик и различных нюансов, поэтому подробно их рассматривать мы не будем.

Для тех, кто хочет больше узнать про Scrum, рекомендуем первоисточник — «Руководство по Scrum» Кена Швабера и Джеффа Сазерленда.