Для чего используется бэклог продукта согласно методике scrum
Бэклог продукта — совершенный список задач
Бэклогу продукта, как и человеку, нужны уход и внимание. А еще он должен быть открыт для других.
Просмотр тем
Agile-бэклог с правильно расставленными приоритетами не только упрощает планирование релизов и итераций. Из него команда узнает, над чем она будет работать. Вся внутренняя кухня скрыта от глаз клиента. Работа становится для заинтересованных лиц и других команд более предсказуемой, что особенно полезно, когда они ставят перед вами дополнительные задачи. Время на разработку становится фиксированным ресурсом.
Что такое бэклог продукта?
Бэклог продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале бэклога продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь. Скорость, с которой команда выполняет задачи бэклога, не зависит от желаний владельца продукта, а он, в свою очередь, не оказывает давления на команду. Напротив, команда разработки самостоятельно выбирает задачи из бэклога продукта, когда у нее есть необходимые ресурсы, выполняя их непрерывно (Kanban) или итерациями (Scrum).
Храните все в одном трекере задач. Не используйте несколько систем для отслеживания багов, требований и рабочих задач по разработке. Есть задача для команды разработчиков? Тогда информация о ней должна быть в одном бэклоге.
Два столпа бэклога продукта
В основе бэклога продукта находятся дорожная карта команды и требования. Инициативы дорожной карты делятся на несколько эпиков, а каждый эпик содержит несколько требований и пользовательских историй. Рассмотрим дорожную карту для вымышленного продукта «Команды в космосе».
Веб-сайт «Команды в космосе» — первая инициатива на дорожной карте, поэтому нам нужно разбить ее на эпики (обозначены на рисунке зеленым, синим и бирюзовым цветами) и пользовательские истории для каждого эпика.
Владелец продукта составляет из этих пользовательских историй единый список для команды разработчиков. Владелец продукта может упорядочить истории так, чтобы команда сначала выполнила один эпик полностью (слева). Как вариант, может быть важнее сначала протестировать бронирование билетов со скидкой, а для этого нужно реализовать истории из нескольких эпиков (справа). Оба варианта представлены ниже.
Что может повлиять на то, как владелец продукта расставляет приоритеты?
Хотя расстановкой приоритетов занимается владелец продукта, в процесс вовлечены и другие стороны. Успешность бэклога зависит от вклада и обратной связи, предоставленной клиентами, дизайнерами и командой разработчиков. Совместными усилиями они должны добиться оптимальной рабочей нагрузки между всеми участниками и обеспечить поставку продукта.
Правильное ведение бэклога
После создания бэклога важно регулярно корректировать его по мере выполнения программы. Владельцы продукта должны пересматривать бэклог перед каждым собранием по планированию итерации, чтобы уточнить расстановку приоритетов и внести изменения на основе выводов, сделанных в результате последней итерации. Регулярный пересмотр бэклога в кругах специалистов по Agile часто называют «грумингом» или «ведением бэклога» (некоторые используют термин «уточнение бэклога»).
Когда бэклог становится достаточно большим, владельцам продукта приходится выделять в нем группы краткосрочных и долгосрочных задач. Краткосрочные задачи нужно досконально проработать, прежде чем присвоить им этот статус. Для этого нужно составить полноценные пользовательские истории, обсудить все детали совместной работы с дизайнерами и разработчиками и оценить сложность разработки. Долгосрочные задачи могут быть продуманы не до конца, однако если команда разработчиков даст им приблизительную оценку, это поможет расставить приоритеты. Ключевое слово здесь — «приблизительная». Оценки поменяются, когда команда получит полное понимание долгосрочных задач и приступит к их выполнению.
Бэклог служит связующим звеном между владельцем продукта и командой разработчиков. Владелец продукта может в любое время поменять приоритеты в работе на основе обратной связи от клиентов, более точных прогнозов и новых требований. И все же следует избегать изменений в ходе работы, потому что они мешают команде разработчиков, негативно влияя на концентрацию, рабочий процесс и моральный дух.
Когда бэклог становится слишком большим, чтобы на него хватало ресурсов команды даже в долгосрочной перспективе, задачи, до которых никогда не дойдет очередь, можно закрывать. Помечайте такие задачи специальной меткой, например «Вне объема работ», в трекере задач команды, чтобы изучить их позднее.
Плохие примеры, которые лучше не повторять
Бэклоги продукта и верность команды принципам agile
Опытные владельцы продукта со всей ответственностью подходят к ведению бэклога продукта, чтобы он был надежным источником рабочих задач по проекту, которые предназначены для совместной работы.
Заинтересованные стороны будут оспаривать принятую очередность задач — и это хорошо. В результате обсуждения того, какие работы важнее, все приходят к общему представлению о приоритетности задач. Такие обсуждения способствуют формированию культуры, в которой приоритеты расставляются групповыми усилиями и все участники объединены общим взглядом на программу.
Кроме того, на основе бэклога продукта планируются итерации. В бэклог должны быть включены все рабочие задачи: пользовательские истории, баги, изменения в дизайне, технический долг, запросы клиентов, действия, намеченные по итогам ретроспективы, и т. д. Так рабочие задачи каждого участника будут рассмотрены на общем обсуждении перед каждой итерацией. Затем участники команды и владелец продукта с полным пониманием объемов задач и учетом обоюдных интересов принимают решения до начала итерации.
Владельцы продукта определяют важность рабочих задач в бэклоге, в то время как команда разработчиков определяет скорость работы над ними. Новым владельцам продукта, которые привыкли торопить команду, такой подход может оказаться не по душе. Подробнее см. в нашей статье о лимитах объема незавершенной работы и рабочем процессе.
Полная схема 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 и много другого материала, включая рассказ о кейсах трансформации. Продолжение следует.
SCRUM: Гибкое управление продуктовыми направлениями
Статья раскрывает тему гибкости управления продуктом в части доставки бизнес-ценности и мобильность в адаптации к изменяющимся внешним условиям. Чёткое понимание видения продукта помогает синхронизировать разработку продукта с бизнес-стратегией компании для достижения стратегических целей. Понимание ценности задаёт темп непрерывного развития продукта. Ценность продукта включает в себя улучшенную транспарентность для применения и развития ценностно ориентированного подхода для принятия решений. Ключевые постулаты предмета включают в себя непрерывное определение ценности, измерение актуальной доставленной ценности, валидация гипотез и анализ трендов.
В статье предложена система метрик для измерения и дальнейшего анализа атрибутов гибкого управления продуктовыми направлениями.
Прогнозирование и планирование релиза
Разработка программного обеспечения является процессом создания продукта и дальнейшего его вывода на рынок потребителей. Сам процесс разработки программного обеспечения живёт в эмпирическом мире, которому свойственно иметь большую неопределённость и хаос. С целью организации бережливого производства для среды с неопределённостью и хаосом, прогнозирование релиза сводится к следующим ключевым идеям:
Конечным результатом прогнозирования является приверженность команды к объёму работ, а не конечная абстрактная оценка по трудозатратам. Процесс организации разработки вокруг оценки трудозатрат внедряет избыточный объём работ, результаты которого либо не используются, либо не нужны клиенту.
Фокусом прогнозирования является добавочная ценность новых функций продукта. В том случае если фокусом является трудозатраты, то возникают сложности в обосновании целесообразности реализации новых функций продукта для клиента.
Клиент платит не за отдельно взятые функции продукта, клиент платит за ценность продукта. Производителем ценности является продуктовая команда, спонсируемая клиентом. Соответственно, при таком подходе отпадает необходимость проведения оценки трудозатрат, так как есть команда, которая гарантирует доставку инкремента с ценностью каждый релизный цикл. Данная идея будет более подробно рассмотрена в рамках ценностной модели обоснования трансформации, так как является системообразующей.
Наблюдение за наличием ответственного лица, который принимает решение о включении доработки в бэклог спринта.
ответственное лицо на уровне компании не выделяется — 0 баллов.
существуют несколько ответственных лиц за одно продуктовое направление — 1 балл.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента не осознаётся — 3 балла.
есть единственное лицо на продуктовое направление, ответственность доставки ценности инкремента осознаётся — 5 баллов.
Участники планирования содержания продукта
Наблюдение за присутствуем стейкхолдеров и ответственных лиц продуктовых направлений на планировании содержания продукта.
при планировании присутствуют только стейкхолдеры — 0 баллов.
при планировании присутствуют стейкхолдеры и часть ответственных лиц продуктовых направлений — 1 балл.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений — 3 балла.
при планировании присутствуют стейкхолдеры и все ответственные лица продуктовых направлений, а также смежные представители по интеграционным вопросам — 5 баллов.
Участники планирования содержания спринта
Наблюдение за присутствуем функциональных исполнителей (разработчиков) на планировании спринта.
исполнители отсутствуют на планировании — 0 баллов.
на планировании присутствуют представители (тимлиды) исполнителей — 1 балл.
на планировании присутствуют исполнители, не объединённых общей командой — 3 балла.
на планировании присутствуют исполнители, объединённые командой — 5 баллов.
Принцип планирования содержания спринта
Наблюдение за принципом включения доработки в состав спринта.
учитываются только приоритеты стейкхолдеров — 0 баллов.
учитываются приоритеты стейкхолдеров и трудозатраты — 1 балл.
учитываются приоритеты стейкхолдеров, полнота существующих знаний — 3 баллов.
учитываются приоритеты стейкхолдеров, полнота существующих знаний, готовность постановок — 5 баллов.
Наблюдение за применяемой техникой при прогнозировании допустимого объёма спринта
прогнозирование не проводится — 0 баллов.
прогнозирование проводит тимлиды функциональных групп — 1 балл.
прогнозирование проводит команда продуктового направления без определённой техники — 3 балла.
прогнозирование проводит команда продуктового направления, используется техника pokerpointing — 5 баллов.
0–17 баллов — низкий результат, характеризующий отсутствие гибкости производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены наличием нескольких рабочих групп с дублирующими функциями, а также размытой зоной ответственности продуктовой команды. Рекомендуется предусмотреть мероприятия по сокращению рабочих групп с дублирующими функциями и выделить единого ответственного лица за продуктовое направление. В дополнении рекомендуется провести тренинг сессии со стейкхолдерами.
18–21 баллов — средний результат, характеризующий ограниченную гибкость производства в части синхронизации объёма работа стейкхолдеров и продуктовой команды. Данные ограничения обусловлены маршрута объёма работ по принципу «глухого телефона», на этапах которого происходит искажение общего информационного поля. В плане улучшения характеристик рекомендуется рассмотреть мероприятия, направленные на оптимизацию маршрута объёма работ.
22–25 баллов — высокий результат, характеризующий гибкость и устойчивость производства программного обеспечения с точки зрения управления ожиданиями. Стейкхолдеры и продуктовые команды синхронизированы относительно содержания инкрементов. Отсутствуют изолированные от продуктового бэклога работы, что предотвращает производство ненужных результатов.
Видение продукта
Видение продукта, или общая концепция продукта, определяет долгосрочную миссию продуктового направления в части маршрута развития. Видение должно выполнять функцию ориентира для всех стейкхолдеров, вовлечённых в разработку программного обеспечения, для достижения общих целей с выпуском инкремента продукта. Продуктовое видение отвечает на вопрос, почему создаётся данный продукт и что компания надеется достигнуть в ближайшем будущем.
Структура видение может быть описана по следующему шаблону:
Для кого: целевая аудитория продукта.
Потребности: потребности и проблемы клиента для решения.
Продукт: брендовое название продукта.
Категория: описание продукта.
Преимущества: ключевые преимущества продукта, причины приобретения.
Сравнение: особенности от конкурентов.
Характеристика
Метод исследования
Метрика
Наблюдение за наличием единственного сотрудника, владеющего видением продукта (продуктового направления).
отсутствует владелец видения — 0 баллов.
существуют несколько владельцев видения — 1 балл.
существует единственный сотрудник в качестве носителя видения, который его не разделяет — 3 балла.
существует единственный сотрудник в качестве носителя видения, который его разделяет — 5 баллов.
Наблюдение за принципом распространения видения среди стекйхолдеров и продуктовой команды.
видение распространяется только среди продуктовой команды — 0 баллов.
видение распространяется только среди стейкхолдеров — 1 балл.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием одинаковых материалов — 3 балла.
видение распространяется среди стекйхолдеров и продуктовой команды с использованием разных материалов — 5 баллов.
Инкрементность и итеративность видения
Наблюдение за принципом этапного развития и доставки видения.
видение доставляется в виде продукта без промежуточных этапов — 0 баллов.
видение доставляется инкрементно без итеративности — 3 балла.
видение доставляется инкрементно с итеративностью — 5 баллов.
Наблюдение за проявлением свойства адаптировать видение к изменяющимся внешним условиям по мере изучения нового.
видение сложно меняется и является идеологическим монолитом — 0 баллов.
изменение видения продуктового направления ограничено корпоративными бюрократическими барьерами — 1 балл.
изменение видения продуктового направления проводится по регламентированной процедуре — 3 балла.
видение продуктового направления может легко меняться, в компании отсутствуют административные барьеры — 5 баллов.
Наблюдение за проявлением свойства позиционировать видение относительно бизнес-ценности.
позиционирование видения насыщено техническими деталями — 0 баллов.
позиционирование видения находится в плоскости решения проблемы и/или доставки добавочной ценности для бизнеса — 5 баллов.
Наблюдение за механизмами валидации видения продукта со стекйхолдерами, продуктовой командой и рынком.
валидация видения не проводится — 0 баллов.
валидация видения проводится только со стейкхолдерами — 1 балл.
валидация видения проводится со стейкхолдерами и командой — 3 балла.
валидация видения проводится со стейкхолдерами, командой и рынком — 5 баллов.
Отношение видения к стратегии компании
Наблюдение за проявлением принципа соответствия видения продукта со стратегией компании.
отсутствует сопоставление видения продуктового направления со стратегическими целями компании — 0 баллов.
существует косвенное сопоставление видения продуктового направления со стратегическими целями компании — 3 балла.
существует прямое сопоставление видения продуктового направления со стратегическими целями компании (увеличение дохода, рост объёма продаж, увеличение доли рынка, улучшение имиджа) — 5 баллов.
0–24 баллов — низкий результат, характеризующий отсутствие продуктового видения как инструмента определения стратегического вектора развития продуктового направления. Данный результат свойственен компаниям с контрактной моделью предоставления сервиса по заказной разработке. Проявляются высокие риски закрытия целых продуктовых направлений. Рекомендуется разработать полноценную программу развития культуры продуктового видения, включив стратегические сессии, коучинг руководителей и тренинги сессии продуктовых команд.
25–29 баллов — средний результат, характеризующий слабую степень развития продуктового видения, которое выражается в рассинхронизации общего представления вектора движения между стекйхолдерами: заказчик, акционеры, руководство и продуктовая команда. При данном результате преобладает низкая культура корреляции стратегических целей компаний с концепцией продуктовых направлений.
30–35 баллов — высокий результат, характеризующий уверенную степень развития продуктового видения, которое обеспечивает разработку дорожной карты по принципу декомпозиции высокоуровневой концепции на тактические задачи в вид бэклога продукта для продуктовой команды. Наблюдается проявление принципа принятия решений на основании стратегических ориентиров. Продуктовая команда и стейкхолдеры синхронизированы в понимании стратегического вектора движения продукта.
Ценность продукта
Ценность продукта — выгоды, приобретаемые пользователем продукта для удовлетворения потребностей с определёнными затратами на них. Ценность продукта является агентом сделки между пользователем и разработчиком программного обеспечения, при котором происходит перераспределение финансовых благ. Ценность, обеспечиваемая продуктом, зависит от двух аспектов:
Важность цели, которую пользователь собирается достигнуть при использовании продукта. Данный аспект определяет абсолютную ценность, характеризующую степень соответствия потребностям пользователя.
Доступные альтернативные решения на рынке для сравнения конкурентных преимуществ. Данный аспект демонстрирует относительную ценность, которая определяет конкурентные правила и векторы роста продукта.
Характеристика
Метод исследования
Метрика
Наблюдение за проявлением проектного или продуктового мировоззрения.
преобладает мировоззрение в контексте проектного треугольника (состав работ, сроки и ресурсы) — 0 баллов.
выделяется как проектное, так и продуктовое мировоззрение — 3 балла.
преобладает продуктовое мировоззрение в контексте доставки ценности продукта — 5 баллов
Наблюдение за признанием ценностей продуктового направления в разрезе выделенных элементов ценности (The 30 Elements of Consumer Value: A Hierarchy).
продуктовые направления не имеют систему элементов ценности — 0 баллов.
продуктовые направления имеют систему элементов ценности, которые не признаны на всех уровнях компании — 1 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании — 3 баллов.
продуктовые направления имеют систему элементов ценности, которые признаны на всех уровнях компании. Проведено маркетинговое исследование для подтверждения — 5 баллов.
Наблюдение за техникой целеполагания в контексте ценности продуктового направления.
техника отсутствует, целеполагание не проводится — 0 баллов.
техника отсутствует, целеполагание проводится — 1 баллов.
присутствует техника impact mapping, ограниченное использование — 3 балла.
Определение интегральной шкалы оценки свойства «ценность продукта» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия стратегических сессий руководителей компании и владельцев продуктовых направлений, тренинг сессии владельцев продуктов для развития культуры целеполагания.
Управление продуктовым бэклогом
Эффективное управление продуктовым бэклогом гарантирует разработку продукта согласно видению с целью доставки добавочной ценности. Более того, повышается транспарентность информационного поля, выстраивается эмпирический механизм валидации ценности и сокращаются зависимости.
Характеристика
Метод исследования
Метрика
Наблюдение за единым местом хранения всех задач, направленных на развитие продукта.
бэклог продукта отсутствует — 0 баллов.
бэклог продукта имеет вид разбросанных задач — 1 балл.
бэклог имеет вид отфильтрованного списка по предмету — 3 балла.
бэклог единое место хранения всех задач по продукту — 5 баллов.
Наблюдение за наличием единственного сотрудника, являющимся владельцем бэклога продуктового направления.
отсутствует владелец бэклога — 0 баллов.
существуют несколько владельцев бэклога — 1 балл.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании не признаётся — 3 балла.
существует единственный сотрудник в качестве владельца бэклога, на уровне компании признаётся — 5 баллов.
Наблюдение за проявлением принципа доступности бэклога всем заинтересованным сторонам.
бэклог не доступен команде продуктового направления и стейкхолдерам или существуют ограничения в части получения доступа — 0 баллов.
бэклог доступен команде продуктового направления и стейкхолдерам по ссылке — 5 баллов.
Наблюдение за принципом организации структуры элементов бэклога.
бэклог включает в себя элементы, отличные от Agile-подхода — 0 баллов.
бэклог включает в себя: EPIC (эпик), user story (пользовательская история), task (задача), subtask (подзадача), bug (дефект) — 5 баллов.
Определение интегральной шкалы оценки свойства «управление продуктовым бэклогом» не целесообразно так, как каждый атрибут является самодостаточной характеристикой и требует индивидуального подхода в интерпретации и разработки мероприятий для развития. Рекомендуется в программе предусмотреть мероприятия с включением коучинг и тренинг сессий владельцев продуктов для развития культуры целеполагания.