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




Содержание страницы

РАБОТА С БЭКЛОГОМ ПРОДУКТА

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

Среди элементов бэклога могут быть исследование потребностей покупателя или различных технических вариантов, описание функциональных и нефункциональных требований, необходимых для запуска продукта дей­ствий, а также другие компоненты — например, создание рабочего окружения или устранение дефектов. Бэклог продукта заменяет традиционные документы с требованиями, такие как спецификации рынка и продукта. Владелец продукта отвечает за управление бэклогом продукта, в него также вносят свой вклад scrum-мастер, команда и заинтересованные лица. Вместе они открывают функциональность продукта.

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

ГЛУБИННЫЕ СВОЙСТВА БЭКЛОГА ПРОДУКТА

Элементы бэклога продукта обладают четырьмя свой­ствами: имеют достаточную степень детализации, оценены, независимы и приоритизированы — в английском языке получается удобная аббревиатура DEEP (от detailed, estimated, emergent, prioritized) — глубинный. Рассмотрим эти свойства подробнее.

ДОСТАТОЧНАЯ СТЕПЕНЬ ДЕТАЛИЗАЦИИ

Элементы бэклога продукта имеют достаточную степень детализации, это показано на рисунке 3.1. Элементы с более высоким приоритетом описаны подробнее, чем менее важные. «Чем ниже приоритет, тем меньше деталей, вплоть до полного минимума», — пишут Швабер и Бидл (Schwaber and Beedle, 2002; 33). Следуя этому правилу, вы сохраняете бэклог продукта минималистичным, а его элементы — реализуемыми в течение спринта. В результате требования выявляются, декомпозируются и детализируются в течение всего проекта.

Рисунок 3.1. Степень приоритетности элемента бэклога продукта определяет уровень его детализации

ОЦЕНКА

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

РАЗВИТИЕ

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

ПРИОРИТЕТНОСТЬ

Все элементы бэклога продукта расположены по приоритетности. Самые важные внедряются в первую очередь. Они находятся в верхней части бэклога продукта, как показано на рисунке 3.1. После завершения работы над элементом он удаляется из бэклога.

РАБОТА НАД БЭКЛОГОМ ПРОДУКТА

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

  • Выявляются и описываются новые элементы, а существующие при необходимости изменяются или удаляются.
  • Происходит расстановка приоритетов. Самые важные задачи помещаются в верхнюю часть.
  • Высокоприоритетные элементы подготавливаются к ближайшему совещанию по планированию спринта. Они декомпозируются и детализи­руются.
  • Команда определяет масштаб элементов бэклога продукта. Это необходимо ввиду внесения в него новых элементов, изменения существующих и исправления оценок.

Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним — это командный процесс. Выявляются и описываются элементы, они выстраиваются по приоритету, декомпозируются и детализируются всей scrum-командой. В Scrum выделяется на эту деятельность до 10% командного времени (Schwaber, 2007). При необходимости в процесс вовлекаются и заинтересованные лица. Требования больше не спускаются команде сверху, в их формулировании принимают участие все члены команды. Владелец продукта, scrum-мастер и команда общаются не через документацию, а лично.

Совместная работа над бэклогом продукта интересна и эффективна. Она порождает диалог как внутри scrum-команды, так и между командой и заинтересованными лицами. Она устраняет разделение на «бизнесменов» и «технарей», ликвидирует ненужные передаточные звенья. Требования становятся более ясными, к их разработке привлекаются коллективный опыт и творческий импульс всей scrum-команды, создается ощущение причастности к общему делу.

Некоторые команды предпочитают заниматься работой с бэклогом сразу после ежедневного scrum-митинга. Другие работают еженедельно или проводят более длинную рабочую сессию с ним ближе к окончанию спринта. Работа с бэклогом продукта происходит и на обзорных совещаниях по спринтам, когда scrum-команда и заинтересованные лица обсуждают дальнейшую разработку: выявляются новые элементы бэклога и удаляются устаревшие. Не забудьте включить в свои планы работу с бэклогом, например еженедельную. Хорошо проработанный бэклог продукта — это необходимое условие для успешного совещания по планированию спринта.

Отличное средство, облегчающее работу с бэклогом продукта, — бумажные карточки. Они дешевы, удобны в использовании и облегчают совместную работу: кто угодно может взять карточку и записать в ней свою идею. Карточки можно сгруппировать на столе или стене и сверяться с ними по мере необходимости. Карточки и электронные средства ведения бэклога продукта, такие как электронные таблицы, дополняют друг друга: перед сессией работы с бэклогом распечатайте на бумажных карточках уже имеющиеся требования, а затем вновь перенесите эту информацию в электронные инструменты­.

Ниже подробно рассмотрим четыре этапа работы с бэк­логом продукта, начав с выявления и описания его элементов.

ВЫЯВЛЕНИЕ И ОПИСАНИЕ ЭЛЕМЕНТОВ

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

ВЫЯВЛЕНИЕ ЭЛЕМЕНТОВ

Выявление элементов бэклога продукта начинается с его создания. Лучше всего это делается совместными усилиями: члены scrum-команды и при необходимости заинтересованные лица в ходе мозгового штурма выявляют элементы, нужные для создания продукта, используя в качестве точки отсчета его идею, его видение или дорожную карту. При этом не пытайтесь думать обо всех элементах сразу. Каждый раз, когда вы работаете с бэклогом, сосредоточивайтесь на минимальной функциональности, необходимой для выхода продукта на рынок, и придерживайтесь принципа простоты, который обсуждался в главе 2. В ходе проекта появятся новые идеи, и бэк­лог продукта будет развиваться в соответствии с отзывами клиентов и пользователей. Если в самом начале бэклог продукта станет слишком длинным и сложным, будет трудно сосредоточиться и правильно расставить приоритеты. Используйте идею или видение продукта, чтобы направлять свои усилия. Сконцентрируйтесь на главном и отложите в сторону остальное. Нужно противостоять искушению слишком быстро добавлять новые подробности. Элементы перечня описываются с течением времени в соответствии с их приоритетностью. Низкоприоритетные элементы остаются неделимыми и обобщенными, пока их приоритет не изменится (либо они станут более срочными, либо основные задачи будут уже выполнены). Нефункциональные требования, которые относятся к свойствам всего продукта, служат исключением из этого правила. Как вы узнаете из этой главы, они должны быть подробно описаны с самого начала.

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

Всякий раз, когда в бэклог вносится требование, следует убедиться, что соответствующая потребность клиента была правильно понята. Спросите себя, зачем нужно это требование и почему оно идет на пользу клиенту. Не нужно слепо копировать требования в бэклог продукта, иначе получите непоследовательный и неуправля­емый список пожеланий. Существующие требования считайте сомнительными, трактуйте их скорее как помеху, а не актив. Требование просто описывает функциональность продукта, которая в определенный момент считалась необходимой. С изменением рынков и технологий, а также с ростом понимания scrum-команды того, как лучше удовлетворить потребности покупателя, требования либо меняются, либо устаревают.

ОПИСАНИЕ ЭЛЕМЕНТОВ

Scrum не предписывает методов описания элементов бэклога продукта, но я предпочитаю работать с пользовательскими историями (Cohn, 2004). Как можно догадаться по названию, это история о том, как клиент или пользователь работают с продуктом. Она содержит имя, краткую информацию и критерии приемки — условия, которые позволяют понять, реализована история или нет. История может быть обобщенной или подробной. Обобщенные истории называются эпиками. Писать, декомпозировать и детализировать пользовательские истории несложно. Конечно, для описания требований можно применять любой другой метод. А если вы предпочитаете пользовательские истории, то необязательно описывать все элементы бэклога продукта. Например, требования по удобству пользователя рекомендуется отображать в виде прототипов или набросков.

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

СТРУКТУРИРОВАНИЕ БЭКЛОГА ПРОДУКТА

Бэклогу часто идет на пользу группировка элементов по тематическому признаку. Темы — это будущая функ­циональность продукта. Они структурируют бэклог, помогают расставить приоритеты, делают удобным доступ к информации. Так, примеры тем для мобильного телефона — это электронная почта, календарь, голосовая связь и органайзер. В принципе, каждая тема должна для начала содержать от двух до пяти обобщенных требований. Этой информации достаточно, чтобы понять, что нужно для производства продукта, при этом содержание бэклога не замусоривается лишними деталями. Темы создают иерархию в бэклоге, который теперь помимо индивидуальных элементов содержит и их группы. Вдобавок полезно провести дальнейшее разграничение между обобщенными требованиями, например эпиками, и детализированными элементами, например историями. Пример такого бэклога частично приведен в таблице 3.1.

Жизненный цикл ПО. Scrum шаг за шагом

Scrum является одним из возможных способов реализации гибкой (Agile) методологии разработки. В отличие от каскадной модели жизненного цикла ПО, отличительной особенностью Scrum является итеративность.

Процесс разработки разбивается на отдельные этапы, результатом каждого из которых является готовый продукт. В конце каждого этапа (в терминологии Scrum — спринта) готовый продукт предоставляется заказчику. Полученный от заказчика отзыв позволяет выявить возможные проблемы или пересмотреть некоторые аспекты первоначального плана. Таким образом, Scrum позволяет наилучшим образом следовать принципам Agile-разработки.

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

  • Владелец продукта(Product owner) представляет интересы конечного пользователя.
  • Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings).
  • Скрам-команда(Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты.

Итак, давайте рассмотрим основные этапы разработки, характерные для Scrum.

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story). Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager:

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

  • Важность (Importance). Степень важности задачи по мнению владельца продукта. Описывается произвольным числом.
  • Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах.
  • Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи.

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

  • Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
  • Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
  • Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
  • ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Шаг 2. Планирование спринта и создание Бэклога спринта

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

Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings

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

Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово». Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта:

Также может быть использовано программное обеспечение, предназначенное для такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA.

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

Результатом каждого совещания также является burndown-диаграмма. По оси X на ней откладываются дни работы над спринтом, а по оси Y — общее количество story points для данного спринта. После завершения задачи, требовавшей определенного количества story points для ее решения, можно отметить на диаграмме точку, в которой на данный момент находится проект. Пример такой диаграммы, построенной в JIRA, приведен ниже:

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

Шаг 4. Тестирование и демонстрация продукта

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

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

Шаг 5. Ретроспектива. Планирование следующего спринта

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

Заключение

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

Блог о проактивном бизнесе

Business Agility Coaches

Как жить, если Бэклог Продукта похож на винегрет

Я работаю с большим количеством организаций, которые учатся использовать Скрам, как инструмент для организационной гибкости. Недавно я заметил закономерность: если команда не может сформулировать Цель Спринта, нужно смотреть на их Бэклог Продукта. И, как правило, он похож на мое любимое блюдо, винегрет. Найти смысл в винегрете — непростая задача 🙂

Со временем отдельные случаи превратились в паттерн и я осознал: Цель Спринта является одним из индикаторов здоровья Бэклога Продукта, потому что именно она объединяет смыслом элементы Бэклога Продукта и служит основанием для командной работы. Сам Бэклог Продукта ультимативно определяет успех продукта, это генеральный план для Скрам-команды.

Попробуем разобраться, как проверить свой Бэклог на винегретность и улучшить ситуацию, если дело плохо.

Как понять, что ваш Бэклог — винегрет

Я выделил четыре маркера, которые помогут оценить качество Бэклога продукта.
Проверьте себя:

  • В Бэклоге нельзя разобраться без пояснений Скрам-команды.
  • «Хотелки» стейкхолдеров никак не связаны друг с другом. Кажется, что в Бэклог накидано все подряд.
  • Через элементы Бэклога не прослеживается стратегия развития продукта.
  • В описании элементов много технических терминов.

Если найдете у себя хотя бы два — это винегрет. И я знаю, что с этим делать.

Что делать с винегретным Бэклогом Продукта

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

Прокачайте Владельца Продукта

Дайте реальную власть. Убедитесь, что тот, кого вы называете Владельцем Продукта, на самом деле им является. Цель настоящего Владельца Продукта — оптимизация бизнес-ценности продукта для всей организации. Владелец Продукта — лидер-слуга для организации, mini-CEO продукта и предприниматель. Не все обязаны быть довольными решениями Владельца Продукта, тем не менее, каждый обязан их уважать и соблюдать.

Спрашивайте бизнес-метрики. Убедитесь, что Владелец Продукта отвечает за бизнесовые метрики: Return On Investment (ROI), Cost Benefit Ratio, Profits and Loss (P&L) и другие. Если скоуп работ жестко зафиксирован, то это никак не стимулирует оптимизировать бизнес-ценность и заниматься приоритезацией Бэклога Продукта. Более того, в этом случае, скорее всего, Владелец Продукта даже не заинтересован в поиске бизнес-ценности. Единственное, что его будет интересовать — попадание в треугольник менеджера (time, scope, cost).

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

Помогите создать дорожную карту продукта и поставить бизнес-цели на ближайший квартал. Сделайте цели измеримыми (SMART), а также сформулируйте несколько критериев, по которым вы будете оценивать каждый элемент Бэклога Продукта. Получите поддержку и согласие у заинтересованных лиц. И в следующий раз, когда Василий Петрович прибежит к Владельцу Продукта с просьбой включить важную фичу в Бэклог, он сможете ответить: «Василий Петрович, мы договорились, что в ближайший квартал снижаем операционные расходы. Как ваша идея поможет нам?»

Прокачайте работу с продуктом

Убедитесь, что Скрам-команда разрабатывает именно продукт. Да-Да, я серьезно. Если команда получает некие данные, а после Спринта передает их другим командам в измененном виде, то вряд ли это продукт. Обычно такие псевдо-продукты имеют название, похожее на Frontend System, Backend System, Core System, Platform.

Настоящий Продукт — это нечто, что приносит бизнес-ценность пользователю (внешнему или внутреннему). Сами по себе данные никакой бизнес ценности не несут, в этом случае Скрам-команда локально оптимизирует часть цепочки по поставке ценности. Попытайтесь сформировать команду с фокусом на клиенте end-to-end, чтобы максимально использовать преимущества Скрама.

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

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

Прокачайте Бэклог Продукта

Свяжите задачи с бизнес-целями. Используйте технику Impact Mapping для связи бизнес-целей с задачами в Бэклоге Продукта. На мой взгляд, это одна из наиболее мощных продуктовых техник, которая помогает понять «А не фигней ли занимается команда?»

Пропишите каждой задаче четыре атрибута. Убедитесь, что каждый элемент Бэклога Продукта имеет четыре обязательных атрибута: порядок, бизнес-ценность, оценку и описание. Это поможет Владельцу Продукта упорядочить Бэклог: ему будет легко вычислить возврат инвестиций (ROI) для каждого элемента и расставить их в порядке уменьшения ROI.

Сформулируйте задачи так, чтобы они стали понятны конечному пользователю. Хороший Бэклог Продукта должен быть прост и понятен пользователям. Если они с трудом могут разобрать смысл формулировок, пора пересмотреть описания и сместить фокус работы Команды Разработки на то, что действительно ценно.

Подводим итоги

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

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

Меня зовут Илья Павличенко , и я — Аджайл Коуч в компании Unusual-Concepts . Также я сертифицированный Скрам тренер в Scrum.org Я ни минуты не работаю, потому что занимаюсь любимым делом. Скрам — мое хобби и моя жизнь. Хотите больше узнать о том, как стать эффективным Скрам-мастером и Владельцем Продукта? Приходите на мои Professional Scrum Master (PSM) и Professional Scrum Product Owner (PSPO) тренинги.

Как создать план проекта в Scrum за 5 шагов

Любому проекту нужен план. Каким он будет, зависит от методологии, которую вы выберете. Сегодня говорим о гибких методологиях в управлении.

Это статья-кейс, где мы показали прикладное применение методологии, которую scrum-студия «Сибирикс» использует в digital-проектах.

Что нужно знать прежде, чем начать

Что такое план управления проектом

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

Кто готовит план управления проектом

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

Первый шаг. Выясняем требования

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

  1. Задаем вопросы, чтобы выяснить цели клиента: какие задачи он хочет решить с помощью продукта.
  2. Оцениваем общую ситуацию на рынке и конкурентов клиента.
  3. Выясняем целевую аудиторию и какие ее проблемы может решить продукт.

Второй шаг. Составляем структуру проекта

После первого шага у вас много информации. Ее настолько много, что разобраться в ней пока трудно. Что делать? Структурировать все данные. Так вы поймете, все ли понятно или остались невыясненные части.

  1. Используем mindmap.
  2. Группируем информацию: цели, задачи, ЦА продукта.
  3. Заносим в mindmap все, что узнали.

Третий шаг. Пишем техническое задание

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

Пишем бэклог продукта.

Расставим приоритеты: чем важнее задача, тем больше число ей присваиваем и тем раньше мы приступим к ее выполнению. Например, «1» ― задача с минимальной важностью, «10 000» ― с максимальной. Пределы зависят только от сложности проекта и количества задач, но цифры не должны повторяться в рамках одного бэклога. Приоритеты зависят от важности требования для продукта.

В самом начале трудно спланировать, сколько часов займет какая задача, поэтому будем оценивать примерно, в условных единицах. Выбираем самую простую задачу, например, пусть будет «Форма обратной связи». Затраты на ее выполнение минимальны, то есть ставим «1». Остальные задачи оцениваем относительно первой. Сложность растет ― цифра тоже. У нас получилось, что самая сложная задача на данный момент — «Главная страница». Примерные затраты на ее выполнение ― шесть условных единиц.

По ходу работы меняем требования местами, если изменился приоритет.

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

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

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

Четвертый шаг. Делаем прототип

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

  1. Готовим наглядную схему продукта: электронную версию или на бумаге. Не концентрируемся на дизайне, тут важна структура.
  2. Акцентируем внимание на удобстве интерфейса будущего продукта для пользователя.
  3. Показываем результат клиенту. Он добавляет комментарии.

Пятый шаг. Планируем спринт

Весь процесс работы делим на равные отрезки, в Scrum они называются спринтами. Каждый длится две недели или месяц, зависит от типа проекта.

  1. Определяем цель спринта. Она должна быть реалистичной. Не ставьте цель, которую не сможете выполнить.
  2. Составляем бэклог. Задача Scrum ― создать продукт с минимальной функциональностью для быстрого запуска на рынок. Элементы бэклога спринта нужно сформулировать так, чтобы каждый член команды понимал задачу одинаково. Каждый элемент должен быть осуществимым, чтобы была реальная возможность внедрить его за один спринт.
  3. Оцениваем элементы спринта, чтобы понять сложность и трудоемкость, проще расставить приоритеты и прогнозировать ход проекта.
  4. Выполняем задачи спринта последовательно, учитывая приоритеты.
  5. По итогу каждого спринта оцениваем, что было сделано и достигнута ли цель: сколько задач решено и какие элементы готовы к использованию.
  6. Если есть сомнения по поводу какого-то элемента продукта, лучше запустить его как можно скорее и проверить в деле. Пользователи подскажут, как лучше.

Мы рассмотрели основные шаги, которые нужны, чтобы составить план проекта в Scrum. Но после составления плана работа только начинается. Дальше ― больше.

Scrum ― это передовая методология, которая может сильно улучшить ваши результаты. Но чтобы все работало, нужно потрудиться и разобраться в тонкостях. Бэклог продукта, спринты, владелец продукта ― в этих названиях новичку легко запутаться. А еще многое зависит от типа разработки: заказная или внутри компании.

Чтобы разложить все по полочкам, лучше не сто раз прочитать, а один послушать практиков и сразу перейти к делу. Хороший способ прокачать навыки и добавить в копилку новых знаний ― онлайн-курсы. Например, в Skillbox есть курс, где все подробно объясняют про особенности Scrum и учат разбираться в сложных процессах управления веб-разработкой.

Жизненный цикл ПО. Scrum шаг за шагом

Scrum является одним из возможных способов реализации гибкой (Agile) методологии разработки. В отличие от каскадной модели жизненного цикла ПО, отличительной особенностью Scrum является итеративность.

Процесс разработки разбивается на отдельные этапы, результатом каждого из которых является готовый продукт. В конце каждого этапа (в терминологии Scrum — спринта) готовый продукт предоставляется заказчику. Полученный от заказчика отзыв позволяет выявить возможные проблемы или пересмотреть некоторые аспекты первоначального плана. Таким образом, Scrum позволяет наилучшим образом следовать принципам Agile-разработки.

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

  • Владелец продукта(Product owner) представляет интересы конечного пользователя.
  • Скрам-мастер (Scrum master) следит за соблюдением принципов Scrum-разработки, координирует процесс, проводит ежедневные собрания (Scrum Meetings).
  • Скрам-команда(Scrum team) участвует в разработке продукта. В скрам-команду входят программисты, тестировщики, аналитики и прочие специалисты.

Итак, давайте рассмотрим основные этапы разработки, характерные для Scrum.

Шаг 1. Создание бэклога продукта

Бэклог продукта (Product backlog) представляет собой упорядоченный по степени важности список требований, предъявляемых к разрабатываемому продукту. Элементы этого списка называются Пользовательскими историями (User story). Каждой истории соответствует уникальный ID. Вот пример пользовательских историй из бэклога продукта, использованного во время работы над XB Staff Manager:

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

  • Важность (Importance). Степень важности задачи по мнению владельца продукта. Описывается произвольным числом.
  • Предварительная оценка (Initial estimate). Предварительная оценка объема работ. Измеряется в story point’ах.
  • Как продемонстрировать (How to demo). Описание способа демонстрации завершенной задачи.

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

  • Категория (Track) служит для того, чтобы владелец продукта мог выбрать все пункты определенной категории и установить им низкий или высокий приоритет. Примером такой категории может быть «Панель управления».
  • Компоненты (Components) состоит из списка компонентов продукта, которые будут изменены во время работы над историей. Такими компонентами могут быть модули приложения, как например, аутентификация или поиск.
  • Инициатор запроса (Requestor) -заказчик, заинтересованный в реализации определенной функциональности. Это поле необходимо, если нужно держать заказчика в курсе текущего положения дел.
  • ID в системе учёта дефектов (Bug tracking ID) содержит ссылки на обнаруженные дефекты, относящиеся к истории с определенным ID.

После того, как составлен бэклог проекта, можно приступить к следующему шагу — планированию спринта.

Шаг 2. Планирование спринта и создание Бэклога спринта

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

Во время планирования спринта команда выбирает самые приоритетные пользовательские истории из бэклога продукта и решает, каким образом будут решаться поставленные задачи. Истории, выбранные для реализации в течение данного спринта составляют Бэклог спринта (Sprint backlog). Количество историй, попадающих в бэклог спринта зависит от их длительности в story point’ах, присвоенных каждой истории на этапе предварительной оценки. Это количество выбирается так, чтобы каждая история была успешно реализована к концу спринта.

Шаг 3. Работа над спринтом. Scrum meetings

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

Для визуализации процесса разработки удобно использовать учетные карточки. Они могут иметь вид больших карточек с названием конкретной истории и маленьких стикеров, описывающих отдельные задачи, необходимые для реализации истории. После начала работы над определенной задачей, ее стикер перемещается из поля «Запланировано» в область «В работе». По завершении работы над задачей, стикер перемещается в поле «Тестирование» и затем, при успешном выполнении тестирования, в поле «Готово». Расположив истории согласно их важности, можно получить представление о текущем состоянии проекта:

Также может быть использовано программное обеспечение, предназначенное для такого рода задач. Примером такого ПО может служить, например, Atlassian JIRA.

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

Результатом каждого совещания также является burndown-диаграмма. По оси X на ней откладываются дни работы над спринтом, а по оси Y — общее количество story points для данного спринта. После завершения задачи, требовавшей определенного количества story points для ее решения, можно отметить на диаграмме точку, в которой на данный момент находится проект. Пример такой диаграммы, построенной в JIRA, приведен ниже:

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

Шаг 4. Тестирование и демонстрация продукта

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

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

Шаг 5. Ретроспектива. Планирование следующего спринта

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

Заключение

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