Адель Шигабутдинов

Сеньор помидор. Бложек ведущего разработчика и тимлида, трансформировавшегося в менеджера проектов :-)

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/

Говори как менеджер (урок английского)

  1. find out what’s wrong —> identify the problem
  2. fix the problem —> resolve the issues
  3. give people confidence —> motivate my employees
  4. give clients my attention —> focus on our clients
  5. spend as little as possible —> minimise our expenses
  6. make as much money as possible —> maximise our earrings
  7. get more work —> generate more business
  8. use the new ideas —> implement the strategies

identify risks, person, reasons, ways
resolve the situation, crisis, disagreements, tension
motivate the staff, team, kids, spouse
generate more sales, revenue, interest, enthusiasm
focus on priorities, goals, studies, health
minimize costs, time, noise
maximise profit, efficiency, grades, investments
implement the changes, policies, safety rules, suggestions

Продолжение уроков: https://www.engvid.com/speak-like-a-manager-verbs-1/

4 апреля   Обучение   Полезное

Как косячить

Илью зовут на вечеринку в 20:00. Чтобы успеть, Илья должен выйти с работы в 19:00. Попросили по дороге заехать за пиццей. «Успею», — думает Илья.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки, приедет он с опозданием на час-полтора. Но Илья никому не звонит, потому что не хочет краснеть перед друзьями.

19:35 «Да и потом, это ж вечеринка, никто не приходит вовремя, да и все знают, что в городе пробки».

19:40 «И они могли бы и раньше меня позвать, я бы как-то лучше распланировал свой день».

19:50 Илье пишут друзья: «Ну что, ты где?». Илья видит уведомления, но не открывает их, чтобы не было галочки «прочитано». Неудобно, что он так поздно выехал.

20:10 Друзья звонят. Илья не берет трубку, зная, что придется краснеть.

20:30 Илья придумывает шикарную отмазку и перезванивает: «Только вышел с совета директоров, эти дебилы никак не отпускали, еле вырвался. Извините, всё, сейчас прыгну в машину и приеду к вам».

20:45 Илья заходит за пиццей. Понимая, что провинился, он покупает раза в три больше, чем его просили.

21:30 Илья появляется на пороге. До него уже успели заказать пиццу и ее только что привезли. Несмотря на полные пакеты и дикие извинения, Илью принимают холодно.

00:00 Большая часть закусок и пиццы остыла и высохла до того, как к ней успели притронуться.

Что в итоге. Илья потратил кучу денег, подпортил отношения и из-за него высохло четыре невинные пиццы.

Или нет, погодите. Всё было не так.

19:00 Илья ковыряется на работе.

19:30 Илья выходит с работы. В городе пробки. Илья переборол стыд и звонит друзьям: «Ребзя, я опаздываю, извините, буду во столько-то. Могу рвануть на метро, но тогда не смогу заехать за пиццей». Друзья в один голос: «Ой, да плевать на пиццу, приезжай скорее. Пиццу закажем».

20:10 Илья выходит из метро и звонит друзьям: «Тут возле выхода есть универмаг, у них должна быть замороженная пицца, взять?» Оказывается, пиццу уже заказали, но нужно докупить выпивки. «И чипсов!» «И сладенького!» «И на завтрак ничего нет!» «И туалетной бумаги десять рулонов!»

Ну, бывает.

20:30 Илья появляется на пороге с пакетами. Его встречают, как героя. Как раз все в сборе.

Что в итоге. Илья потратил немного денег, и хотя он закопался на работе и опоздал, все кайфанули.

Замените вечеринку на статью, друзей на клиентов, пиццу на интервью с экспертом, пробку на творческий кризис, а «восемь вечера» на «дедлайн» — получится редакторский проект. Замените на дизайн в соответствии с брендбуком — будет проект с дизайнером. Задача по работе мало чем отличается от задачи для друзей.

Мораль

Как грамотно косячить на проекте:

Бить тревогу. Не ждите, что проблема решится сама. Увидели, что на улицах пробки — не ждите, что они волшебным образом пропадут. Не тяните до без пяти минут дедлайн: чем раньше скажете о проблеме, тем легче всем подстроиться.

Приходить с решением. Не просто «опаздываю», а «опаздываю, предлагаю заказать пиццу по телефону».

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

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

Делать не то, что можешь, а то, что нужно. Есть распространенная ошибка: редактор сорвал срок и решил, что теперь-то он не имеет права на ошибку. Он решает вылизать статью до совершенства (все еще не отвечая на звонки).

Расчет такой: «Я уже опоздал, зато когда они увидят мою статью, они всё простят, ведь это будет лучшая статья в мире». Но клиенту нужна хоть какая статья сегодня-завтра, потому что послезавтра журнал уходит в печать. Через три дня ему статья не нужна, даже лучшая в мире.

Поэтому нужно не статью писать, а придумать, как сдать ее в печать сегодня. А для этого нужно позвонить с клиентом и договориться.

Совсем мораль

Если коротко, то правила на самом деле три:
1. Общаться, а не молчать. Все проекты ломаются тогда, когда люди начинают делать каждый свое, не не держа друг друга в курсе. Видите проблему, даже со своей стороны, — сообщайте о ней. Вместе с клиентом вы придумаете, как ее решить.

2. Помогать, а не увольняться. У многих, когда они косячат, включается комплекс отличника: «как же так, я что-то сделал плохо, я плохой, я недостойный, сейчас меня уволят». Это ерунда. Клиенту наплевать, хороший вы или плохой. Ему надо решить задачу, и ваш косяк — просто обстоятельство.

Представьте, что это не вы накосячили, а кто-то другой. Что с этим делать? Как получить полезное действие в этих новых условиях? Придумайте решение и идите с ним к клиенту.

3. Не быть бараном. Накосячили — признайте, не оправдывайтесь. И чините, а не ждите, что всё исправят за вас.

Источник: Ильяхов

Полезное по теме
Начитаются кемпами и травят леску за гаражами

Про скорость разработки в Канбан

В августе 2016 года на одном из проектов установили ограничение Work In Progress равное количеству девелоперов работающим над проектом. Т. е. если кто-то заболевал или уходил в отпуск, ограничение Work In Progress уменьшалось на единицу. При добавлении разработчиков, увеличивалось на единицу.

На скриншоте Control Chart в Jira и эффект от внедрения данной практики:

Rolling avarage дней между «взято в разработку» и «готово к релизу» (конкретно на этом проекте даже выкачено на продакшен) снизилось с 7.4 дней до 2.7 дней.

То есть бизнес стал получать свою функциональность в два раза быстрее.

Недавно проводил мастер-класс новой проектной команде по Канбану и WIP:

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

Частая картина в девелоперских командах:

  1. Программист взял Задачу 1 в разработку
  2. Отправил Задачу 1 на тестирование
  3. Тестер приступил к тестированию через 5 часов
  4. Программист пока взял Задачу 2
  5. Задача 1 вернулась с багом
  6. Программист решает закончить Задачу 2
  7. Через 3 часа программист отправляет Задачу 2 на тестирование
  8. Программист возвращается к доработке Задачи 1
  9. Через час исправляет баг и отправляет Задачу 1 на тестирование
  10. Через 2 часа Тестировщик приступает к тестированию Задачи 1
  11. Задача 1 отправляется в релиз

Итого время простоя задачи
на пункте 3: 5 часов
на пункте 7: 3 часа
на пункте 10: 2 часа

Проблемы бесконтрольного набора задач:

  1. Задача долго отлеживается, перед тем как её возьмут на тестирование, потому что тестировщики заняты тестированием других задач
  2. Задача долго отлеживается после возвращения на доработку, потому что программист пока ждет результатов тестирования, взял себе на разработку уже другую задачу, и пока ее не закончит, к доработкам вернувшегося тикета не приступит.

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

Так вот, в моих командах, процесс устроен следующим образом:

  • Ограничение WIP = кол-во девелоперов на проекте
  • Пока программист реализует задачу, тестировщик ждет: читает хабр, доки, занимается планированием собственной работы, какими-то улучшениями, общением с аналитиками по задачам в разработке
  • Как только задача готова, тестировщик принимается за ее тестирование.
  • Программист находится в активном ожидании обратной связи от тестировщика и читает хабр, документацию, занимается самосовершенствованием, помогает тестировать
  • Как только задача возвращается на доработку — берет ее в ту же минуту и быстро исправляет недочеты. Это легко, т. к. программист находится в контексте задачи и прекрасно помнит что именно где править
  • Как только задача завершена, тестировщик в ту же минуту проводит повторное тестирование, и если все ОК, отправляет в релиз.
  • Как результат:

    1. минимальное время на реализацию задач
    2. минимальное количество задач погрязших в болоте доработок
    3. у программистов и тестировщиков есть время на саморазвитие
    4. бизнес подразделение довольно: новая функциональность начинает приносить деньги сразу же, а не «через 2 недели, когда будет релиз»

    + Полезное из переписки на facebook:

    Про внимание к деталям

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

    Про скрам

    Возни много, все потеют, а к забитым голам отношения никакого.

    2017   Scrum

    х

    Вот какая мысль мне пришла о несоответствии выпускников ВУЗов с требованиями на работе. К нам приходят бакалавры и магистры, а мы ждем инженеров.

    В итоге выпускник ВУЗа тратит несколько лет на то, чтобы в бою освоить:

    • Объектно ориентированное программирование
    • Паттерны проектирования ООП
    • Работу с реляционными базами данных
    • Работу с не реляционными базами данных
    • Несколько фреймворков
    • Несколько ORM
    • Базовые функции операционных систем
    • Основы администрирования серверов
    • Опасные баги
    • Способы решения каких-то нетривиальных задач
    • Системы контроля версий
    • Технологический процесс производства ПО
    • Пару методологий ведения проекта
    • Как выяснять требования
    • Как тестировать
    • Как рефакторить
    • Как работать в команде

    И дальше уже ставший инженером, идет дальше работать, развиваться, приносить пользу себе, работодателю, миру.

    Я очень люблю умных ребят. Огромное уважение вызывают те, кто умеют сходу оценивать O-сложность алгоритмов, разбираются в структурах данных, вообще с хорошими скиллами в Computer Science. Но на практике же большинство этих скиллов в решение повседневных задач практически и не применяются. Опыт решает.

    Такие дела.

    Иннополиса ребят пост

    В этом году университет Иннополиса выпускает вполне себе умных, живых и интересных ребят. Удивляет, что много ребят из Казахстана, Сибири, Москвы, а из Казани, наоборот, совсем немного. По крайней мере из тех, кто до меня дошли.

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

    Фото сделано при выходе из междугороднего автобуса в 8:55 21 апреля 2017 г.
    Когда еще снегопад за неделю до майских праздников увидим? :)

    Канбан (Манн-Иванов-Фербер)

    Обнаружил и начал читать свежую книгу про Канбан. Могу сказать, что она совершенно замечательная, полезная и я всем проектным управленцам ее теперь буду яростно рекомендовать.

    Очень легко и понятно сформулированы все вещи, которые мы на своем опыте прошли и сохранили в виде не описанного опыта и ощущений «спинным мозгом» того, что правильно и работает, а что нет.

    http://www.mann-ivanov-ferber.ru/books/kanban/

    2017   kanban   Книги
    Ранее Ctrl + ↓