Текст книги "Менеджмент цифрового продукта. От идеи до идеала"

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

Табл. 3.4. Краткое описание событий и процессов Scrum

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

Помимо официальных названий, есть устоявшиеся неофициальные: обзор спринта – демо. Далее для краткости будем использовать как официальные, так и неофициальные обозначения.

Для начала давайте рассмотрим «скелет» событий Scrum (рис. 3.14).

➠ На планировании спринта собирается Scrum-команда. Участники идут сверху вниз по бэклогу, прошедшему приоритизацию, и разработчики набирают в него элементы.

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

➠ Несколько раз за спринт Scrum-команда встречается для прояснения бэклога, чтобы добавить новые элементы, провести декомпозицию, приоритизацию и оценку.

➠ В конце спринта Scrum-команда собирается для обзора. Владелец продукта инспектирует инкремент продукта и определяет готовность, согласно определению завершенности.

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

Затем все повторяется.

Рис. 3.14. Scrum: схема процесса

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

➠ Начинать спринт с планирования. Это помогает избежать дней простоя после окончания спринта, когда команде нечем заняться.

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

➠ Проводить демо, ретро и планирование в один день. Это позволяет команде избежать не занятых работой часов. Участники не переключаются на разработку и сфокусированы на ритуалах. Однако процесс получается утомительным и важно делать перерывы.

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

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

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

Тема 1. Почему этот спринт важен?

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

Тема 2. Что будет сделано во время спринта?

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

Тема 3. Как это будет сделано?

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

➠ Не менять длину спринта. У команды вырабатывается определенный ритм и определенные внутренние ритуалы. Фиксированная длина спринта позволяет эффективно оценивать его объем и собирать статистику.

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

➠ Учитывать отпуска и болезни. Это влияет на то, какие истории и в каком объеме могут быть взяты в спринт.

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

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

➠ Чрезвычайный буфер (emergency buffer). Если почти каждый спринт из-за чрезвычайных ситуаций запланированный объем выполняется не в полной мере, нужно зарезервировать несколько единиц объема под такие работы и делать поправку при планировании.

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

Цель ежедневного Scrum – обменяться статусами, планами и определить препятствия к достижению цели спринта.

Хорошая практика, когда каждый член команды разработчиков по очереди рассказывает:

➠ что было сделано вчера;

➠ что запланировано на сегодня;

➠ какие препятствия могут помешать выполнить запланированный объем в срок.

Часто для визуализации используется Scrum-доска (см. п. 3.1.3.6.). В этом случае каждый участник передвигает свои задачи по Kanban-доске для изменения статуса (рис. 3.7).

Scrum-мастер модерирует встречу, чтобы не обсуждались темы, не связанные с ежедневным прогрессом. Если команда начинает разбор полетов, то Scrum-мастер предлагает перенести обсуждение на ретро; если начинается обсуждение реализации, то на прояснение бэклога. По другим вопросам предлагается сделать отдельную встречу или перенести обсуждение в чат.

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

Цель обзора спринта – проинспектировать результат спринта. Разработчики демонстрируют продуктовый инкремент элемент за элементом. Если демонстрируемый элемент соответствует описанию в бэклоге продукта и определению завершенности, то элемент считается готовым.

➠ Открытое демо (public demo). На обзор спринта приглашаются все желающие – стейкхолдеры, члены других команд, сотрудники организации и пользователи-спонсоры[46]46
  Пользователи-спонсоры (англ, sponsor users) – пользователи, вовлеченные в создание продукта, например, представители бизнес-заказчика для В2В-продукта.


[Закрыть].

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

➠ Выставочное демо (trade show demo). По аналогии с выставкой для каждого реализованного элемента создается «выставочный павильон». Реальные пользователи, стейкхолдеры и другие участники проходят через все павильоны и тестируют функциональность, а представители команды в каждом павильоне фиксируют озарения для улучшений в продукте. Такой подход позволяет протестировать инкремент сразу на нескольких пользователях за ограниченное время.

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

➠ Не показывать почти готовое. Бывает, что элемент почти готов, но не соответствует определению завершенности, например, не развернут на пользователей, но его можно увидеть в тестовом окружении. Статус «почти готово» может сбить с толку, вселить ложные надежды и, самое главное, придется повторно инспектировать артефакт, когда он будет готов.

Ретроспектива позволяет поддерживать процессы в актуальном состоянии. Scrum-команда инспектирует последний спринт и анализирует его в разрезе ролей, процессов, инструментов и определения завершенности.

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

Важно, чтобы каждый член команды мог высказаться.

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

➠ Обсуждение положительных моментов в формате благодарения (thanksgiving retro). Участники говорят спасибо за положительные моменты, которые помогали. Это сплачивает и настраивает на позитивную коммуникацию.

➠ Последовательность «коуч – наставник – учитель». Паттерн для Scrum-мастера, который позволяет генерировать проблемы максимально эффективно:

➠ для начала человеку, заявившему о проблеме, предлагается придумать решение самостоятельно (коуч);

➠ если это не приносит результатов, всем предлагается вспомнить лучшие практики из опыта (наставник);

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

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

➠ Обсуждение проблем, повлекших незавершенность элементов бэклога. Для каждого незавершенного элемента бэклога в спринте выявляются проблемы, которые помешали завершению, и определяются решения этих проблем. Это позволяет острее сфокусироваться на предсказуемости прогнозов и минимизировать разговоры о малозначимых абстрактных проблемах.

➠ Голосование за проблемы позволяет вскрыть то, что волнует большинство. Организовать это можно инструментально, например, при помощи чат-бота, который собирает во время спринта в чате команды темы с хештегом #наретро и позволяет голосовать. Такой подход позволяет сэкономить время ретро и сфокусироваться на наиболее важных проблемах.

➠ Регулярная смена шаблонов ретроспектив. Существуют десятки, если не сотни разных шаблонов проведения ретроспектив. Их регулярная смена вносит разнообразие и позволяет привнести новые лучшие практики в сам процесс ретроспективы.

Цель прояснения бэклога – поддержание верхней части списка в актуальном состоянии, чтобы планирование проходило максимально быстро.

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

Сессии прояснения бэклога позволяют минимизировать неопределенность перед планированием и планировать максимально эффективно.

Руководство по Scrum не регламентирует, какими должны быть элементы продуктового бэклога (product backlog items, или PBI), но без сомнений можно сказать, что самый популярный тип – это пользовательская история. Вторым по популярности можно считать Spike, появившийся впервые в экстремальном программировании. Впоследствии популярный фреймворк масштабирования Agile, SAFe (Scaled Agile Framework), внес Spike в состав более широкого класса сущностей – энейблеров. Они бывают нескольких размерностей – от энейблер-эпик (enabler epic) до энейблер-истории (enabler story). Так как далее в нашем контексте мы будем обсуждать размеренность уровня истории, то для краткости будем использовать термин «энейблер» в отношении «энейблер-история».

Типы элементов продуктового бэклога представлены в табл. 3.5.

Табл. 3.5. Элементы продуктового бэклога

Энейблеры – значительно более редкий элемент продуктового бэклога, поэтому часто можно услышать термин «история». Применяется для всех элементов продуктового бэклога. (Подробнее об энейблерах см. в п. 3.2.4.1.)

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

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

Табл. 3.6. Пример продуктового бэклога и горизонты планирования и декомпозиции

На планировании спринта нужно быстро оценить, сколько элементов бэклога может войти в спринт. Для этого каждая история оценивается в условных единицах – сторипоинтах (англ, story points – баллы истории). Зная объем сторипоинтов, закрытых в прошлых спринтах, можно предположить, сколько сторипоинтов будет завершено в планируемом спринте.

В табл. 3.6 приведен пример бэклога. Команда быстро может набрать истории в спринт, ориентируясь на прошлые показатели. Остается запас оцененных историй на 1–2 спринта, благодаря чему команда может планировать спринты самостоятельно, в исключительной ситуации, когда владелец продукта не смог участвовать. Также запас позволяет варьировать скоуп[47]47
  Скоуп (англ, scope) – набор фич и частей продукта, закрепленных за отдельной командой.


[Закрыть] спринта, и лучше его заполнять. В табл. 3.6 владелец продукта понизил приоритет одной из историй во время планирования для более эффективного заполнения объема спринта.

Для эффективной подготовки элементов к планированию, по аналогии с определением завершенности (DoD), вводят понятие определение готовности (Definition of Ready, DoR).

DoR представляет собой некий чек-лист, которому должна соответствовать история, перед тем как отправиться на планирование.

По аналогии с DoD, DoR формируется командой самостоятельно в процессе работы.

Табл. 3.7. Акроним INVEST как основа для определения завершенности

Для старта подойдет популярная группа критериев, названная INVEST по первым буквам (табл. 3.7).

Помимо INVEST, в DoR могу входить и другие критерии в зависимости от домена, например, «описание соответствует шаблону юзерстори», «готов дизайн-макет» или «написан тест-кейс».

История, которая не умещается в один спринт и обычно занимает до одного квартала разработки, называется эпик (epic story). Для декомпозиции эпиков используются инструменты декомпозиции, такие как картирование пользовательской истории (user story mapping). Далее, если история недостаточно маленькая, ее разбивают снова, используя шаблоны декомпозиции.

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

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

Такой подход позволяет собрать все идеи реализации, отсортировать их и распределить по релизам.

В сторимэпе выделяется четыре слоя:

➠ Роль – смена ролей в процессе взаимодействия; иногда их может быть несколько.

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

➠ Шаг – атомарный элемент пользовательского путешествия.

➠ Особенности – идеи того, как может быть реализован шаг.

Рис. 3.15. Пример карты пользовательской истории

Процесс картирования пользовательской истории

1. Определяются активности, которые нужно декомпозировать в первую очередь.

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

3. В процессе размещаются новые активности и роли.

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

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

6. Особенности распределяются по релизам.

7. В первый релиз выделяют то, без чего действительно невозможно обойтись (минимально жизнеспособный релиз).

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

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

Табл. 3.8. Пример бэклога для одного релиза, сформированного на основе карты пользовательской истории (рис. 3.6)

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

Разбиение по «и/или»

Если в описании истории используется «И/ИЛИ», значит, можно разделить прямо по этим союзам. Это относится и к спискам, разделенным запятыми.

Пример:

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

Можно разделить на:

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

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

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

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

Разбиение на операции

Известный представитель такого типа шаблонов – CRUD. Название шаблона – это аббревиатура из первых букв действий, которые можно совершать со списком: Create, Read, Update, Delete (Создать, Прочитать, Обновить, Удалить).

Историю «Я как пользователь могу редактировать список разделов» люжно разделить на:

Я как пользователь могу создать раздел.

Я как пользователь могу видеть список разделов.

Я как пользователь могу редактировать раздел.

Я как пользователь могу удалить раздел.

Разделение по этапам процесса

Если процесс содержит несколько шагов, то можно разделить по ним. Например, если для публикации контента нужно пройти этапы рецензирования редактором и юристом, то история «Я как контент-менеджер могу публиковать материал на сайте» может быть разделена на:

Я как контент-менеджер могу публиковать материал напрямую на сайте.

Я как контент-менеджер могу публиковать материал на тестовом сайте.

Я как корректор могу проверить материал перед отправкой.

Я как редактор могу проверить материал перед отправкой.

Если внимательно приглядеться, история «Я как пользователь могу ввести e-mail, чтобы зарегистрироваться» может быть разбита на три атомарных этапа:

Я как пользователь могу просто ввести e-mail.

Я как пользователь могу увидеть, что e-mail не соответствует шаблону name @domain.zone.

Я как пользователь могу увидеть, что введенный e-mail уже существует.

Разделение по производительности

Историю «Я как пользователь могу получать изображение в реальном времени» можно разбить на варианты «заставить работать» и «работать быстро»:

Я как пользователь могу получать изображение.

Я как пользователь могу получать изображение менее чем за 5 секунд.

Я как пользователь могу получать изображение менее чем за 1 секунду.

Этот шаблон может быть применим для:

➠ времени выполнения;

➠ времени доступности;

➠ качества контента и пр.

Разделение по сегментам пользователей

Историю «Я как пользователь могу распознать текст на фото» можно разделить на:

Я как пользователь iOS версии выше 17 могу распознать текст на фото.

Я как пользователь Android версии выше 13 могу распознать текст на фото.

Этот шаблон может быть применим для:

➠ типов устройств – настольные, мобильные;

➠ операционных систем и их версий – iOS, Android;

➠ лояльности – сотрудник компании, друзья и родственники, бета-тестер, постоянные клиенты, члены команды;

➠ сегментов обслуживания – премиальные, массовые.

Добившись малой размерности истории, можно переходить к оценке.