какое поле обязательно должно быть добавлено в фильтре для поиска неоцененных задач в бэклоге
Идеальный бэклог продукта
И снова здравствуйте. Перевод данной статьи был подготовлен в преддверии старта курса «Agile Project Manager в IT».
Здоровый бэклог продукта является необходимым условием для успешной Scrum-команды. Вместо того, чтобы сосредотачиваться только на доработке пользовательских историй для предстоящего спринта, предусмотрительные Scrum-команды инвестируют в доработку бэклога продукта, чтобы повысить прозрачность, сосредоточиться на своем видении и сохранить согласованность действий. Прозрачность – это гораздо больше, чем просто предоставление информации, заинтересованная сторона должна иметь возможность получить искомую информацию в течение нескольких секунд.
Взгляните на бэклог продукта, который представлен ниже, чтобы понять, что я подразумеваю под идеальным бэклогом. Этот бэклог четко отражает работу предстоящего спринта, долгосрочную дорожную карту, ключевые контрольные даты и формулирует видение будущего – и все на одной странице! Взгляд на такой бэклог позволяет всем заинтересованным сторонам, клиентам, членам команды и руководителям быстро сформировать понимание о состоянии продукта. Самые последние ретроспективные действия находятся сверху. Все пользовательские истории подвергаются оценке. Вне зависимости от типа аудитории, каждый ее член получит необходимую информацию меньше, чем за 30 секунд.
Где умирают пользовательские истории
Сталкивались ли вы когда-нибудь с бэклогом продукта, когда пользовательские истории следующего спринта четко определены, но за под ними куча неприоритезированного мусора? Я называю это бэклогом-кладбищем. Со временем это кладбище растет. Пользовательских историй слишком много, чтобы следить за ними постоянно, поэтому оценки устаревают. Такой бэклог больше не помещается на один экран, и люди больше не возвращаются к нему, даже Product Owner. Это кладбище порождает нездоровое поведение внутри Scrum-команды. В поведении это проявляется по-разному: у команды возникает противоречивое представление о том, что они делают и зачем они это делают, а Product Owner тратит свое время на создание версии бэклога продукта в Power Point, чтобы донести до команды его текущий статус. В свою очередь стейкхолдеры создают и поддерживают свою собственную версию бэклога для дорожной карты продукта, и каждая команда говорит на своем языке, а конфликт возникает в тот момент, когда появляется понимание, что интерпретация бэклога продукта у этих команд разная. Этот антипаттерн, укрепившийся в отношениях между бизнесом и Scrum-командами, проявляется, когда бэклог превращается в заброшенное пространство небольших пользовательских историй, над которыми уже никто не будет работать и ценность которых ставится под сомнение.
Как воскресить бэклог продукта, чтобы он стал идеальным?
Итак, каким образом команда может получить из бэклога-кладбища идеальный бэклог продукта?
На что больше похож ваш бэклог: на идеал или на кладбище? Как бэклог продукта влияет на поведение команды и результаты? И что вы можете с этим сделать?
А если вы хотите разобраться в том, чем отличаются Project и Product, выяснить, как между ними распределяются обязанности и определить разницу в софт скиллах для этих ролей, записывайтесь на бесплатный урок по курсу.
Бэклог задач: Оценка и приоритезация
Планирование и определение приоритетов является важнейшим элементом создания продукта. От навыков руководителя проекта, в нашем бизнесе — продюсера, зависит насколько эффективно будут использованы ресурсы компании, какой выйдет стоимость разработки, на сколько продуктивно будет работать каждый член команды, какими будут сроки. Все эти аспекты зависят от грамотного планирования и расстановки приоритетов для каждой задачи.
Бэклог
Список всех задач (Backlog) проекта, начиная от сырых идей и заканчивая хорошо декомпозированными и описанными, готовыми в работу, планами спринтов. Этот список задач, будет основным артефактом продюсера, инструментом для достижения максимальных показателей эффективности в работе над проектом.
Бэклог является открытым, и добавлять в него задачи (идеи, баги, пожелания) может кто угодно: от Стейкходера до тестировщика. После того, как задачи попадают в бэклог, продюсер определяет их Бизнес ценность, а команда Сложность. Именно эти два компонента определяют, когда задача идет в работу.
Эпики и подзадачи
При планировании, возникновении идеи или бага в бэклог заносятся Эпики — корневые задачи / цели. Например в игру нужно внедрить ежедневный бонус, чтобы усилить механизмы удержания. Продюсер вписывает эпик «Добавить Дейли бонус» и собирает команду. Вместе они разбивают задачу на подзадачи. Дизайнер интерфейсов говорит, что ему надо нарисовать пару скетчей, и просит художника подготовить графику согласно стиля игры. Программист просит гейм диза расписать принципы работы, перед тем как собирать окно. Бэкэнд спрашивает на сколько много можно добавить бонусов, и нужно ли синхронизировать сбор бонусов с часовым поясом. Команда обсудила идею Дейли бонуса, и теперь её можно разбить на подзадачи. Подзадачам присваиваются метки, определяющие тип работы над задачей — программирование, графика или гейм дизайн.
Декомпозируя эпик, менеджер проекта выстраивает иерархию задач, которые могут делаться параллельно, и задач, которые выступают блокерами для других. Например задача по скетчированию персонажа является блокером к задаче по анимации персонажа.
Когда в бэклоге накапливается достаточное для обсуждения количество эпиков с высокой бизнес ценностью, продюсер проводить предпланирование, на котором разбивает пул задач на подзадачи.
Оценка задач
После предпланирования гейм дизайнеры берутся за детальное описание задач, создают документ, полностью объясняющий как работает новый компонент игры, как выглядит, и как влияет на игру и её процессы. Как только описание готово и утверждено продюсером проекта, оно рассылается команде на ознакомление, вместе с приглашением на планирование.
На планировании, гейм диз и продюсер доносят до команды цели и суть каждой новой задачи, после чего команда задет вопросы, чтобы лучше понять, что же должно получиться на выходе. Разобравшись с задачами, каждый член команды дает свою оценку. Оценка может быть в рабочих часах или в неких очках — Story Points.
Я рекомендую для оценки сложности использовать «Ряд Фибочначи» — последовательность чисел, где каждая следующая равна сумме двух предыдущих: 1, 2, 3, 5, 8, 13, 21…
1. очень легко — задача, которая делается за 10-15 минут (например, перекрасить кнопку).
2. легко — задача, которая делается в пределах 1 часа. Таких задач в день можно сделать порядка 10.
3. нормальная сложность — задача, для решения которой не нужно ничего созидать, но ее реализация требует времени. В день таких задач может быть две или три.
5. сложно — задача, решение которой требует созидания, анализа. Такая задача не решается за 1-2 дня и требует подготовки.
8. очень сложно — задача, решения которой у исполнителя нет. Требуется поиск решения, дополнительные исследования, разные подходы к реализации. Такая задача занимает весь спринт (неделю).
21. оценка: ХЗ — задача, которую исполнитель не может оценить, по разным причинам. Такие задачи в работу не берутся, так как нуждаются в дополнительной пред обработке. Возможно задачу нужно разбить на несколько подзадач, детализировать описание, или собраться на мозговой штурм и обсудить подходы к реализации.
Оценивать задачи нужно только тогда, когда утверждено описание. Каждый член команды оценивает задачи исходя из своего опыта и знаний. Оценивая задачу, команда берёт на себя ответственность за сроки её исполнения. Эпику присваивается наивысшая сложность всех подзадач.
После оценки задач Менеджер проекта может включать в состав спринта, учитывая эстимейты команды.
Определение Бизнес Ценности
Бизнес ценность задачи — это оценка важности задачи для текущей стадии проекта. В зависимости от стадии проекта, одни и те же задачи имеют разную бизнес ценность. Например, если у игры пользователи отваливаются на туториале, то задача по контент апдейту вообще не важна и будет иметь минимальную оценку. А у приложения с миллиардным DAU, которое на рынке уже некоторое время, контент апдейт будет напрямую влиять на доходы, соответственно задача по нему будет иметь высокую ценность.
Для оценки ценности используем тот же «Ряд Фибоначчи», умноженный на 1000, чтобы визуально отличался от оценки сложности.
Вот мои рекомендации для запущенного приложения.
21 000 — Критически важная задача — задача, которая влияет на работоспособность приложения, на его корректурную работу. Такие задачи берутся в работу в первую очередь.
13 000 — Задачи, от которых напрямую зависят финансовые показатели — например, добавление системы акций в игру, активация пей-воллов, изменение кривой сложности…
8 000 — Косвенно, влияющие на монетизацию задачи — такие, как сплит платежного меню, изменение воронки оплат…
5 000 — Задачи, на прямую влияющие на возврат пользователей, их удержания — например: прикрутка ФБ-коннекта, использование OG, и обмен подарками в игре…
3 000 — Задачи, влияющие на вовлечение пользователей — тут и графика, и анимации и звук, и прочие компоненты игры, на основании которых пользователь складывает впечатление от игры.
2 000 — Идеи, которые хотелось бы добавить в игру, но их полезность не очевидна. Тут могут быть разные мысли, вплоть до замены дракона на кошку на прелоадере.
1 000 — Очевидная чушь, которая попала в бэклог. Задачи, которые надо запомнить, чтобы не делать. Да такие тоже есть))
В зависимости от сильных и слабых сторон проекта, ценность того или иного компонента может меняться. Например приложение хорошо зарабатывает, но виральности ни какой — в этом случае задачи на привлечение будут иметь ценность выше, чем у задач по монетизации.
Когда приложение ещё не выпущено, ценность задачи определяется её ближайшими milestones и дороговизной переделки задачи, в случае ошибки. Так сказать, в работе есть точки не-возврата, такие как выбор архитектуры или сеттинга имеют более высокую ценность, чем внедрение социальных компонентов или обвесов игры. Обвес всегда можно переделать, и это не займет много времени. А вот переделать архитектуру — это практически не реально и очень дорого.
Расставляем приоритеты
После того, как у каждой задачи в бэклоге есть оценка сложности и бизнес ценность, можно легко расставить приоритеты по следующему принципу:
Планируя работу над проектом мы всё время сфокусированы на задачах, которые дадут наибольший профит наименьшими усилиями.
По-понятиям:
Эта методология придумана не мной. Такой способ работы мне подсказали знающие люди, я его адаптировал под свои проекты и успешно применю последние 2 года. Полагаю, такой подход поможет оптимизировать и ваши процессы разработки приложения.
Backlog в управлении продуктом: что делать, когда идеи нарастают «как снежный ком»
В условиях высокой конкуренции важно концентрироваться на самом приоритетном. Конкуренты постоянно выпускают новые фичи. Их так много, что просто не хватает времени на их изучение. Клиенты в развитии продукта также играют важнейшую роль, предлагая улучшения, конструктивную критику и свежие советы. В общем, идеи растут «как снежный ком».
В любом продукте, скорее всего, хотят внедрять те функции, которые поднимут на новый уровень доходы, увеличат возвраты (retention) или виральность (virality).
Здорово, если вы уже внедрили какой-либо количественный фреймфорк, например, Pirate Metrics (AARRR). Он помогает сконцентрироваться на самых важных этапах вашей воронки продаж, а именно на AARRR (acquisition, activation, retention, referral, revenue).
Однако вернемся к большому скоплению идей и инициатив.
Определяем проблему
Итак, проблема следующая — у вас скопилось много идей из разных источников: из Intercom, Zendesk, Satismeter, из личных бесед с клиентами, от сотрудников. Вам становится все сложнее выбирать идеи для очередного спринта. Причем, цена ошибки очень высока: вы рискуете сделать такую фичу, которая будет невостребованная аудиторией и не принесет ожидаемых бенефитов. Например, она не увеличит конверсию в регистрацию или ARPD.
Backlog постоянно растет и управлять им становится все сложнее — менеджер продукта тратит много времени на его аудит, во время которого он просматривает идеи, расставляет приоритеты, выбрасывает то, что перестало быть актуальным. Каждый раз нужно мониторить все идеи. Самое время “перелопатить” известные техники приоритизации и найти свое решение.
Находим решение
Мы в Hygger.io предлагаем системное решение этой проблемы выбора. Решение состоит из трех основных блоков:
Структурирование бэклога
Как правило, Backlog — это обычный список. В Hygger бэклог — это двухмерная Kanban доска. Более того, пользователя предлагаются Labels (тэги) и Swimlanes. Этого более чем достаточно, чтобы структурировать ваш бэклог любого размера.
Например, колонками на этой Kanban доске могут быть этапы работы над идеями:
Вместо процесса вы можете сделать в колонках релизы, чтобы распределить идеи. Кстати, Hygger умеет считать Capacity для колонок — чтобы вы могли равномерно распределять задачи по релизам.
С помощью Swimlanes вы можете разделить идеи. Например, так:
Лейблы можно использовать для чего угодно, например, для того, чтобы отметить идеи конкретных клиентов. Или идеи конкретных сотрудников. Или отметить особо важные идеи. Или отметить Сandies — мелкие фичи, которые делают продукт “вкуснее” для пользователей. Эти Сandies усилий практически не требуют, на скорость работы не влияют. Но замечая их, пользователи чувствуют заботу о них и больше доверяют.
Идеи упорядочены по полочкам, теперь можно приступать к их оценке. Оценка поможет вам в будущем сделать правильный выбор.
Оценка идей по Value и Effort
Оценить все идеи удобно с помощью двух критериев: Value или Impact и Effort.
Говоря абстрактным языком, Value — этот вклад, который идея или фича может дать в ваш продукт. Для корректной оценки вам нужно сначала понять, что вы хотите улучшать с помощью этой фичи.
Допустим, что вы внедрили Pirate Metrics (AARRR), тогда ваши цели могут быть такими:
Процесс оценки идей по Value в компании такой:
Когда вы оценили все идеи, вы можете переходить к этапу выбора идей. Не обязательно делать это сразу после окончания оценки — иногда лучше взять паузу и дать идеям отлежаться. Вы можете получить новые данные, например, из внешней среды, которые могут повлиять на оценку Value или Efforts.
У нас в компании процесс пересмотра идей является постоянным и фоновым. Но мы это делаем на графике, а не на Kanban доске, потому что на графике самые важные идеи четко отделены от всякой ненужной мелочи. Вы можете пересматривать идеи от самых важных до ненужных, если вам позволяет время. Главное то, что важные идеи вы пересматриваете вначале, и на них у вас всегда найдется 5 минут.
Выбор идей с помощью визуального инструмента Backlog Priority Chart
Те идеи, которые вы оценили, вы можете увидеть на графике.
На графике есть две шкалы — Value и Efforts, а также 4 квадранта:
График удобен тем, что позволяет оценивать идеи друг относительно друга. Во время оценочной сессии идеи оцениваются, как правило, независимо друг от друга. Но когда мы начинаем сравнивать идеи, которые оценены одинаково, друг с другом, явно какая-то идея будет более полезной или менее трудозатратной. Исходя из этого, мы можем скорректировать оценки идеи, их Values или Efforts.
Итак, вы оценили идеи, отобрали с помощью графика самые полезные идеи, и теперь вы можете отправлять их в разработку — на Kanban доску или на Спринт-доску.
Заключение
Подводя итог, кратко выделим главное:
Полная схема scrum — работа с бэклогом и релизный цикл
В четырнадцатой статье серии «Менеджмент цифрового мира» я расскажу, откуда появляется бэклог и как с ним работать для получения реалистичного прогноза на итерацию, а также про планирование цикла релизов. И этим завершу рассказ про схему scrum.
Отмечу, что это будет расширенный вариант схемы, по сравнению с тем, что я рассказывал в предыдущих статьях, и он обычно не входит в рассказ для начинающих и тренинг для скрам мастера. Тем не менее, он не является каким-то секретным знанием, все это можно найти в материалах для Product Owner и даже в продвинутой версии тренинга для них.
Я в 2013 услышал все это как раз на тренинге Джефа Паттона, и был уверен, что это входит в стандартную версию. Но потом мне объяснили, что это мне просто крупно повезло, а стандартные тренинги на сертификат Product Owner, который проходило несколько моих знакомых содержит гораздо меньше материала. Собственно, в этом и состоит смысл проходить даже начальные тренинги у топовых специалистов-практиков – они расскажут много больше, чем обычный тренер. И мне повезло учиться Scrum у Джефа Паттона и Хенрика Книберга, я им очень благодарен, как и другим топовым специалистам, на тренингах которых я был – Ивару Якобсону, Джеффу де Люка и другим.
Возникает естественный вопрос: а насколько подробно необходимо прорабатывать задачи, кто именно их оценивает. На этот вопрос есть следующий функциональный ответ: содержание задачи должно быть проработано настолько, чтобы (а) Product Owner был уверен, что выполнение этих работ принесет стейкхолдерам желаемую ценность и (б) Команда могла оценить трудоемкость выполнения этих работ на планировании. Не меньше, но и не больше. Потому что именно на основании оценки задач и принимается решение, что помещается в спринт, а что – нет.
Как мы говорили, в Scrum деятельность состоит из выполнения задач, помещенных в Product backlog. Каждая из них несет некоторую ценность и имеет содержание – набор работ, которые надо выполнить. Откуда же появляется бэклог?
Достижение цели – и есть ценность. Формулировки – важны. Классический примеры из новейшей мифологии касаются Стива Джобса. «Я хочу слышать музыку, чтобы получать удовольствие», а вовсе не иметь 100500 записей в своей коллекции – идея, которая породила iPod.
Как легко заметить, в формулировке для iPod часть про роль – отсутствует. Это не значит, что она не обязательна, просто она появится наследующем уровне детализации – вам надо описать представить пользователей, и для этого есть техника персонажей: вы описываете типичного представителя социальной группы и его потребности относительно продукта, в случае iPod – какую музыку любит, где и как много слушает, какое нужно разнообразие и так далее. Техника персонажей требует олицетворения и именования конкретного человека, за которым будет стоять группа, соотнесение его с социумом, очень полезно, чтобы у него появилось лицо, и вообще вы могли говорить от его имени. Эта техника возникла с развитием массового web при работе с User eXperience (UX), но может применяться для любых продуктов и услуг, а не только в IT.
В целом вы детализируете свою ценность по группам пользователей и по составу, но при этом придумываете принципиальный способ реализации, это как раз часть о том, что именно делает пользователь и каким образом. Без особых подробностей, но идея должна быть реализуема, иначе это фантазии.
Для уже существующего бизнеса вместо ценности для пользователей можно использовать продвижение по векторам Objectives and Key Results (OKR) для развития бизнеса. Например, если стоит задача захвата регионального рынка, то вы планируете разные рекламные и маркетинговые акции с целевыми аудиториями и ожидаемым эффектом, но при этом не надо забывать о насыщении рынка количеством товара, адекватным прогнозируемому росту спроса. И так далее.
Далее есть интересный такт – последовательность захвата мира. Вы определяется последовательность, в которой группы людей начнут использовать ваш продукт, и причины, по которым они это сделают. При этом учитываете, что люди начинают использовать новое по разным причинам, каждому персонажу нужна своя киллер фича: одним важно, чтобы было прикольно, другим – чтобы лучше, чем у аналогов, а третьим – чтобы было в тренде. Для того, чтобы определить последовательность, есть хорошая техника – story mapping, в которой вы раскладываете на доске карточки с фичами, привязывая их к релизам.
Заметим, что фичи бывают трех категорий: одни привлекают пользователей, другие обеспечивают основной функционал, а третьи – обеспечивают целостность работы. Прием платежей в интернет-магазине вовсе не нужен покупателям, для них ценность – товар и доставка, но без оплаты оно не работает и оплата должна быть удобна. Фичи разных категорий реализуются по-разному, киллер фича должна привлекать пользователей, а поддерживающая – лишь не раздражать. Поэтому полагания о классе фичи тоже надо запомнить.
Дальше идет такт оценки трудоемкости. Оценка идет по придуманной принципиальной реализации, и обычно выполняется по аналогии, детализация для более точной оценки на этом этапе отсутствует. Технически это может быть planning poker, о котором я расскажу дальше, или оценка экспертами. Оценка приближенная, поэтому единицы оценки – грубые, обычно в человеко-неделях. Из оценки получаются сроки релизов, в которые необходимо заложить резервы, учитывая приближенные оценки и высокую степень неопределенности в реализации. Они обычно оказываются слишком долгими, особенно для первого, и идет несколько итераций по свертыванию плана. Особенно важно на этом этапе не свертывать план за счет уменьшения резервов, потому что такой план будет не реалистичным.
Важно, чтобы на такте оценки, а лучше – раньше в процессе участвовало ядро будущей команды разработки. Если же ядро команды появляется позже, то с ним нужно заново пройти такт оценки, получить совсем другие цифры и разобраться с расхождениями – это лучше сделать до старта проекта. Впрочем, даже если этого не сделать, итерационная разработка по Scrum или другим Agile-методам за 2-3 итерации проявит проблемы планирования, в отличие от классического проектного подхода, в котором они обычно выясняются к концу проекта.
В целом начальное наполнение бэклога и планирование релизов занимает не так много времени, не больше недели работы нескольких экспертов и стейкхолдеров, часть из которых войдет в ядро будущей команды. Важно, чтобы в составе были не только реализаторы, но и те, кто представляет потребителя и рынок. Для начального планирования часто проводят отдельную сессию на 1-2 дня, центром которой является story mapping. Но это хорошая техника, а вовсе не обязательная часть метода. Возможна просто работа группы экспертов, вместо story mapping можно применять сортировку списка функций. Однако, чего нельзя делать – это заменять ценность на функции и забывать о группах пользователей, которым релиз несет ценность.
Заметим, что в описанной выше технике практически нет специфики IT, ее можно применять для планирования рекламных компаний, создания коллекций одежды и в целом развития бизнеса, особенно при использовании OKR вместо ценности, о котором я писал выше.
Отмечу, однако, что описанное выше нельзя рассматривать как исчерпывающую инструкцию по созданию продукта. Это лишь часть, создание продукта имеет много других аспектов, о которых можно посмотреть бизнес-модель Александра Остервальдера или другие.
В результате описанного выше процесса, который инода называют нулевой итерацией, у вас появляется начальное наполнение бэклога и теперь можно запускать спринты, которые объединяются в более крупный релизный цикл, как это изображено на полной схеме Scrum.
Почему релизы не выпускаются каждую итерацию, если она итерация должна поставлять ценность? Дело в том, что темп выпуска релизов определяется не внутренней скоростью разработки, а характером взаимодействия с рынком – проведением рекламных компаний, привлечения групп пользователей и так далее. Все это разворачивается в собственном темпе. То же можно сказать и про корпоративную разработку: внедрение нового функционала требует изменения бизнес-процессов и обучения пользователей, и эти процессы разворачиваются в собственном темпе. При этом технически новый функционал уже может быть в продукте.
Релизный цикл накладывает свой отпечаток на спринты, могут появляться отдельные спринты стабилизации и выпуска релизов, в некоторых проектах после выпуска может быть предусмотрен спринт срочных доработок по запросам пользователей, или даже переключение в потоковую обработку задач до стабилизации.
Как написано выше, предварительный бэклог наполнен крупными задачами, для которых известен только принципиальный способ реализации. Они несут значительную долю неопределенности, которая недостаточна для уверенного планирования спринта. Поэтому до планирования задачи бэклога, которые с большой вероятностью будут включены в спринт, необходимо дополнительно детализировать.
Однако, использование только функционального ответа недостаточно, потому что разные люди будут по-разному давать ответ на этот вопрос. Поэтому хорошей практикой является разработать чек-лист Definition of Ready, формулирующий критерии готовности задачи к планированию.
За подготовку и необходимую детализацию задач отвечает Product Owner. Как уже говорили, она выполняется не заранее, а по мере продвижения проекта только для ближайших спринтов. Потому что детальные проработки проекта целиком имеют печальное обыкновение сгнивать раньше, чем добираются до реализации, и оказываются бесполезной работой.
Если такая подготовка задач к будущему планированию требуют заметных трудозатрат, то их надо планировать в предыдущим спринте, а если ограничивается обсуждениями, то отдельное время не выделяется, оно учитывается как общие накладные расходы. Процесс такой подготовки называется backlog grooming или backlog refinement. Груминг – первоначальное название, и оно соответствует сути, однако у него есть негативные сленговые коннотации, поэтому в официальных документах оно было заменено на refinement, подробности можно прочитать в этой статье.
Подготовка бэклога показана на моей рисовке схемы отдельным процессом, хотя часто ее помечают просто надписью на содержании спринта. Этот процесс требует организации. Простой способ – добавить к скрам-доске три колонки слева, в первую из которых Product Owner будет вывешивать задачи, ожидающие подготовки, во второй – те, которые готовятся на данный момент и в третьей – готовые к включению в будущий спринт. Но если процесс более сложен и требует внешних согласований, то такой способ может оказаться недостаточен. Тогда для подготовки бэклога можно организовать отдельный Kanban-процесс – об этом есть хороший доклад Алексея Пименова на SECR-2016 «Discovery Kanban для управления беклогом Scrum-команды».
Еще один вариант организации подготовки бэклога – уже упоминавшийся в статье «Завершение спринта в Scrum – демо и ретро» splitting sprint, разделение спринта на два со сдвигом.
Об оценке трудоемкости следует сказать отдельно. Она может выполняться в человеко-часах, в том числе в разрезе конкретных специалистов. В этом случае понятно, как определять, сколько задач поместиться в спринт: у нас есть общий ресурс часов команды, с учетом текущих отпусков, есть нормированные накладные расходы и резерв на регулярные потоки работ, если команда их делает, и дальше мы просто учитываем загрузку специалистов. Такая оценка практикуется, при этом, однако, важно не стремиться к излишней точности оценки.
Обычно это достигается применением карточек, где оценка дана в числах Фиббоначи (1, 2, 3, 5, 8, 13, 20, 40) или степенями двойки. Но практика показывает, что при относительно однородном потоке задач не менее точной, зато гораздо более быстрой является оценка не в часах, а условных единицах Story Point или в условных размерах: S, M, L, XL. При этом на нескольких спринтах эта оценка калибруется и емкость спринта или скорость команды определяется именно в таких единицах. Практика показывает, что члены команды могут давать оценку в размерах даже для задач, в которых они не являются специалистами-исполнителями, обучаясь на предыдущем опыте работы.
А еще опишем процедуру оценки, для этого используется planning poker: после представления задачи члены команды выкладывают карточки с оценками, а потом одновременно их переворачивают. При больших расхождениях идет обсуждение, обычно это означает, что разные члены команды поняли задачу сильно по-разному, что и выясняется в обсуждении. Потом следует повторное голосование.
На планировании вполне вероятной является ситуация, когда оценка задачи получается слишком дорогой для ее ценности. Тогда следует такт обсуждения с Product Owner, который на планировании представляет интересы стейкхолдеров. Во-первых, бывает, что у стейкхолдеров есть на этот случае План-Б, и задачу просто не нужно делать. Во-вторых, возможно, команда может предложить какое-то более легкое решение для реализации, которое удовлетворит основные потребности – правило Парето говорит, что чаще всего это возможно. Это – конструктивное обсуждение.
А вот переход в этом случае к различным способам давления чаще всего не имеет смысла. Потому что наиболее распространенный результат – команда соглашается, а потом просто не делает. И в результате вместо четкого представления о том, что какой-либо функционал не будет получен через две недели, стейкхолдеров обнаруживают это постфактум, две недели спустя, когда они рассчитывали его получить. Не обязательно тот, по поводу которого было давление – может оказаться, что его сделали, но не сделали что-то другое. А если не сделали именно его – то на него при этом уже затрачены определенные ресурсы, и далее надо доделывать или выбросить.
Конечно, может оказаться, что сознательная команды сделает этот функционал за счет личного времени. Но, как показывает практика, на это может сработать один-два раза, а вот на регулярной основе это приводит к негативным последствиям: либо команда выгорает и производительность падает, а сотрудники уходят, либо команда начинает систематически завышать оценки, чтобы было, куда отступать при давлении. В любом случае, прозрачность процесса и сотрудничество в достижении цели – разрушается, что разрушает эффект использования Agile-подходов.
Вообще надо отметить, что планирование представляет собой заключение контракта на спринт между командой и стейкхолдерами, при этом интересы стейкхолдеров представляет Product Owner. Этот контракт может иметь разную жесткость. В свое время была популярной идея о том, что «настоящая команда» на планировании всегда дает обещание, commitment, которое потом выполняет почти любой ценой. Такой взгляд очень нравится стейкхолдерам и, на первый взгляд, отвечает их интересам. Однако, практика показывает, что это неверно. В долгую это ведет к выгоранию команды либо к сознательному завышению оценок, в котором еще и не сознаются, тратя выигранное время по своему усмотрению и превращая работу в agile-курорт. И этому есть системная причина – длинный хвост распределения в оценках IT-работы, о чем есть хороший доклад Андрея Бибичева «Пуассоново горение сроков».
Конечно, планирование спринта обычно не является заключением какого-то принципиально нового контракта, речь обычно идет лишь о целях и объеме работ на спринт. Однако, в общем случае, стейкхолдерами проекта после любого спринта может быть принято решение о прекращении проекта.
И в заключении этой статьи я хочу еще раз обратить внимание на то, что выполнение состава работ, которым наполнена задача, вовсе не означает, что ценность получена. Начинали наполнение бэклога мы именно с ценности, которую выполнение задачи должно принести пользователям, клиентам или потребителям. Ценность – это решенная проблема или предоставленная возможность. По мере проработки бэклога мы придумали способ получить ценность, сначала – принципиальный, потом – детальный, потом реализовали это. Но при этом наш придуманный способ остается гипотезой, и требует экспериментальной проверки реальным потребителем. И может оказаться, что требуются какие-то дополнительные работы.
Мы думали, что пользователь сформирует список из 10-20 любимых песен для запуска по циклу в фоне, а оказалось, что у многих есть несколько списков для разных настроений, и любимое произведение в одном состоянии превращается нестерпимым в другом. Мы сделали специальную форму для оформления заказов с доставкой со склада на тренажеры прямо из магазинов, а оказалось, что сотрудники магазинов по-прежнему звонят в офис и резервируют товар по телефону, а только потом заполняют форму. Потому что боятся, что пока они будут оформлять заказ и подробности доставки, тот единственный тренажер уйдет по другому назначению, и не хотят, чтобы покупатель почувствовал тоже самое, что чувствуют многие из вас, когда после заполнения сведений о пассажирах при покупке билетов получают сообщение, что билеты уже проданы или подорожали…
То есть уже после реализации оказывается, что создание ценности требует дополнительных объемов работ. И на это тоже надо закладывать резервы при планировании. Но если у вас задачи похожие, то статистика позволит оценить качество, с которым команда превращает ценность в содержание работ, и требуемый размер буфера.
Отметим, что важно закладывать общий буфер, а не резерв на каждую задачу: дело в том, что имея по задаче оценку с резервом, разработчики всегда испытывают искушение повысить качество реализации, если они сделали задачу быстрее оценки. А если задача оказалось сложной – то превышают оценку. По этой же причине, кстати, детальные оценки на планировании спринта в человеко-часах хуже оценки в размерах или условных единицах.
На этом я завершаю описание схемы Scrum. В следующей статье мы переключимся от описания методов и практик к описанию мест, в которых целесообразно применение Agile-команд в компаниях. Особенно в ситуациях, когда речь идет о постепенном изменении организации в большой компании, которое не стоит делать революционно. А в последующих статьях – снова вернемся к методам, у нас впереди Kanban, затем – фреймворки масштабирования Agile и много другого материала, включая рассказ о кейсах трансформации. Продолжение следует.