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

Примеры связки 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-командой.

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

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

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