Как быть уверенным, что работаешь над самыми важными элементами бэклога?

«Когда Agile команды работают только над срочными элементами, результат чаще всего их не удовлетворяют»

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

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

Ловушка Agile приоритезации: в начале каждого спринта выбираем что делать

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

  1. критичная проблема, пришедшая от технической поддержки
  2. то, что вчера повлияло на продажи;
  3. последний каприз очень важного стейкхолдера

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

Приоритезация без цели — это как покорение вершины без карты

В Колорадо есть 53 вершины, высота которых достигает 14,000 футов (4,267 метров). Есть 2 способа покорить вершину.
Первый способ: вы просто едете к подножию горы и начинаете восходить к самой высокой точке, которую вы видите. Почти наверняка это будет ложная вершина, которая кажется только вершиной, потому что затеняет настоящую вершину.

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

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

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

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

Много-спринтовая цель: карта Владельца продукта (пример: User story mapping)

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

И так заманчиво вместо этого заняться краткосрочными пожарами.

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

Когда приоритезируете помните, что срочное редко бывает важным

Президент Соединенных Штатов Эйзенхауэр знал, насколько важно различать важные и срочные вопросы.
Эйзенхауэра часто цитируют так:

«То, что важно, редко срочно, а то, что срочно, редко важно».

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

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

Владельцу продукта следует определять значимую цель ежеквартально

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

Всё это означает, что Владельцу продукта жизненно важно определить основную цель и, возможно, в перспективе на 3 месяца — это достаточный срок.

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

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

Это должно быть значительным. Для нового продукта это может быть минимально жизнеспособный продукт (MVP — minimum viable product), для существующего продукта — добавление минимальной рыночной функции  (MMF — minimum marketable feature), некоторые компании называют это чрезвычайно важной целью (WIG — wildly important goal)

Владея основной целью — будь то в форме MVP, MMF или WIG — Владелец продукта сможет лучше оценить срочные элементы. Если работа над срочным элементом более важна, чем работа по достижению основной цели, то все силы команды должны быть направлены на работу с ним.

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

Оригинал статьи: https://www.mountaingoatsoftware.com/blog/how-to-ensure-youre-working-on-the-most-important-items-each-iteration

Поделиться
Отправить
Запинить
Популярное