3.2 ПРОДУКТ И ЕГО АРТЕФАКТЫ
Авторы раздела:
Бутвина Н. Л.
Алферов П. А.
Ожаровский А. В.
Коротких С. С.
Если вы пропустили раздел о команде, то мы советуем все же вернуться к нему (см. раздел 3.1). Если прочитали, то теперь важно правильно ставить цель перед своей командой. Этот раздел посвящен способам постановки целей в Agile, а также создаваемому продукту проекта. В разделе показано, как именно применяются Agile-инструменты через призму создаваемого поэтапно продукта.
Если вы пропустили раздел о команде, то мы советуем все же вернуться к нему (см. раздел 3.1). Если прочитали, то теперь важно правильно ставить цель перед своей командой. Этот раздел посвящен способам постановки целей в Agile, а также создаваемому продукту проекта. В разделе показано, как именно применяются Agile-инструменты через призму создаваемого поэтапно продукта.
3.2.1 БЭКЛОГ ПРОДУКТА
3.2.1 БЭКЛОГ ПРОДУКТА
Время чтения: 11 мин.
Бэклог продукта — упорядоченный, «плоский» (без иерархии) список элементов планирования проекта (продукта). В качестве элементов планирования могут выступать: функциональные элементы (функции) продукта, требования, задачи, которые нужно выполнить, иные характеристики продукта и т. д. Как правило, эти элементы представлены в форме пользовательских историй (user stories), которые располагаются в порядке приоритета, его определяет владелец продукта (см. раздел 3.4.2).
Время чтения: 11 мин.
Бэклог продукта — упорядоченный, «плоский» (без иерархии) список элементов планирования проекта (продукта). В качестве элементов планирования могут выступать: функциональные элементы (функции) продукта, требования, задачи, которые нужно выполнить, иные характеристики продукта и т. д. Как правило, эти элементы представлены в форме пользовательских историй (user stories), которые располагаются в порядке приоритета, его определяет владелец продукта (см. раздел 3.4.2).
У качественно подготовленного бэклога есть следующие свойства:
- Достаточная детализация. Степень детализации зависит от того, где в списке находится тот или иной элемент бэклога. Элементы, которые находятся выше в списке и, вероятно, попадут в ближайшие 2−3 спринта, должны быть более детализированы, нежели те, которые находятся ниже. Степень детализации должна быть достаточна для проработки элемента бэклога в течение одной итерации (спринта).
- Наличие оценки. В соответствии со Scrum производится оценка по трудоемкости, а не по длительности. Нужно дать ответ на вопрос: насколько данную задачу трудно выполнить? Ответ, как правило, дается не в виде количества страниц или часов работы, а в относительных единицах.
- Динамичность. Бэклог обновляется на протяжении всего проекта. В него добавляются новые элементы, из него убираются ненужные. Элементы можно дробить на более мелкие по мере получения новой информации о продукте или просто уточнять.
- В команде все участники должны одинаково понимать, когда элемент бэклога считается завершенным. Требования к завершенным элементам называются критериями готовности (Definition of Done).
Критерии готовности (Definition of Done) — список требований к результатам работ по продукту (в частном случае — по спринту), которые команда выполняет в течение спринта, чтобы создать инкремент продукта. Этот список команда определяет до того, как начнется первый спринт. В список можно включать требования к качеству результатов работ, составу необходимых проверок и т. д. — все то, что необходимо сделать, чтобы элемент проекта (продукт) можно было назвать готовым. Критерии готовности обеспечивают общее понимание завершенности и уровня качества результатов проекта у всех участников и заинтересованных сторон проекта.
Бэклог продукта «Спортивная страна» состоит из пользовательских историй (см. раздел 3.3.2). Правила формулирования пользовательской истории вы можете прочитать в разделе 3.4.2.
Пример карточки в бэклоге продукта:
Также было решено добавить в бэклог продукта следующие нефункциональные требования:
Пример карточки в бэклоге продукта:
- Как мама активного сына, я хочу видеть все доступные спортивные секции неподалеку, чтобы выбрать подходящие занятия для ребенка (1.2). Цифра в скобках — это номер пользовательской истории (потребуется далее при изучении бэклога спринта и т. д.).
Также было решено добавить в бэклог продукта следующие нефункциональные требования:
- Размер приложения на смартфоне пользователя не должен превышать 30 Мб.
- Приложение должно пройти независимый аудит информационной безопасности со стороны специализированной аудиторской компании ХХХ.
- Приложение должно иметь интеграцию на уровне обмена данными с автоматизированными системами (АС) Х и Y.
3.2.2 СПРИНТ
3.2.2 СПРИНТ
Спринт — итерация длительностью от одной до четырех недель. Крайне желательно соблюдать одинаковую продолжительность спринта в течение всего проекта. Новый спринт начинается сразу же после окончания предыдущего. В ходе спринта команда стремится достичь цели — доставки ценности (инкремента, см. раздел 3.2.5) заказчику в объеме, определенном в ходе планирования спринта (см. раздел 3.5.1). В бэклог спринта команда может вносить лишь минимальные изменения. Такие изменения должны соответствовать следующим критериям:
- Не подвергать риску достижение цели спринта. В ходе спринта может измениться приоритет или появиться новая информация, требующая внесения корректировок. Цель спринта остается неизменной.
- Изменение бэклога спринта не должно влиять на качество.
- В ходе спринта все изменения должны вноситься совместно и по согласованию с владельцем продукта, Scrum-мастером и командой проекта.
Команда проекта «Спортивная страна» выбрала длительность спринта
2 недели, что позволяет сохранить достаточный уровень гибкости проработки решений и при этом довольно часто выпускать существенные обновления продукта, чтобы получать оперативную обратную связь от конечного пользователя. В течение двух недель команда проекта «Спортивная страна» будет работать над MVP.
2 недели, что позволяет сохранить достаточный уровень гибкости проработки решений и при этом довольно часто выпускать существенные обновления продукта, чтобы получать оперативную обратную связь от конечного пользователя. В течение двух недель команда проекта «Спортивная страна» будет работать над MVP.
3.2.3 ЦЕЛЬ СПРИНТА
3.2.3 ЦЕЛЬ СПРИНТА
Цель спринта — это краткое описание того, ради чего выполняется спринт. Она необходима, чтобы команда проекта могла самостоятельно принимать решения, например при появлении альтернативных путей решения задачи. Цель спринта определяется владельцем продукта. Часто целью спринта может быть создание минимально жизнеспособного продукта (Minimum Viable Product, MVP). Это инкремент продукта с минимально необходимым набором характеристик, который пользователи могут применять для удовлетворения той или иной потребности.
Целью спринта команда часто указывает подготовку MVP и его последующую доработку. Так, для первого спринта была определена цель — создать MVP, позволяющий видеть список спортивных учреждений и секций в САО Москвы в мобильном приложении для iOS. В последующих спринтах может быть поставлена цель расширить список заведений за счет включения других районов Москвы и развить удобную систему отображения ближайших заведений и секций на основе местонахождения пользователя. Цель спринта определяется исходя из приоритетов на каждом отдельном этапе разработки продукта.
3.2.4 БЭКЛОГ СПРИНТА
3.2.4 БЭКЛОГ СПРИНТА
Бэклог спринта — это список задач, которые команда планирует выполнить/протестировать за время спринта. Часто пользовательские истории из бэклога продукта команда делит на отдельные задачи для реализации в ходе спринта и заносит в бэклог спринта на Kanban-доске. Список задач определяется в ходе планирования спринта. В течение спринта новые задачи/требования не появляются в бэклоге спринта, за исключением критических задач/поручений. Все задачи следует оценить с точки зрения трудозатрат и значимости реализации в ходе спринта.
Карточки в бэклоге спринта проекта «Спортивная страна», созданные для одного из последующих спринтов проекта
(1) Исправить систему отображения спортивных учреждений на карте (M).
(1) Обновить реестр спортивных учреждений в САО Москвы (S).
(2) Разработать систему определения спортивных учреждений, ближайших к местонахождению пользователя (M).
(1) Сформировать реестр спортивных секций и разбить его по учреждениям (L).
(2) Сформировать реестр спортивных мероприятий в САО Москвы (L). (2) Создать инструмент по добавлению спортивных мероприятий пользователями (L).
(3) Собрать информацию по всем требованиям к получению спортивных разрядов (L).
(3) Сформировать реестр профессиональных разрядов по наиболее распространенным видам спорта (M).
(3) Создать MVP системы хранения информации о спортивных достижениях граждан (M).
Буквы S, M, L и т. д. (как в обозначении размеров одежды — от XS до XXL) означают условную размерность задачи с точки зрения трудозатрат, так как довольно сложно определить точное количество часов, которое потребуется на выполнение задачи. Можно использовать любые удобные условные обозначения трудоемкости. Задачи расположены в порядке убывания значимости их выполнения в ходе спринта, значимость (приоритет) отмечена цифрой в скобках.
(1) Исправить систему отображения спортивных учреждений на карте (M).
(1) Обновить реестр спортивных учреждений в САО Москвы (S).
(2) Разработать систему определения спортивных учреждений, ближайших к местонахождению пользователя (M).
(1) Сформировать реестр спортивных секций и разбить его по учреждениям (L).
(2) Сформировать реестр спортивных мероприятий в САО Москвы (L). (2) Создать инструмент по добавлению спортивных мероприятий пользователями (L).
(3) Собрать информацию по всем требованиям к получению спортивных разрядов (L).
(3) Сформировать реестр профессиональных разрядов по наиболее распространенным видам спорта (M).
(3) Создать MVP системы хранения информации о спортивных достижениях граждан (M).
Буквы S, M, L и т. д. (как в обозначении размеров одежды — от XS до XXL) означают условную размерность задачи с точки зрения трудозатрат, так как довольно сложно определить точное количество часов, которое потребуется на выполнение задачи. Можно использовать любые удобные условные обозначения трудоемкости. Задачи расположены в порядке убывания значимости их выполнения в ходе спринта, значимость (приоритет) отмечена цифрой в скобках.
3.2.5 ИНКРЕМЕНТ
3.2.4 БЭКЛОГ СПРИНТА
Инкремент — это ощутимый результат работы в процессе одной итерации (спринта). Например, это может быть внедрение новой функции на сайте, прототип мобильного приложения, обновленная версия ПО с исправленными ошибками. Команда должна показать заказчику или пользователям, что она сделала за прошедшее время. Это нужно для получения обратной связи и планирования следующих задач по улучшению продукта. Каждый инкремент должен быть готовым и завершенным и иметь ценность для пользователей. Но не любой результат спринта будет инкрементом. Например, если в течение всего спринта команда работала только над техническим долгом (устраняла неоптимальные архитектурные решения, внедряла новую версию базы данных и т. д.), то новая версия продукта (с устраненным техническим долгом) не будет инкрементом, так как, с точки зрения конечного пользователя, не имеет для него дополнительной ценности по сравнению с предыдущей версией.
Как правило, в Agile-подходе бюджет и сроки фиксированы, поэтому управление и определение состава инкремента ведутся через приоритизацию содержания, как показано на рисунке 7.
Как правило, в Agile-подходе бюджет и сроки фиксированы, поэтому управление и определение состава инкремента ведутся через приоритизацию содержания, как показано на рисунке 7.
Рисунок 7. Бюджет — cроки — cодержание
Инкремент первого спринта:
- реестр спортивных учреждений и секций САО Москвы (доступный для просмотра в мобильном приложении);
- реестр спортивных мероприятий САО Москвы (доступный для просмотра в мобильном приложении);
- система определения ближайших спортивных учреждений, секций и мероприятий САО Москвы на основе геолокации пользователя (внутри приложения).
3.2.6 МИНИМАЛЬНО ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ
3.2.6 МИНИМАЛЬНО ЖИЗНЕСПОСОБНЫЙ ПРОДУКТ
Минимально жизнеспособный продукт (MVP) — это инкремент продукта с минимально необходимым набором характеристик, который пользователи могут применять для удовлетворения той или иной потребности (рисунок 8). Он позволяет проверить гипотезы относительно продукта и понять его соответствие ожиданиям пользователей и требованиям к результату проекта. Такой подход позволяет сэкономить ресурсы на модификацию продукта на поздних стадиях готовности, снижает риски расходования ресурсов на ненужный продукт.
Цель команды — в кратчайшие сроки выпустить MVP и начать получать обратную связь от пользователей и заинтересованных сторон.
В различных случаях MVP может представлять собой:
- продукт с минимальным набором ключевых характеристик (автомобиль с двигателем, рулем, тормозами и кузовом, но без кондиционера, фар, стеклоподъемников; мобильный банк без функции перевода денег и оплаты счетов);
- модель или прототип будущего продукта (только интерьер салона автомобиля, чтобы пассажиры проверили, насколько он удобен, или интерфейс приложения без рабочих функций);
- работающий ИТ-сервис без полной автоматизации (клиент заполняет форму онлайн, но вместо автоматической обработки ее обрабатывают операторы вручную).
Рисунок 8. Минимально жизнеспособный продукт
Примеры MVP для нескольких спринтов подряд:
- реестр спортивных учреждений и секций САО Москвы (доступный для просмотра на экране мобильного приложения);
- реестр спортивных учреждений и секций по САО Москвы (с возможностью интерактивного взаимодействия (отображение на карте, возможность позвонить, отправить e-mail));
- реестр спортивных учреждений и секций по САО Москвы (с возможностью интерактивного взаимодействия и определения ближайших на основе геолокации пользователя);
- доработанное приложение (с возможностью интерактивного взаимодействия с расширенным реестром спортивных учреждений и секций САО и еще 3−5 районов Москвы и определения ближайшего на основе локации пользователя);
- полностью функциональное приложение (с возможностью интерактивного взаимодействия с любым спортивным учреждением Москвы (запись в секцию, уточнение расписания и т. д.)).
MVP может последовательно развиваться в ходе каждого последующего спринта, попутно разработчики наращивают функционал и добавляют ценность для конечного пользователя.