Мини-справочник и руководство по scrum

Особенности бэклога

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

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

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

Характеристики

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

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

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

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

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

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

Метод RICE Score

RICE

• Reach — это охват
• Impact — влияние
• Confidence — уверенность в вашей оценке охвата, влияния и трудозатрат
• Effort — трудозатраты

Reach (Охват)

Например:
Фичей будет пользоваться 800 пользователей в месяц.
1000 пользователей вовлечены в онбординг, и 70% — только 700 пользователей увидят эту фичу.

Impact (Влияние)

4. Добавляют ценности продукту и отстраивают нас от конкурентов

Confidence (Уверенность в оценке)

Например
Проект A: У менеджера продукта есть количественные показатели для влияния фичи, и оценка трудозатрат. Таким образом, проект получает 100% -ную оценку уверенности.
Проект B: У менеджера продукта есть данные по охвату и трудозатратам, но он не уверен в отношении фактора влияния. Проект получает коэффициент доверия в 80%.
Проект C: Данные охвата и влияния могут быть ниже, чем предполагалось. Трудозатраты могут быть выше. Проект получает 50%-ную оценку доверия.

Например:
Проект A займет около недели планирования, 2 недели дизайна и 3 недели для разработки, поэтому трудозатраты составят 2 человеко-месяца.
Для проекта B потребуется только неделя планирования, 1-2 недели для разработки и не потребует дизайна. Трудозатраты будут равны 1 человеко-месяцу.

Как использовать RICE и ICE Scoring?

SwimlanesLabelsColumns

• Backlog — здесь вы собираете все идеи и фичи
• Next Up — сюда вы перемещаете фичи, над которыми хотите работать в ближайшее время
• Specification — тут вы собираете требования и пишите спеки на фичи
• Development — фичи находятся в разработке, и здесь вы можете отслеживать их текущий статус
• Done — фичи были успешно залиты на прод и теперь доступны вашим пользователям.

Оценка в Hygger по RICE

PushPush

• создается задача по реализации фичи на доске разработке — на Канбан или Спринт доске внутри Hygger (да-да, Hygger поддерживает Kanban и Scrum). В будущем мы добавим интеграцию с Jira и с другими трэкерами задачи, так как прекрасно понимаем, что многие команды используют для разработки Jira и уйти с нее на что-то другое — анрил
• задача на бэклог-доске и задача на доске разработки линкуются между собой
• когда задача на доске разработке будет полностью выполнена, задача на бэклог-доске также будет перенесена в done-колонку.

Инструменты управления бэклогом

Чтобы управлять бэклогом, его нужно где-то вести. Самым распространенным инструментом в agile командах, являются: Jira, Trello, Redmine.

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

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

Кто выбирает задачи для бэклога?

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

Также важно поддерживать контакт с командой разработчиков, чтобы понимать стоимость и сложность определенных требований

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

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

Метод оценки ICE

ICE Scoring: Как это работает?

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

В качестве примера, применим это к фиче «Виджеты для Dashboard»:

Влияние: насколько это будет эффективно? Что это даст нашим пользователям и их целям и задачам?

Легкость реализации: насколько легко будет разрабатывать, тестировать и запускать эту фичу?

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

Недостатки ICE

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

Многокомандное Уточнение Бэклога Продукта (Multi-team PBR)

Многокомандная сессия PBR — это когда несколько команд вместе находятся в одной комнате, проводя PBR. На встрече присутствуют эксперты и все члены участвующих команд.

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

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

Многокомандная сессия PBR может быть дополнением или заменой командного PBR.

Перевод — Господчиков Сергей

Какие задачи брать в бэклог

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

• Функциональные
• Эволюционные
• Аналитические
• Баги

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

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

Оценка задач

1. Игра престолов
   Приходит какой-то «верховный босс» и говорит, что из бэклога должно быть сделано прямо сейчас, и спускает вам оценки сверху. Это может быть технический директор, который расставляет оценки всех задач и говорит, что какая-то задача делается за столько-то, такая-то за столько-то. Или это можете быть вы сами 🙂
   Такое часто встречается (хотя сами мы так стараемся не делать). Обычно по ходу декомпозиции какие-то вещи уточняются, появляются какие-то детали и нюансы. Часто с этими оценками могут быть не согласны разработчики или реальность может быть немножко сложнее, чем вы себе запланировали. Плюс у бизнеса всегда есть подсознательное понимание, за какое количество часов он готов купить эту фичу, а за какое уже не готов (и это всегда где-то на грани).

2. Оценка из теории вероятности
   Берутся три оценки по времени: оптимистичная, пессимистичная и реалистичная, и строится график, называемый Гауссианой.

   Для расчета наиболее вероятной оценки применяют формулу: (Оптимистичная + (Реалистичная * 3) + Пессимистичная) / 6.

   В идеале наиболее вероятная оценка будет чуть дальше, чем реалистичная.

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

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

3. Planning Poker
   Это наиболее простой и «чистенький» способ получить нормальные оценки, обсудить какие-то фичи, нюансы, детали. Даже на верхнем уровне по бэклогу можно такое проделать.Минус Planning Poker — это довольно ресурсоемкая операция, поскольку нужно собирать всю команду вместе и читать бэклог. Но если вы применяете методы вроде Story Mapping, вам всё равно нужно собираться командой и делать предварительные оценки (хотя бы в днях, неделях — крупных величинах).Плюсы Planning Poker
   1. оценки распределяются в зависимости от опыта сотрудника, и здесь можно договориться;
   2. оценки даются сначала закрыто, и только потом открываются — нет давления авторитета (как в случае с оценками, спущенными «сверху»).

Ситуация

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

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

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

Хорошие новости — есть несколько методик, которые помогают в этом случае:

1. договариваться о приоритетах — выбирать, что важнее, а что можно отложить;

2. устанавливать критерии приоритизации бэклога (чуть менее субъективные, чем чья-то галлюцинация — увы, совсем без субъективизма не получится).

Бэклог

1. Вы не пытаетесь запланировать каждый шаг, каждый ресурс и человекочас. Вы согласовываете общие высокоуровневые KPI и начинаете проект, сэкономив на этом уйму времени.
2. Вы берёте те ресурсы, которые у вас есть и идёте с ними превращать согласованные KPI в пользовательские истории. И выгода здесь не только в том, чтобы точно понять, какая картинка конечного продукта в голове у пользователя. Это также ваш шанс с помощью уточнений и разъяснений сформировать эту картинку в нужную и практичную сторону. (Запомните! Не существует такого понятия, как «слишком много change management-а)
3. Из этих пользовательских историй, как настоящие декомпозиторы, вы декомпозируете себе симпатичный маленький бэклог и принимаетесь ваять прототипы, визжа и похрюкивая от радости понимания и осмысленности происходящего.
4. На первый же (ну окей на второй) УК вы притаскиваете этих своих недопиленных уродцев, не стесняясь ничуть. Ведь это ПРОТОТИПЫ! Они не должны быть совершенством! И в этот период, если кто-то в вашей команде начинает вставать в позу, крича, что он «привык делать всё на совесть», что «отвечает за свою работу», и что «готово, только тогда, когда готово», гоните его из команды. Или объясните ему понятие MVP (минимально жизнеспособный продукт). Не нужна ложка с инкрустациями и вязью, когда всё уже съедено. Ложка дорога к обеду.
5. Теперь. На этом же УК вы получаете самое ценное, что может получить менеджер проекта – РАННЮЮ ОБРАТНУЮ СВЯЗЬ ОТ ЗАКАЗЧИКА! Когда ещё только всё началось, когда менять можно что угодно и куда угодно.
6. Вы собираете эту обратную связь и уходите, чтобы принести через неделю немного улучшенные прототипы. Пусть они всё ещё не идеальны, но вы добавляете ценность с каждым разом и так начинаете РАБОТАТЬ КОРОТКИМИ ИТЕРАЦИЯМИ.
7. Так как все заинтересованные стороны понимают и разделяют ваше видение, и, более того, сами принимают участие в создание финального продукта, у всех формируется чёткое понимание того, как быстро идет проект, хватает ли ресурсов, где нужно ускориться и отчего, очевидно, нужно отказаться как от нежизнеспособного, то вы не тратите время на многочисленные согласования, «новые вводные» и оправдание чьих-нибудь ложных ожиданий, а внедрение проходит в спокойной рабочей атмосфере.
8. Кроме того теперь вы не только успешно внедряете проект, но и строите здоровые, продуктивные и позитивные отношения со спонсорами и клиентами, закрепляя свою репутацию гениального проджект менеджера и команды мощнейших профессионалов.
9. Вы таки внедряете проект, который так поразит привыкших к мертвецам акционеров своей живостью, что они начнут подумывать об угловом кабинете для вас и об IPO для своей компании!

Методы приоритизации задач

Story Mapping

Где и как применятьПлюсы Story Mapping

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

Value & Effort (или Lean Prioritization) для идей

1. Значимость фичи
   Значимость каждой фичи с точки зрения бизнеса — это примерно то же, что и «ценность для бизнеса» в обычном бэклоге. Величина оценивается в условных единицах, лучше всего — в деньгах. В целом, любой параметр, который вы оптимизируете, можно брать за Value. Это может быть количество пользователей, которых вы привлечете в проект, или уменьшение оттока пользователей в проекте.
2. Количество усилий, которое необходимо затратить на каждую из фич
   Тоже можно считать, что это оценка в часах (estimate), как в бэкглоге. Но можно измерять и в Story Point-ах (сравнительная оценка требований относительно друг друга) или в человеко-часах.

Где и как применять

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

MoSCoW

M — Must HaveS — Should HaveC — Could HaveW — Would Have
Пример
Допустим, вы разрабатываете автомобиль. Must Have будут колеса, руль, ходовая часть, двигатель. Should Have — освещение ночью, сидения вместо стульев, двери и всё такое прочее. Could Have — автоматическая коробка передач и так далее. Таким же образом можно разобрать любой проект, где Must Have будет эдаким MVP.

Kano

Пример
Вы планируете делать следующие релизы и опрашиваете группу людей. Кто-то из них может сказать: «А вот вы там платную функцию сделали, из-за неё продукт стал хуже, фи!» Только потому, что она за деньги, эта функция покажется кому-то ненужной. Хотя для бизнеса это может быть ключевая вещь, которая приносит прибыль.

Классический метод приоритизации баг-листов

Критические багиКритичное юзабилити и забытые фичиНекритичные багиНекритичное юзабилитиТекстыХотелки / не будем делать / на усмотрение менеджера

Выбор идей с помощью визуального инструмента Backlog Priority Chart

• Quick Wins – идеи с высоким Value и низким Efforts. Это очень полезные фичи, которые легко сделать. Эти задачи лучше делать в первую очередь. Быстро сделали — быстро получили результат.
• Big Bets – идеи с высоким Value и Efforts. Задачи, которые настолько полезные, насколько и сложные/длительные в реализации. Эти задачи можно делать во вторую очередь. Делать их придется дольше чем Quick Wins, но зато польза от них будет такая же большая.
• Maybes – идеи с низким Value и Efforts. Задачи, которые не дают особой пользы, но их можно легко сделать. Такие идеи лучше отложить в долгий ящик.
• Time Sinks – идеи с низкой полезностью, но с высокими трудозатратами. О таких идеях лучше вообще забыть.

Заключение

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

А как у вас обстоят дела с приоритезацией? Ждем ваших комментариев и отзывов.

Техники скоринга

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

ICE Scoring

Аббревиатура состоит из трех параметров:

• Impact — влияние на продукт либо с точки зрения бизнеса, либо сколько денег принесет, либо что эта фича даст, насколько она крутая. Параметр задается в диапазоне от 1 до 10.

• Confidence — уверенность в оценке сложности или в оценке влияния фичи. Например, вы придумали какую-то функцию и думаете, что она хорошо повлияет на проект. Аналитики не было, данные неточные и пока приоритет основывается только на вашем личном мнении. Чем ниже уверенность в вашем личном мнении, тем ниже показатель. Задается также в диапазоне от 1 до 10.

• Ease — трудозатраты или простота реализации. Также задается от 1 до 10. Чем проще функция, тем у нее выше балл.

Как измерять уровень уверенности — источник

Для получения ICE нужно умножить эти три параметра — это и будет приоритет на реализацию.

Плюсы: быстро и просто.

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

RICE Scoring

Здесь используется 4 параметра:

• Reach — охват: сколько пользователей у нас от этой фичи получат хоть какое-то удовлетворение, либо заметят эту фичу, либо будут ей пользоваться. Можно измерять количественно: например, 500 миллионов пользователей ощутят на себе эту функцию. Можно измерять в процентном отношении — например, 30% пользователей будет использовать эту фичу.

  

  

  

  

  

  

  

  

  

  

• Impact — влияние: насколько эта функция на самом деле нам нужна, насколько она нам поможет, насколько функция крутая.

• Confidence — уверенность: аналогично с ICE Scoring, уверенность в наших оценках и прогнозе влияния.

• Effort — трудоемкость.

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

История одного релиза

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

Наша фронтенд-команда работает двухнедельными спринтами. На каждый публичный релиз приходится 6-8 таких спринтов. Однажды, когда мы находились в середине цикла и оставалось буквально 3 спринта, к нам приходят владелец продукта с дизайнерами. «Нужно сделать редизайн, очень желательно успеть к релизу. Вот макеты, которые всем нравятся».

Новый макет выглядит, действительно, лучше прежнего. Но нужно поменять довольно большую часть внешнего облика системы. Заводим задачу «сделать редизайн», оцениваем. Получается, что если сразу начать, то теоретически к концу спринта можно успеть. Есть некоторые нехорошие предчувствия, но мы всё равно начинаем. И к концу спринта мы, конечно, не успеваем. Ну уж в следующем-то успеем?

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

В общем, это было непросто, но мы справились. История с редизайном была закончена только в самом конце спринта. С компромиссами и кучей костылей вливаем в master, и идём на ретроспективу.

Остается последний спринт релиза

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

Разбор полетов

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

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

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

Так при чем тут управление рисками?

А его в этой истории и не было.

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

Мини-справочник Scrum

ScrumProduct Owner

• определение элементов бэклога продукта;
• правильное расположение элементов для оптимизации достижения цели;
• обеспечение понятности и прозрачности Product Backlog;
• обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
• общая оптимизация для достижения наибольшей ценности работы Development Team;
• ответственность за понимание бэклога командой разработки.

Scrum TeamScrum MasterDevelopment TeamStakeholdersUserProduct BacklogEpicUser StoryTaskSprintSprint GoalSprint Planning MeetingScrum PokerStory PointsDaily Scrum MeetingSprint ReviewSprint Retrospective MeetingDefinition of Done (DoD)VelocityBurndown ChartBurnup ChartAbnormal Termination

Источники рисков: технический долг

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

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

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

Технический долг зафиксирован в бэклоге

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

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

Рефакторинг и новая функциональность — отдельные задачи

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

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

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

Организационное

Дейоф

day-offвыходнойПримеры употребления:

• «У меня завтра дейоф»
• «Он взял дейоф за свой счет»
• «Почему я не в курсе о ее дейофе?»

Драйвер

driverводительПримеры употребления:

• «Для этой инициативы нужен драйвер»
• «Кто будет драйвить этот проект?»
• «Как драйвер ты должен периодически всех пинать, чтобы работали»

Консёрн

concernтревога, участиеПримеры употребления:

• «У меня есть консёрны относительно этой идеи»
• «Мой консёрн в том, что это может не работать»
• «А какие у тебя консёрны?»

Окиары

OKRObjectives and Key Resultsцели и ключевые результатыПримеры употребления:

• «Когда мы узнаем окиары на следующий квартал?»
• «У команды не может быть окиаров, они есть только у юнитов»
• «Впечатляющие окиары!»

Оффер

offerпредложениеПримеры употребления:

• «Ему выслали оффер, ждем ответа»
• «Кандидат отклонил наш оффер»
• «По итогам собеседования мы хотим сделать вам оффер»

Поинт

pointточкаpoint of viewПримеры употребления:

• «Мой поинт в том, что надо заранее планировать работу»
• «Согласна, в этом есть поинт»
• «Какие поинты у этого решения?»

Вот здесь вторая

Бэклог продукта: на шаг к пользователю

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

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

Собирая “боли” пользователей вы формируете гипотезы

А правда ли это настолько важно для него? Может быть, это просто очередное “хочу”? Чтобы проверить гипотезы на жизнеспособность и превратить их в задачи, вы делаете следующий шаг. Проводите а/б тесты, количественные исследования (опросы) и прочее, чтобы сделать вывод: “Да, это и правда важно” или “Легко и без этого проживут”

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

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

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

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

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

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

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

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

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

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

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

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

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