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... ), суммируются и делятся на размер работы. Размер работы тоже оценивается числами Фиббоначи, в общем оценкой в скрамовских сторипоинтах.
К примеру, следующий набор Фич для интернет-магазина:
- Приветственное письмо покупателю, сразу после того, как он получил на руки заказ от курьера
- Автоматический дозвон до клиента и соединение с оператором коллцентра после того, как клиент оставил заказ в интернет магазине
- Автоматичесая печать наклеек на пакеты для транспортной компании
Проведем оценку, чтобы было понятно почему такие значения, распишем Business Value и перечень технических задач на реализацию каждой Фичи:
Есть строгие правила проставления оценок:
- Заполнять по одной колонке за раз, начиная с самой простой Фичи, проставив ей оценку 1, остальные оценивать относительно первой единице
- Следствие: должна быть минимум одна единица в каждой колонке!
- Самое большое число по WSJF означает наиболее высокий приоритет
По мне, очень полезные правила, придерживаться которых следует, чтобы снизить коэффициент «ленинского прищура».
Расставляем веса и смотрим что получилось:
Иногда результаты могут получиться контр-интуитивными. Как видно из формулы, на приоритет Feature можно повлиять с двух сторон: оценка бизнес-важности, так и оценка со стороны сложности реализации. При низкой экспертизе оценщиков или плохой коммуникации между заказчиком и исполнителем, могут быть ошибки, приводящие к тому, что все делается не в оптимальной последовательности.
Самое ценное в этом принципе то, что его использование предполагает диалог между бизнесом и инженерами.
Кстати, если бы среди моих инженеров был тот, кто уже работал как с API CRM так и с API транспортной компании, оценка от технической команды могла быть для Фичи про печать наклеек гораздо меньшей.
А вот мой двухгодичной давности пост о приориетизации http://ashigabutdinov.ru/2016/02/07/1/
Вперед, к причинению пользы! ;-)
Еще по теме: