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

Владелец продукта (РО): Предлагаю разделить на две истории, когда значение сохраняется только на фронте, а вторая – на бэке.

SM: Разобьем историю на несколько: «Я как пользователь могу согласиться с правилами без повторного запроса на все время браузерной сессии» и «Я как пользователь могу согласиться с правилами без повторного запроса на разных устройствах».

3.2.3.16. Отмена спринта

Бывают такие ситуации, когда нет смысла продолжать спринт. В этом случае Scrum-команда договаривается остановить спринт (рис. 3.19).

Рис. 3.19. Схема разделения одного спринта на два при выполнении остановки спринта

В день остановки проводятся завершающие события спринта – демо и ретро.

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

3.2.4. Артефакты Scrum

Артефакты Scrum созданы для фиксации обязательств и прозрачности:

➠ Бэклог продукта – обязательства по цели продукта.

➠ Бэклог спринта – обязательства по цели спринта.

➠ Инкремент – обязательства в соответствии с определением завершенности.

3.2.4.1. Бэклог продукта

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

Элементы продуктового бэклога могут быть завершены за один спринт и подготовлены для выбора на планировании спринта. Обычно они подготавливаются в процессе прояснения бэклога. Элементы бэклога отвечают на вопрос «что», а не «как».

Обязательство: цель продукта

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

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

Scrum-команда работает в направлении достижения цели продукта. (Подробнее о том, как эффективно описывать цель продукта, см. в п. 4.3.6.)

Типы элементов бэклога

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

Пользовательская история

Пользовательская история – это описание особенности продукта, какую новую возможность он получает, голосом пользователя. Пользовательская история – идеальный граничный объект (см. п. 2.4.), который позволяет передать суть функциональности («что?»), но дает при этом свободу команде разработчиков в способе реализации («как?»).

Наибольшую популярность получил шаблон, описанный Майком Коном (рис. 3.20).

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

Энейблер

Энейблеры (enabler), как правило, начинают появляться на зрелых фазах существования продукта, когда сформирован поток ценности (см. 4.2.2. Определение потока ценности).

Рис. 3.20. Шаблон пользовательской истории, описанный Майком Коном

В руководстве по фреймворкам масштабирования Agile SAFe выделяют четыре вида энейблеров:

➠ Исследовательский (exploration). Обозначает работы по проведению исследований, прототипирование и прочие активности, необходимые для прояснения пользовательских историй. Популярный вид таких энейблеров – Spike, который используется разработчиками, если они не могут оценить историю в процессе прояснения бэклога.

➠ Архитектурный (architectural). Работы по повышению эффективности разработки и поддержки, например настройка CI/CD.

➠ Инфрастуктурный (infrastructural). Работы, направленные на оптимизацию инфраструктуры. Например, снижение стоимости владения или митигация рисков стабильности.

➠ Комплаенс (compliance). Работы по аудиту и приведению системы в соответствие стандартам, спецификациям, внешним и внутренним требованиям, например, приведение хранилища платежных данных в соответствие стандарту PCI DSS.

Критерии приемки

Обязательная часть пользовательской истории – критерии приемки (Acceptance Criteria, АС). Это описание того, в каких условиях будет тестироваться функциональность и какой ожидается результат.

Критерии приемки позволяет делать формулировки историй более короткими и не перегружать их техническими деталями.