Scrum backlog: Полная схема scrum — работа с бэклогом и релизный цикл — Карьера на vc.ru

что такое бэклог продукта и как им управлять? / Блог компании Hygger / Хабр

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

Бэклог продукта (product backlog) — это упорядоченный набор элементов, очередь задач, перечень всех функций, которые заинтересованные люди хотят получить от продукта. Этот список содержит краткие описания всех желаемых возможностей продукта.

Product manager или product owner представляют бэклог команде и управляют им, описывает его главные элементы во время митинга по планированию спринта. Описание бэклога следует производить на простом и доступном языке, без технических спецификаций, чтобы оно было понятно каждому в команде. Любые изменения и требования по продукту должны быть своевременно отражены в этой очереди задач.

Бэклог продукта vs бэклог спринта

Эти два компонента Scrum несут разный смысл, но их часто путают.

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

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

Бэклог продукта составляет product owner, а за бэклог спринта отвечает команда разработчиков. Еще одним важным отличием является время создания бэклога: Product backlog создается на самом первом планировании спринта, а Sprint backlog должен создаваться командой на каждом планировании нового спринта. Таким образом, первый бэклог живет на протяжении всей разработки продукта, а Sprint backlog — на протяжении 1-4 недель, то есть, в течение одного спринта.

В чем смысл бэклога продукта?

Работа над Agile-проектами не предполагает долгого документирования всех требования. Обычно product owner и другие члены команды начинают работу над проектом, отмечая все, что им нужно, для приоритизации бэклога. Уже такого бэклога достаточно для первого спринта. Затем его можно растить и менять.

Обычный бэклог продукта включает следующие пункты:

• Функции продукта (например, формы пользовательских историй — описания желаемой функциональности)
• Разные баги
• Получение новых знаний (например, обновление рабочих мест)
• Технические работы (например, любые полезные исследования)

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

Элементы бэклога — это «пользовательские истории» или user stories. Такие элементы упорядочены в зависимости от их бизнес «веса». Чем выше в бэклоге конкретный элемент, тем скорее разработчики будут работать над ним. Верхние позиции будут более подробно описанными и четкими по сравнению с нижними элементами. Все они должны быть понятны для нетехнических членов команды и заинтересованных сторон.

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

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

Для чего нужен backlog refinement?

Backlog refinement (улучшение, оптимизация, «чистка») — это действие или мероприятие, во время которого команда добавляет детали, оценки и порядок в элементы продукта. Процесс не должен охватывать более 10% рабочего времени команды разработчиков.
Этот постоянный процесс означает сотрудничество собственника продукта и разработчиков, когда ими рассматриваются и пересматриваются все элементы продукта.

Чем бэклог продукта в Agile отличается от простого списка дел?

У бэклога продукта есть определенные свойства:

• Любая отметка в backlog продукта добавляет ценности для клиентов.
• Все записи в бэклоге продукта оцениваются.
• Все отметки получают свой приоритет и порядок.
• Уровень детализации зависит от позиции отметки в Scrum backlog.
• Бэклог продукта — это живой документ без каких-либо бездействий или задач низкого уровня приоритета.

Что делать, если бэклог неустанно растет?

Фокус на ключевых приоритетах — одна из ключевых задач менеджера продукта или product owner. Однако очень часто у них нет времени изучать и отслеживать все новые возможности конкурентов. Пользователи постоянно предлагают улучшения и дают советы, члены команды предлагают новые идеи, происходят обновления. Когда бэклог продукта увеличивается, становится сложно его контролировать. Как успевать отслеживать приоритеты, если идеи в бэклоге нарастают как снежный ком?

Решение можно найти в современных платформах для управления продуктами, таких как Hygger.io. Функционал платформы помогает справиться со следующими вопросами:

• Структурирование бэклога на основе Kanban-досок, лейблов и горизонтальных Swimlanes.
• Оценка идей (с помощью удобных критериев Value and Effort).
• Визуализация и приоритезация важных идей на основе диаграммы Backlog Priority Chart.

Структурирование бэклога

В бэклоге Hygger простой список идей представлен на двухмерной доске. Здесь вы найдете полезные ярлыки (Labels) и горизонтальные колонки (Swimlanes). Вы можете использовать столбцы на бэклог-панели, чтобы визуализировать рабочие этапы для идей:

• Collect Ideas — для сбора всех идей.
• Review Ideas — для изучения идей и прояснения непонятных моментов. Детально описывать идеи на старте не нужно, так как неизвестно, будет ли точно идея выбрана для разработки.
• Score Ideas — для оценивания идеи.
• Approval — для проверки идеи Scrum-мастером или менеджером проекта.
• Developing — для отправления идеи в разработку.
• Done — для реализованных идей. Это означает, что функция «залита» на продакшн.

Swimlanes в Hygger можно использовать для организации идей. Эти горизонтальные столбцы на Kanban-доске используются для разделения различных видов проблем, которыми заняты члены команды. Они помогают командам легче определить, над каким вопросом им работать дальше.

Опция Labels может использоваться для обозначения идей от конкретных пользователей или от конкретных сотрудников.

Оценка идей

В Hygger вы можете оценить все свои идеи, используя 2 критерия: Value and Efforts. Сопоставление этих значений для каждой задачи помогает лучше определить приоритеты и выбрать наиболее важные из задач для ближайшей разработки.

• Value показывает, какую бизнес-ценность может принести ваш продукт или бизнес.
• Efforts измеряют ресурсы, необходимые для выполнения задачи.

Backlog Priority Chart

Все оцененные идеи могут быть показаны на графике Backlog Priority Chart. Этот график полезен для оценки идей относительно друг друга. Помимо шкал Value and Effort, здесь предлагаются 4 квадранта:

• Quick Wins для идей с действительно высокой ценностью и низкими усилиями.
• Big Bets для идей, имеющих большие ценность и усилия.
• Maybes для идей с низкими ценностью и усилиями.
• Time Sinks для идеи с низким преимуществом, но высокими ресурсными затратами.

Каков бы ни был разрабатываемый продукт, услуга или сервис, оптимизация бэклога — это неотъемлемая часть функционала в управлении. Профессиональный product owner может запросто перейти с бэклогом на «ты», в том числе, благодаря профессиональным инструментам для управления бэклогом, которые превращают его из рутины в приятный процесс.

Бэклог продукта — совершенный список задач

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

Что такое бэклог продукта?

Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он в свою очередь не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum). 

Подсказка

Храните все в одном трекере задач. Не используйте несколько систем для отслеживания багов, требований и рабочих задач по разработке. Есть задача для команды разработчиков? Тогда информация о ней должна быть в одном бэклоге.

Два столпа бэклога продукта

В основе бэклога продукта находятся дорожная карта и требования команды. Инициативы дорожной карты делятся на несколько эпиков, и каждый эпик содержит несколько требований и пользовательских историй. Давайте рассмотрим дорожную карту для вымышленного продукта «Команды в космосе».

Вебсайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.

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

От чего может зависеть то, как владелец продукта расставляет приоритеты?

• Важность для клиента
• Необходимость в обратной связи
• Относительная сложность реализации
• Тесная взаимосвязь между рабочими задачами (например, сделать «Б» будет проще, если сначала сделать «А»)

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

Правильное ведение бэклога

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

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

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

Подсказка

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

Примеры, которых нужно избегать

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

Бэклоги продукта и верность команды принципам agile

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

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

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

Подсказка

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

Поделитесь этой статьей

Dan Radigan

Методология Agile оказала на меня огромное влияние как в профессиональном, так и в личном плане. Я понял, что и в программировании, и в жизни оптимальный подход — гибкий. Мои интересы лежат на пересечении технологий, фотографии и мотоспорта. 

Product Backlog

Как-то в статье о Sprint мы писали, что это основа методологии Scrum, и всё вокруг него крутится. Сегодня самое время сказать:

«А сам-то Sprint то крутится вокруг Product Backlog и производной – Sprint Backlog!».

На самом деле Product Backlog должен быть понятен абсолютно всем (за что и отвечает Product Owner). Прозрачность Product Backlog помогает разобраться в нём как команде, так и заказчику. Сделать его таким – сродни искусству. Порой заказчики и специалисты говорят совершенно на разных языках, и данный «языковой барьер» главным образом мешает работе, а ещё, более того, таит в себе опасности. Если где-то какое-то недопонимание было изначально, и интерпретация желаний заказчика была не совсем верная, то по прошествии спринта будет готовый продукт, который, представьте себе, сильно ушел в сторону. Малейшее отклонение в ядре продукта может привести к его неисправимой эволюции в другую сторону, так как весь остальной код может базироваться на ошибочном изначальном.

Сам Product Backlog состоит из элементов бэклога или, как модно называть, User Story. По сути, это список желаний, или, на сленге разработчиков – «хотелок». Сами эти «хотелки» должны быть упорядочены по степени важности.

Но довольно слов, давайте посмотрим, как это выглядит:

Расшифровка полей Product Backlog:

ID – всем разработчикам тут всё понятно. Уникальный номер задачи, который идет по порядку.

Название – ёмкое название задачи, которое, по сути, должно быть однозначным и понятным всем.

Важность – в каком порядке выполнять задания, чтобы как можно скорее строился готовый продукт, а потом только расширялся и улучшался. Каждая компания делает свои стандарты по шкале оценок. Например, может быть от 10 до 150.

Изначальная оценка – пока это просто примерное значение, которое накидал Product Owner, но, по сути, оно может, конечно же, меняться. Просто когда команды работают над похожими продуктами вместе достаточно долго, то Product Owner понимает, сколько требуется трудовых ресурсов на выполнение той или иной задачи. Потом, конечно, это переоценивается при помощи Planning (Scrum) Poker.

Демонстрация – чтобы доказать законченность работы, надо продемонстрировать результат. Что хочет видеть Product Owner и заказчик? Это и необходимо описать в данном поле.

Релиз – по сути, это наглядная демонстрация того, что хотелось бы видеть после первого спринта. По мере роста очков важности бывает тяжело определить, на чем остановиться, если есть какие-то пограничные состояния. Например, Product Owner по Velocity знает, на что способна команда и как идет её работа. Он рассчитывает по Story Points и по «Важности», сколько примерно команда сможет выполнить за одну итерацию. Бывает так, что вроде следующий пункт уже выходит за рамки возможностей команды, согласно Velocity, или, наоборот, можно еще что-то впихнуть, но стоит ли? Product Owner может оценить, что для логичной законченности продукта на эту итерацию, скажем, не надо делать пункт, который ещё можно включить, и ставит на нём «Релиз 2».

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

На самом деле в Product Backlog могут быть и другие поля, расширяющие понимание задач и всего проекта:

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

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

Сначала необходимо попытаться написать это всё по строчкам: 1 I A, 2 II B, 3 III C, 4 IV D, 5 V E – и засечь, сколько времени это займет. Можно представить, что арабские цифры – работа с базой данных, римские – с файловым сервером, буквы – это API. То есть вам нужно сначала сделать что-то по базе, потом по файлам, потом по API. Теперь, по тесту, нужно написать всё тоже самое, только по столбикам: 1 2 3 4 5, I II III IV V, A B C D E. Так, конечно, получится намного быстрее, так как мозгу нет необходимости переключаться с одной системы на другую, и он на автомате работает гораздо лучше в одной системе координат.

Привязываясь к данному примеру с компонентами, представьте, что у команды есть возможность работы не с такими данными: 3 III C, 5 V E, а скажем, с такими: 1 2 3 4, A B C. Такая работа будет намного продуктивней.

Инициатор задачи. Как известно, ответственный за Product Backlog – Product Owner, однако его правкой могут заниматься многие. Очень удобно отслеживать, кто поставил задачу, чтобы знать, с кем по этому поводу общаться.

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

Возвращаясь к разделению на категории, всегда возникает вопрос: а как поступать, если имеются несколько команд разработки? Сделать для каждой своего Product Owner и свой Product Backlog? Может лучше иметь один Product Backlog и одного Product Owner?

На само деле существуют разные подходы, используемые компаниями.

Подход №1 – один Product Owner и один Product Backlog

Такой подход похож на ситуацию, когда капитаны команд в какой-либо игре отбирают себе игроков. Сначала один капитан выбирает себе самого сильного игрока, потом второй самого сильного из оставшихся и так далее. Здесь происходит похожая ситуация. Product Owner располагает задачи из Product Backlog в порядке важности, и команды начинают разбирать себе задачи также в порядке важности. Деление обычно происходит по тематике (для этого удобно использовать соответствующую графу в Product Backlog).

Команды могут поторговаться за какие-то задачи, сгруппировать их у себя, поменять приоритеты.

Когда распределение закончено, каждая команда занимается только своей стеной задач, то есть своим Sprint Backlog.

Подход №2 – один Product Owner и несколько Product Backlog

Всё, собственно, тоже самое, только задачи на команды раздает Product Owner. Тут, конечно, сразу возникают резонные замечания, одно из которых: «Зачем владельцу продукта распределять задачи по командам? Команды сами лучше решат, кто что сделает, ведь Product Owner может не знать тонкостей реализации» – и это вполне резонно. Однако в некоторых случаях рабочего процесса это может вполне работать. Благодаря такому подходу сама подготовка и формирование Sprint Backlog происходит значительно быстрее. Если на каком-то производстве заранее известно, какой команде какой набор лучше дать – этот способ подойдет как нельзя лучше.

Подход №3 – несколько Product Owner и несколько Product Backlog

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

Тренироваться составлять Product Backlog на бумаге не всегда эффективно. Мы предлагаем Вам попробовать это в боевом режиме в системе Scrum Time, тем более это бесплатно.

Scrum — что это такое, как это работает и в чем преимущества

Собрания или мероприятия Scrum

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

Перечислим основные собрания, в которых может принять участие команда Scrum.

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

2. Планирование спринта. Работу, которую необходимо выполнить (объем спринта) в течение текущего спринта, планируют на этом собрании всей командой разработчиков под руководством scrum-мастера. На нем принимается решение о цели спринта. Затем в спринт добавляются конкретные пользовательские истории из бэклога продукта. Эти истории всегда соотносятся с целью. При этом команда Scrum согласовывает такие истории, которые можно будет реализовать на практике в ходе спринта.

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

3. Спринт. Спринт — это фактический промежуток времени, в течение которого команда Scrum совместно работает над созданием готового инкремента. Как правило, спринт длится две недели, хотя некоторым командам проще спланировать объем спринта на одну неделю или поставить инкремент, обладающий достаточной ценностью, за месяц. Дейв Уэст из Scrum.org рекомендует выбирать спринт тем короче, чем сложнее работа и чем больше в ней неизвестных. Но последнее слово всегда за командой, и вам не стоит бояться менять продолжительность спринта, если покажется, что она вам не подходит. В течение этого периода владелец продукта и команда разработчиков могут пересмотреть объем спринта, если это необходимо. Это и есть ключ к пониманию эмпирической сути Scrum.

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

4. Ежедневное scrum-совещание, или стендап. Это ежедневное сверхкороткое собрание, которое для простоты проводится в одно и то же время (обычно утром) и в одном и том же месте. Многие команды стараются уложиться в 15 минут, но это не более чем ориентир. Такое собрание еще называется «ежедневным стендапом», что подчеркивает его краткость. Ежедневное scrum-совещание проводится, чтобы каждый участник команды был в курсе происходящего, не отклонялся от пути к цели и получал план работы на ближайшие 24 часа.

   Стендап — самое время сообщить обо всем, что мешает вам достичь цели спринта, в том числе о блокерах.

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

   •      «Что мне удалось сделать вчера?»
   •      «Что я планирую сделать сегодня?»
   •      «Может ли мне что-то помешать?»

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

5. Обзор итогов спринта. В конце спринта команда собирается для просмотра демонстрации инкремента (или для его изучения) в неформальной обстановке. Команда разработчиков представляет рабочие задачи из бэклога, которые на тот момент считаются завершенными, на суд заинтересованных лиц и коллег. Владелец продукта решает, стоит ли выпускать инкремент или нет, хотя в большинстве случаев инкремент выпускается.

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

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

Три важнейшие роли, от которых зависит успех применения Scrum

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

Владелец продукта Scrum

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

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

• Они решают, когда поставить продукт, стремясь делать это как можно чаще.

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

Scrum-мастер

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

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

Команда разработчиков Scrum

На команды Scrum ложится вся основная работа. Они специалисты по принципам сбалансированной разработки. Самые успешные команды сплочены, находятся в одном месте и обычно состоят из 5–7 участников. Чтобы определить размер команды, можно обратиться к известному «правилу двух пицц», которое сформулировал глава Amazon Джефф Безос (в команде должно быть столько участников, чтобы им хватало двух пицц).

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

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

Scrum, Kanban и agile

Scrum — настолько популярная agile-методология, что слова Scrum и agile многие ошибочно используют как синонимы. Но есть и другие методологии, например Kanban, которая тоже пользуется популярностью. Некоторые компании даже предпочитают гибридную модель, сочетающую в себе элементы Scrum и Kanban. Ее называют Scrumban или Kanplan — по сути, Kanban с бэклогом.

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

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

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

За что мы любим Scrum?

Сама по себе методология Scrum проста. Понять

Scrum — обзор популярной методологии Agile-разработки

Scrum и Agile – понятия, которые идут рука об руку. Без понимания, что такое Agile, расшифровка термина Scrum будет неполной.

Итак, Agile – это целая философия, семейство гибких подходов к разработке программного обеспечения (ПО), а Scrum – один из них.

У Scrum есть еще братик – Kanban (тоже из Agile – такие доски с цветастыми наклейками, благодаря которым не простаивают задачи). Этот обзор – краткое сборное руководство по Скрам и описание сервисов, которые его поддерживают. 

В английском scrum – это «толкучка», схватка мяча в таком виде спорта как регби. 

Scrum: что такое и зачем?

Скрам – это фреймворк* для разработки и поддержки сложных продуктов. У него есть роли, события, правила и даже артефакты.

А идейные вдохновители и создатели подхода – Кен Швабер и Джефф Сазерленд. Его вклад в Скрам – это книга «Scrum. Революционный метод управления проектами» – руководство для тех, кто стремится реализовывать проекты быстро и качественно. Рекомендуем к прочтению.

*Фреймворк – «каркас» в переводе с английского. Это набор базовых элементов и правил, на котором строится процесс разработки. 

И кстати, о книге. Ее автор утверждает, что именно Scrum – секрет успеха таких гигантов как Amazon и Google, и что якобы даже ФБР использует эту методологию для разработки данных.

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

Scrum и Kanban – в чем отличия?

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

Чистый Scrum представляет собой более директивную методологию, в которой больше предписаний. А Kanban намного демократичнее и его проще внедрить. 

Канбан. Здесь над задачей может трудиться несколько команд с узким профилем. Например, сначала работают аналитики, затем дизайнеры разрабатывают прототип продукта и уже после подключаются разработчики. При этом в работу могут включаться и универсальные команды. А еще в Kanban в командах нет ролей. Более подробный обзор Канбан читайте здесь.

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

Также есть другие отличия:

• в плане ролей – в Scrum-команде нужно больше ресурсов;
• в планировании – в Scrum приоритеты по задачам выставляет руководитель (владелец продукта), а в Канбан – команда;
• во временных промежутках – в Scrum сроки соблюдаются в обязательном порядке, и время делится на строгие «спринты», а в Kanban задача может находиться в работе столько, сколько нужно;
• в досках – они используются при обоих подходах, но Канбан-доска заполнена постоянно, а в Scrum ее очищают при каждой итерации. 

На чем стоит Scrum: роли, элементы и другое

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

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

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

Роли в Scrum

В Scrum всего 3 роли:

1. Скрам Мастер. Это бизнес-аналитик, руководитель проекта. Его задача – организовывать и проводить совещания и следить за тем, чтобы соблюдалась технология Scrum. Еще он снимает противоречия и направляет команду. 

2. Product Owner. А это уже владелец проекта, его функциональный заказчик. Он отвечает за разработку продукта и ставит задачи команде. Это всегда один человек, а не группа лиц.
3. Development Team. Команда из профильных специалистов – программистов, дизайнеров, аналитиков и т.д. Работает по принципам самоорганизации и самоуправления. Типичный размер команды – 7 человек (плюс/минус 2). За результат команда отвечает как единое целое. 

Артефакты (элементы) Scrum

В Скрам задействуется всего 4 артефакта.

Product Backlog

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

Sprint Backlog

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

Sprint Goal

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

Sprint Burndown Chart

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

Ритуалы (процессы) в Скрам

Подход использует парочку процессов, которые здесь принято называть ритуалами. Каждый из них можно использовать строго по инструкции в соответствии с подходом. В реальной жизни ритуалы пытаются сделать адаптивными, но ключевые принципы остаются неизменными.

Sprint Planning Meeting

Это встреча по планированию спринта, на которой команда выбирает требования из Product Backlog и создает Sprint Backlog. На этой встрече Product Owner отвечает на вопросы участников команды.

Daily Meeting

Ежедневная встреча всей команды – она обязательно должна проходить каждый день, причем в одно и то же время. Интересный момент: на встрече все стоят (потому встречи еще зовут стендапами), потому длительность мероприятия не более четверти часа. В таком коротком временном промежутке каждый должен ответить на 3 вопроса:

• Что я делал вчера?
• Чем я занимаюсь сегодня?
• Какие есть проблемы?

На этом митинге только делятся информацией, и не решают проблемы, а лишь выявляют их.

Sprint Review

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

Retrospective

Это ритуал по обмену опытом в коллективе команды и конструктивное улучшение процесса разработки. На встрече обязательно присутствие всей команды, вместе со Скрам Мастером, а вот Product Owner сам решает – приходить или воздержаться. На встрече озвучивают ответы на ряд вопросов:

• Какие решения нужно принять, чтобы сделать процесс еще более предсказуемым?
• Какие проблемы мешают выполнять обязательства, возложенные на команду?
• Как еще лучше работать и взаимодействовать с Product Owner’ом?
• Какие ошибки допускаются в команде и почему это происходит?

Какие сервисы помогают внедрять Scrum?

Мы собрали небольшой список сервисов, которые помогут использовать Scrum-подход:

• Atlassian – сервис с большим выбором продуктов и Scrum-досками Jira. Здесь есть и Scrum, и Kanban, и смешанная методология. Платформа позиционирует себя как «лучший инструмент для agile-команд». Есть бесплатный период. Можно отслеживать ход работы онлайн с помощью Jira на смартфоне. 

Кстати, сервис Trello (популярная в рунете Скрам и Канбан-доска) – как раз разработка Atlassian. Весь список продуктов Atlassian тут. 

• Scrum-Time. Еще один русскоязычный менеджер задач для управления проектами в духе Agile. Есть бесплатный период, а платные тарифы ну очень со смешной ценовой политикой – до 1$ в месяц. Здесь есть три типа проектов: доска задач в стиле Scrum, но не со всеми возможностями подхода; доска задач со всеми инструментами Scrum; Kanban. Также тут подробно рассказывают о том, что такое Scrum.

Выводы

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

Увы, в наших реалиях внедрение 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 может оказаться полезной в том случае, если с течением времени у заказчика изменится видение того, как должен выглядеть продукт. И наконец, вся полученная на этих этапах информация учитывается во всех последующих спринтах, что помогает оптимизировать процесс разработки наилучшим образом.

The following two tabs change content below.

Маркетолог XB Software с большим опытом в области интернет-маркетинга. Увлекается юзабилити и стремится создавать полезный контент, отвечающий интересам ИТ-аудитории.

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

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

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

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

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

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

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

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

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

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

Пример оформления структуры проекта.

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

Как выглядит бэклог продукта для интернет-магазина.

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

1. Создаем Google-таблицу.2. В столбец заносим базовые требования к продукту. Детали добавим в процессе работы.

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

3. Расставляем приоритеты.

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

4. В третьем столбце прописываем примерную оценку затрат команды.

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

5. Добавляем новые задачи. Если требование выполнено ― удаляем его из бэклога.

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

Важно!

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

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

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

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

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

Так выглядит прототип сайта с комментариями клиента. Источник.

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

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

Как выглядит процесс создания интернет-магазина при работе в Scrum.

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

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

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

Курс «Управление Digital-проектами»

Курс поможет вам оценить себя как менеджера: разобраться и понять, почему у вас что-то не получается. Определить, какие навыки и знания нужно подтянуть. И сделать это, выполняя практические задания.

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Что такое бэклог продукта?

Перейти к основному содержанию

Домой

Икс

• авторизоваться
• регистр
• партнеры
• служба поддержки
• Поиск

• Домой
• Насчет нас
  
  • Назад
  • Насчет нас
  • обзор
  • Почему Scrum.организация
  • Новости
  • Карьера
  • Познакомьтесь с нашими сотрудниками
  • Познакомьтесь с нашими тренерами и тренерами
  • Разнообразие и инклюзивность
  • Связаться с нами
• Повышение квалификации
  
  • Назад
  • Повышение квалификации
  • Обзор курсов
  • Посмотреть расписание занятий
  • Запросить частный класс
  • Найдите тренера или тренера
  • Станьте профессиональным тренером по Scrum
  • Отзывы студентов
  • Профессиональные компетенции Scrum
• сертификация
  
  • Назад
  • Сертификация

.

Как разработать бэклог продукта Scrum

Если вы работаете в сфере технологий, вполне вероятно, что ваша группа разработки программного обеспечения или продукта использует методологию управления проектами Scrum (подмножество методологии Agile), при которой команды выполняют работу в двухнедельных спринтах, чтобы постоянно разрабатывать продукт вместо того, чтобы выпускать сразу весь продукт.

Но, как и в любой методологии управления проектами, ключевым моментом является организация. И отставание по продукту scrum — важный инструмент, который поможет вам в этом.

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

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

Пример отставания продукта (Щелкните изображение, чтобы изменить его в Интернете)

Что такое отставание продукта в Agile?

Согласно официальному руководству Scrum, отставание по продукту составляет «…упорядоченный список всего, что, как известно, необходимо в продукте ».

Бэклог продукта находится за пределами цикла спринта (то есть он содержит работу, которая не будет завершена во время текущего спринта), но сообщает, как будет спринт ваш спринт. Журнал отставания по продукту состоит из отзывов от:

• Команда разработчиков
• Клиент
• Заинтересованные стороны

Пример того, как выглядит отставание по продукту, можно найти в примере выше по продукту.

Почему отставание по продукту имеет значение?

Думайте о отставании по продукту как о способе реализации мозгового штурма или плана продукта. К вам, несомненно, обратятся заинтересованные стороны (или клиенты), у которых есть много идей по улучшению продукта. Не все идеи хороши и не все идеи ценны, но без систематизированного бэклога продукта трудно отличить прекрасные ценные идеи от идей, которые были бы пустой тратой времени. Вот еще несколько преимуществ отставания по продукту:

1. Это организованный список, который легко составить.
2. Расставить приоритеты просто.
3. Его можно изменить при изменении приоритетов.
4. Позволяет сразу увидеть зависимости и упорядочить их.
5. Это позволяет думать о продуктах в долгосрочной перспективе, а не только с точки зрения насущных потребностей.

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

Что в портфеле продукта?

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

• Характеристики
• Функции
• Требования
• Улучшения
• Исправления

Но это не просто список дел. Каждой позиции в портфеле продукта:

• Добавляет ценность для клиента
• имеет приоритет
• По оценкам

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

Хотите узнать, какие еще инструменты Agile могут помочь вашей команде разработчиков работать более эффективно?

Узнать больше

Как создать бэклог продукта

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

Когда вы начнете создавать список невыполненных работ, подумайте об использовании более гибкого программного решения, такого как Jira Software или Lucidchart.Шаблон бэклога продукта Lucidchart — это самый простой способ начать создание бэклога продукта scrum — это живой документ, которым легко поделиться с заинтересованными сторонами и изменить его так, как вам нравится.

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

1. Добавить идеи в журнал

Заинтересованные стороны обычно обращаются к вам с идеями по улучшению продукта

2. Получить разъяснения

Если к вам обращается заинтересованное лицо с предложением о добавлении или исправлении продукта, убедитесь, что вы понимаете:

• Причина добавления или исправления
• Величина ценности продукта в целом
• Характеристики товара

3.Приоритет

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

4. Регулярно обновляйте бэклог

Бэклог — это живой документ; убедитесь, что вы постоянно расставляете приоритеты, уточняете и обновляете отставание.

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

Начните работу быстро с настраиваемым шаблоном невыполненной работы по продукту.

Шаблон журнала невыполненных работ по продукту (щелкните изображение, чтобы изменить его в Интернете)

Приоритизация бэклога продукта

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

Элементы с более высоким приоритетом должны быть усовершенствованы и имеют большую ценность для продукта.

Пункты среднего приоритета должны быть кандидатами на доработку (процесс детализации каждой задачи)

Элементы с низким приоритетом не должны быть зависимостью, и их можно безопасно игнорировать, пока они не станут кандидатами на уточнение.

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

Улучшение продукта

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

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

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

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

Планирование спринта

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

Пример встречи по планированию спринта (Щелкните изображение, чтобы изменить в Интернете)

Подробный пример доски задач Scrum (щелкните изображение, чтобы изменить в Интернете)

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

.

Международный институт Scrum | Официальные сертификаты Scrum

SCRUM INSTITUTE ™

• Сертификаты
  • Аккредитованная сертификация Scrum Master ™
  • Аккредитованная сертификация владельца продукта Scrum ™
  • Аккредитованный сертификат Scaled Scrum Expert ™
  • Agile Scrum Leadership (Executive) Аккредитованная сертификация ™ (NEW)
  • Scrum Trainer Accredited Certification ™
  • Scrum Coach Accredited Certification ™
  • Certified Kanban Expert (Kanban-EXP ™) Certification ™ (NEW)
  • Сертифицированный менеджер проектов Канбан (Kanban-PM ™) Certification ™ (НОВИНКА)
  • Аккредитованный член команды Scrum Certification ™
  • Сертификация Scrum для Java Developer ™

  Сертификация

  • Scrum для веб-разработчиков ™
  • Сертификация Scrum для разработчиков мобильных приложений ™
  • Зарегистрируйте свою программу сертификации Scrum
  • Международный институт шести сигм ™
  • Международная академия сертификации DevOps ™
  • Международная организация по управлению проектами ™ (IO4PM ™)
  • Международный институт тестирования программного обеспечения ™
  • Международный институт MBA ™
• Институт
  • О Scrum Institute ™
  • Ваш блог (8 причин, почему International Scrum Institute ™?)
  • Реестр валидации общих цифровых бейджей и сертификатов Scrum (НОВИНКА)
  • Присоединяйтесь к программе корпоративных партнеров Scrum Institute ™
  • Порекомендуйте Scrum Institute ™ своим друзьям
  • Обзор отрасли и отзывы
  • Официальное признание и клиенты отрасли
  • Часто задаваемые вопросы (FAQ)
  • Свяжитесь с Scrum Institute ™
  • Положения и условия
  • Политика конфиденциальности
• Преимущества
  • Сертификация Scrum Master стала экономичной: Пошаговый план (НОВИНКА)
  • Ваш подарок ждет вас: фреймворк Scrum
  • Ваш подарок ждет вас: фреймворк Канбан (看板) (НОВИНКА)
  • Ваша бесплатная аудиокнига Scrum — Структура Scrum, 3-е издание
  • Ваш бесплатный премиум-тренинг по Scrum
  • Типовые вопросы сертификационного теста Scrum
  • Ваша бесплатная книга Scrum — Структура Scrum, 3-е издание
  • Ваша бесплатная аудиокнига по канбану — The Kanban Framework, 1st Edition (NEW)
  • Бесплатное обучение Канбан премиум-класса (НОВИНКА)
  • Ваши образцы вопросов для сертификационного теста Kanban (НОВИНКА)
  • Подкаст Международного института Scrum ™
  • Слушайте Scrum Institute ™ в подкастах Apple®
  • Слушайте Scrum Institute ™ в Google® Подкасты
  • Слушайте Scrum Institute ™ на Spotify®
  • Форум сообщества International Scrum Institute ™ (НОВИНКА)
  • Программа ежегодных стипендий для колледжей Scrum Institute ™
  • Ваши бесплатные события Scrum с Scrum Institute ™

• Доступ
• РЕГИСТР

.

Объяснение уточнения бэклога продукта (1/3)

Одним из самых сложных действий в Scrum является уточнение бэклога продукта. Во время учебных курсов я получаю много вопросов по этому занятию. Что вы делаете во время доработки бэклога продукта? Как вы предотвратите отклонение обсуждения от цели или слишком большое количество деталей? Кто там должен быть? Когда вы оцениваете? В этой серии блогов вы получите несколько хороших практик и руководств по улучшению, более действенному и наглядному уточнению бэклога продукта.Эта серия будет состоять из трех постов:

1. Перед тем, как принести предмет на собрание
2. Что вы обычно делаете во время встречи, посвященной совершенствованию?
3. Организация встречи по уточнению бэклога продукта

«Состояние готовности»

Целью доработки бэклога продукта является работа с командой Scrum и заинтересованными сторонами (при необходимости), чтобы привести элементы бэклога продукта в «состояние готовности». Что это значит? По сути, это означает, что у команды разработчиков есть идея, что это:

1. Достаточно ясно, чтобы они понимали, о чем просят заинтересованные стороны и почему они просят об этом.
2. Достаточно маленький, поэтому элементы должны быть достаточно маленькими, чтобы их можно было выполнить в течение спринта (обычно за несколько дней работы), чтобы соответствовать определению «сделано».

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

Прежде чем принести его на встречу

Самая важная часть уточнения бэклога продукта на самом деле — это прежде, чем вы начнете дорабатывать. Самый неэффективный вариант использования времени Scrum-команды — это доработка элемента, который не влияет на видение продукта. Для владельца продукта один из первых шагов, когда у заинтересованного лица появляется идея, — это выяснить, что этот человек хотел бы иметь и зачем ему это нужно.Распространенная ошибка заключается в том, что заинтересованная сторона требует решения, «как», а владелец продукта со всем своим энтузиазмом не может понять, что они хотели бы иметь и зачем им это нужно. Я много раз видел, как заинтересованные стороны просили приложение для iPad. Это звучит невероятно ценно, и любой разработчик хотел бы потратить на это время вместо работы над каким-нибудь устаревшим приложением. Однако, если причины решения неясны, оно, скорее всего, окажется где-нибудь в магазине приложений.

Таким образом, знание причин, лежащих в основе идеи, позволяет Владельцу продукта легко судить, способствует ли эта идея достижению долгосрочного видения продукта.В противном случае владелец продукта может подумать о том, чтобы поработать над этим в любом случае, поскольку это открывает новые рыночные возможности, но чаще всего было бы лучше сосредоточиться на тех элементах, которые способствуют тому, что команда существует. Если все флажки отмечены, то будет принято самое важное решение. Имея знания, которыми обладает Владелец продукта, стоит ли создавать эту идею? Есть ли у этого предмета шанс быть поднятым командой или он окажется где-нибудь в конце бэклога продукта. Я видел, как Владельцы продуктов собирали все вопросы, которые когда-либо задавали в течение 8 лет, и в итоге оставляли 12 000 пунктов в Журнале заказов продуктов.Полная трата времени и сил. Даже бэклог продукта из 100 элементов может оказаться слишком большим для одной команды. Как владелец продукта, вы должны спросить себя, насколько велика вероятность того, что этот предмет будет забран, если изначально он будет помещен на 40-ю позицию в бэклоге продукта?

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

Этапы готовности

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

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

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

.