Привет.

В прошлой статье я писал о запуске SAFe® в нашей компании и о первом опыте проведения PI планирования. Мы уже успели провести 3 таких мероприятия и готовимся к следующему. Ну а что же происходит между PI-планированиями? Очевидно, что работа: команды стремятся выполнить поставленные цели. А что в это время делает “бизнес”? Как это ни странно, но как только заканчивается одно PI-планирование, сразу же начинается работа над следующим. К началу следующего мероприятия Product Owner (PO) должен подготовить и согласовать со всеми заинтересованными сторонами backlog продукта.

Как такового backlog’а у нас раньше не существовало. Нет, конечно же, был список задач, которые нужно сделать. Но когда руководитель проекта (РП) задавал вопрос “Что там с моим продуктом?”, его отправляли в Jira со словами - “все там”. РП заходил в Jira и видел огромный перечень технических задач, из которых … скажем так, не всегда понятно: связана ли эта задача с его проектом/фичей, все ли задачи проекта занесены в команду, какой статус по задаче, какие сроки, в работе ли задача вообще. По сути это был один огромный технический backlog по всей компании, по всем продуктам, по всем командам - все в одной куче: и мухи, и котлеты.

3х-уровневый Backlog

После запуска SAFe мы стали выделять 3 уровня backlog’а: Program Backlog, Team Backlog и Sprint Backlog. Сейчас я очень бегло расскажу про все уровни, а потом немного углублюсь в то, как мы работаем с первым, “верхним” уровнем - Program Backlog.

Итак, с момента, как мы начали внедрять SAFe в своей работе, у нас появился backlog бизнес-фич. Это именно сформулированные бизнесом фичи, которые понятны в первую очередь бизнесу, руководителям проектов, клиент-менеджерам и внешним заказчикам. Кроме бизнесовых задач в этот же backlog включаются крупные технические задачи - рефакторинг, смена стека и т.п. Такие элементы backlog’а называются Enabler.

Product Owner (PO) - владелец backlog’a, задача которого учесть требования и хотелки бизнеса, а также возможности и обратную связь от разработчиков и определить приоритеты. Уточнение приоритетов - это постоянный процесс. Потому что меняются требования, обстоятельства, хотелки, появляются новые законодательные акты, возникают форс-мажоры, уточнения и прочая и прочая. Какие то фичи могут вообще выпилить.

Потом фичи из Program Backlog’a уже разбивается на User Stories, которые формируют Team Backlog. В каждой бизнес-фиче может быть 10-20 User Stories. Причем разработчики со своей стороны тоже могут заносить через РО User Stories в бэклог.

А уже User Stories растаскиваются на конкретные технические задачи, тикеты в Jira.

А теперь давайте вернемся к верхнему уровню - Program Backlog’у. В нем может быть десяток, а то и не один, бизнес-фич, а инкремент не может вместить их все. И тут встает вопрос, какие фичи войдут в backlog и пойдут в работу в следующий период, а какие нет…Мы используем модель приоритезации, которую также взяли в SAFe

WTF, а нет - это WSJF

WSJF (Weighted Shortest Job First) - это простой инструмент для приоритизации задач, когда они все очень важны. Если по-простому, то мы выбираем те задачи, которые легко сделать и которые имеют максимальную пользу для бизнеса.

Алгоритм достаточно простой:

Смотрим на каждую фичу с 4х сторон: ценность для бизнеса, критичность по срокам, риски (что будет, если мы не сделаем) и сложность реализации. Технические задачи (Enablers) участвуют в оценке на общих основаниях, таким образом архитектор/техлид обязан обосновать необходимость очередного рефакторинга с точки зрения бизнеса.
Затем оцениваем по каждому из этих параметров, используя ряд Фибоначчи 1, 2, 3, 5, 8, 13, 21. Ключевой момент - оцениваем фичи относительно друг друга. Можно использовать любые известные практики оценки в Story Points, например покер планирования. Важно фиксировать в комментариях, почему выставлена та или иная оценка, иначе через пару недель большинство приведенных аргументов забудется и придется переоценивать.
Считаем Cost of Delay: для этого складываем первые 3 оценки (ценность, сроки и риски) и делим на Job Size (объем работы, 4-й критерий).
Сортируем наш список фичей по полученному коэффициенту от большего к меньшему.
Берем в следующий инкремент первые 3/5/10 элементов backlog’а (количество уже зависит от возможностей команды).

Подробнее можно почитать у первоисточника.

Легко сказать, сложно договориться

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

Против цифр сложно спорить, но тем не менее, спорить очень хочется. Особенно когда интуитивно кажется, что твоя любимая фича должна стоять на первом месте, а в backlog’е она на 10-м. Здесь очень важно не вестись на манипуляции - коллег, разработчиков, клиентов - а посмотреть на метрики, где и что выбивается, где несоответствие.

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

Единственное решение - это договариваться. Вернее управлять backlog’ом через договоренности с командой. Раз в неделю РО проводят Program Backlog Refinement - встречу, на которой все заинтересованные люди (PMы, клиент-менеджеры, архитектор/техлид) собираются и обсуждают backlog, обсуждают оценки, метрики, договариваются в конце концов.

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

Волшебная таблетка (спойлер: которой нет)

За полгода внедрения фреймворка мы уже столкнулись с множеством историй, когда наши (или клиентские) ожидания не совпадали с оценкой. Универсального решения тут не существует. Почти каждая ситуация уникальна, но все же есть похожие сценарии:

Требует заказчик. Понятно, что Заказчик всегда будет говорить, что его фича - самая горячая. Тут очень важно не вестись на манипуляции и здраво оценивать возможности и риски.
Мы излишне усложняем задачу. Давайте будем честными, разработчики любят усложнять задачи и создавать системы там, где это не нужно. Простой пример: нужно добавить одно поле. Но разработчики говорят: нужно сделать систему, которая позволит добавлять любые поля, создадим для этого админку, добавим разные типы полей и т.д. и т.п. Да, возможно, в дальнейшем возникнет необходимость в создании такой системы. Но сейчас, именно сейчас - это лишнее. И наша задача (наша, я имею в виду PO) пресечь этот момент и таким образом облегчить реализацию. Что естественно повлечет за собой переоценку метрики и изменит расстановку сил в рейтинге фич.
Может быть и другая история, ребята из команды разработки могут подсветить определенные вопросы, связанные с информационной безопасностью или еще что-то, что можно решить не кодом, а инфраструктурой. Тогда мы договариваемся уже с Заказчиком, что они должны обеспечить определенную инфраструктуру, которая будет соответствовать модели угроз. И получается, что на уровне кода ничего делать не нужно, все решается на уровне сисадминов, а оценка снижается просто за счет договоренности с клиентом.
Крупные фичи можно и нужно декомпозировать. Бывает, что команда может сделать в итерацию только одну фичу, но бизнесу нужно две или даже три. Тогда можно взять самую крупную, выделить в ней только самое необходимое и упаковать этот минимум в "первый этап", который и пойдет в итерацию. Оставшиеся работы можно спокойно планировать в следующие PI. Таким образом освободить ресурсы команды под дополнительные фичи. Главное, не забыть согласовать выделение этапов с заказчиками.
Изобретаем велосипед. Бывает так, что для решения задачи уже есть решение, например, разработанное в соседней команде в предыдущую итерацию. Вообще отсутствие шаринга знаний между командами - это известная многим компаниям проблема. У себя раз в две недели мы проводим встречи всех РО для синхронизации команд и мониторинга межкомандных зависимостей. На этих встречах каждый РО может вынести на общее обозрение свои сложные истории и запросить помощи. Иногда в результате такого группового ревью фичи выясняется, что в другой команде есть наработки позволяющие упростить задачу.

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

Результат

В результате серии встреч по уточнению Program Backlog мы получаем согласованный со всеми участниками забега список бизнес-задач и Enabler’ов со сквозным приоритетом. Таким образом, на очередном PI-планировании у команды есть четкая очередь бизнес-задач, которая уже раскладывается на User Story в Team Backlog. И уже на основании Team Backlog команда планирует следующий инкремент программы. О том, как мы формируем Team Backlog расскажу в следующей статье.

Лебедь, рак и щука или как приоритизировать backlog и не убить друг друга