Rose debug info
---------------

WSJF как способ приоритезации задач

Weighted Shortest Job First. Сначала наивесомейшая кратчайшая работа.

Принцип используется в SAFe 4 как метод приоретизации работы. Смысл в том, чтобы наиболее ценные и быстровыполнимые задачи брать с более высоким приоритетом. Для того, чтобы быстрее наносить максимум пользы конечным пользователям в потоке поставке ценности.

Что глядя на это можно сказать?

  • Чем скорее можем поставить большую ценность, тем лучше.
  • Чем меньше потратим Cost of Delay, тем лучше.
  • Чем менее значима бизнес составляющая, и высока сложность, тем меньше шансов, что до её реализации вообще дойдет :)

Звучит очевидно, да? Но на практике не всегда легко ранжировать.


Формула выглядит так:

WSJF = Cost of Delay / Duration

SAFe предлагает Cost of Delay считать как:

Cost of Delay = User-Business Value + Time Criticality + (Risk Reduction or Opportunity Enablement)

  • User-Business Value: Насколько громко просят об это пользователи? Как это отразится в деньгах, если эта штука НЕ будет сделана? Какой потенциально негативный эффект будет, если это выполнить позже, а не раньше?
  • Time Criticality: Как это влияет на общий поток поставки? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что опоздание с этим умножит на ноль весь смысл проделанной работы?
  • Risk Reduction: Снижает ли это какие-то риски? Будет ли это позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?
  • Opportunity Enablement: Откроет ли эта штука новые возможности для продукта или всего бизнеса? Поможет ли выйти на новые рынки сбыта/привлечь других клиентов?

Оценки проставляются от 1 до 21 согласно ряду Фиббоначи (1, 3, 5, 8, 13, 21... ), суммируются и делятся на размер работы. Размер работы тоже оценивается числами Фиббоначи, в общем оценкой в скрамовских сторипоинтах.

К примеру, следующий набор Фич для интернет-магазина:

  1. Приветственное письмо покупателю, сразу после того, как он получил на руки заказ от курьера
  2. Автоматический дозвон до клиента и соединение с оператором коллцентра после того, как клиент оставил заказ в интернет магазине
  3. Автоматичесая печать наклеек на пакеты для транспортной компании

Проведем оценку, чтобы было понятно почему такие значения, распишем Business Value и перечень технических задач на реализацию каждой Фичи:

Есть строгие правила проставления оценок:

  1. Заполнять по одной колонке за раз, начиная с самой простой Фичи, проставив ей оценку 1, остальные оценивать относительно первой единице
  2. Следствие: должна быть минимум одна единица в каждой колонке!
  3. Самое большое число по WSJF означает наиболее высокий приоритет
    По мне, очень полезные правила, придерживаться которых следует, чтобы снизить коэффициент «ленинского прищура».

Расставляем веса и смотрим что получилось:

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

Самое ценное в этом принципе то, что его использование предполагает диалог между бизнесом и инженерами.

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

А вот мой двухгодичной давности пост о приориетизации http://ashigabutdinov.ru/2016/02/07/1/

Вперед, к причинению пользы! ;-)

Еще по теме:

  1. http://www.summa.com/blog/what-is-wsjf-how-to-use-this-agile-concept-to-prioritize-work
  2. https://techbeacon.com/prioritize-your-backlog-weighted-shortest-job-first-wsjf-improved-roi
  3. https://www.scaledagileframework.com/wsjf/