Артефакты 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, АС). Это описание того, в каких условиях будет тестироваться функциональность и какой ожидается результат.

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

Примеры связки US и АС можно увидеть в табл. 3.9.

Используется одна и та же формулировка US, но разные АС.

Табл. 3.9. Пример бэклога с разными критериями приемки

3.2.4.2. Бэклог спринта

Бэклог спринта (sprint backlog) – это план спринта для разработчиков. Прозрачная картина того, что было сделано для достижения цели спринта, актуализируемая каждый день на ежедневном Scrum.

Обязательство: цель спринта

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

Лучшие практики управление бэклогом спринта

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

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

Использовать диаграмму сгорания. Диаграмма сгорания позволяет в реальном времени видеть отставание в процессе спринта. Например, на рис. 3.21 видно, что разработчики закрывают задачи вовремя, практически по идеальному графику. Но если посмотреть на график сгорания сторипоинтов, то заметно отставание. Ну и самое главное – график сгорания пользовательских историй отражает самую суть: сколько единиц ценности будет поставлено. Ориентация на график сгорания пользовательских историй позволяет минимизировать риски недопоставки. Для ритмичной поставки истории на протяжении спринта можно использовать практику роения.

Роение (swarming) – подход к разработке, когда вся команда последовательно реализует историю за историей на протяжении спринта. Это позволяет не терять время на переключение между задачами и не держать в голове дополнительный контекст по принципу «сделал – забыл». При достаточно мелкой декомпозиции пользовательских историй команда может сразу двигать их по Kanban-доске, на разбивая на задачи. Этот подход подразумевает, что вся команда «набрасывается» на историю и работает над ней одновременно.

Как можно одновременно работать над одной пользовательской историей, не всегда очевидно, особенно для тех, кто до этого занимался заказной разработкой. Обычно в таких случаях возникают вопросы типа: «Как я сверстаю интерфейс без дизайн-макета?» или «Как мне делать разработку фронта без бэкенд API?».

Прежде всего история должна быть достаточно маленькая, желательно атомарная, типа «Я как пользователь могу удалить раздел». Это делает работу каждого понятной и обозримой. Далее команда активно взаимодействует и дорабатывает артефакты друг для друга.

Например: в начале разработки дизайнер и фронт-разработчик совместно рисуют схему расположения элементов, фокусируясь при этом на уже существующих компонентах. Фронт-разработчик и бэк-разработчик прописывают контракты[48] взаимодействия. QA (quality assurance, инженер, отвечающий за тестирование) создает моки[49] (mock) – тестовые данные, которые позволят фронту и бэку отлаживать базовые сценарии взаимодействия. В середине пути дизайнер создает макет более стильного и удобного интерфейса. Фронтенд элемент за элементом улучшает интерфейс согласно макету.

Бэкенд постепенно заменяет моковые методы на настоящие, a QA в реальном времени тестирует эти методы, адаптируя тест-кейсы. Бывает, что не все идеи дизайнера получается воплотить; в этом случае команда находит компромиссное решение (рис. 3.22).

Рис. 3.22 Управление качеством артефакта в процессе спринта

В конце пути QA тестирует функциональность на тестовой среде в составе релиз-кандидата, остальные участники исправляют выявленные недочеты.

3.2.4.3. Инкремент продукта

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

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

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

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

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

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

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

Пример определения завершенности

Часто бывает, что на старте члены Scrum-команды по-разному понимают значение Done (Выполнено). Владелец продукта ожидает, что функциональностью можно пользоваться реальным пользователям. Для разработчиков Done может значить, что код написан и ждет тестирования. DoD позволяет выравнивать ожидания.

В табл. 3.10 вы можете ознакомиться с примером определения завершенности с показательными элементами, собранными в разное время от разных команд.

Как уже стало заметно, DoD – мощнейший инструмент для управления требованиями к:

➠ производительности;

➠ архитектуре;

➠ безопасности;

➠ развертыванию;

➠ качеству кода;

➠ сбору аналитических данных;

➠ сравнительным экспериментам;

➠ дизайну;

➠ документации;

➠ инфраструктуре;

➠ ролям;

➠ процессам;

➠ требованиям;

➠ обслуживанию;

➠ автоматизации тестирования;

➠ процессам тестирования.

Табл. 3.10. Пример определения завершенности (DoD)

Важно как можно раньше начинать развивать DoD для подготовки к фазе масштабирования.

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