Как работает оценивание задач в Kanban на практике? | Agile тренинги, обучение и сертификации Scrum, Kanban, DevOps в Scrum Украина
 
The article is displayed in the original language.

Как работает оценивание задач в Kanban на практике?

Нужны ли какие-то оценки задач в Kanban методе?

17 июл 2020

Иногда бывает, что команды уходят от работы по Scrum'у к работе по Kanban'у, или к процессу который они называют Kanban'ом. По причине того, что Scrum страшно требователен к улучшениям и дисциплине. А может их контекст специфичен и не подходит для Scrum. Про Kanban иногда можно услышать следующее: “Kanban - это просто. Kanban - это три колонки и никаких заморочек. Если у Вас не получается Scrum - попробуйте Kanban, а может потом и наоборот. Не надо проводить кучу встреч, тратить время на оценивание элементов бэклога”. Так ли это, на самом деле? Или может быть оценивание задач в Kanban всё-таки существует? Как команда может делать прогноз о завершении проекта? Можно ли заказчикам рассчитывать на поставку фичи к нужной дате? На подобные вопросы попробую ответить в этой статье.

Для чего заказчику или бизнесу нужно знать когда работа будет закончена? Зачем нужны какие-то оценки задач? Вариантов может быть много:

  • для того, чтобы понимать приблизительно сколько будет стоить реализация в деньгах. То что команда, например, из пяти человек будет делать месяц, кроме всех остальных затрат компании, равняется сумме зарплат этой команды за месяц. Готов ли бизнес инвестировать столько денег в очередной набор фич? Настолько ли они нужны, окупиться ли это всё? А что если команда будет делать не месяц, а полтора или больше? Тогда получится еще дороже;
  • может быть этот набор фич надо сделать к какой-то дате, потому что уже есть договорные обязательства или внешние факторы, например, выставка или конференция;
  • от понимания когда будет выполнена работа, можно планировать смежные активности, например поставку фичи клиенту, рекламную кампанию и т.д.;
  • для приоритезации задач, минимизации рисков и задержек, для прогнозирования выполнения и т.д. и т.п.

Цель использования Kanban метода состоит в том, чтобы оптимизировать поток: выполняемая работа должна проходить лучше благодаря процессам. Если поток работы идет хорошо, он не застрянет. Результаты становятся предсказуемыми, а время производства становится короче.

Существует разница в подходе оценивания в Scrum и Kanban. Для оценки в Scrum фреймворке на практике часто используется популярный дополнительный инструмент - Planning Poker и оценки элементов бэклога в Story Points (SP), что является аналитическим подходом. При его использовании мы пытаемся посмотреть на данные по задаче, которые у нас есть в результате проработки элементов бэклога (рефайнмента), до того как мы приступили к её выполнению. И приблизительно всей командной угадать сколько это займёт усилий, в конечном счёте времени на выполнение.

Если вы пытались сравнивать план с фактом по задачам в своих командах, даже в Story Points на коротких и длинных периодах, обязательно заметите интересные закономерности, которые кстати полезно обсуждать совместно с командой. С помощью чего можно корректировать точность таких оценок в будущем. Самый простой пример, в одной из моих команд мы заметили статистически, что казалось бы очевидно, но зависит конечно от контекста, чем больше оценка задачи на старте (к примеру 5, 8 или 13) - тем по факту она займет еще больше времени в итоге. Чем больше оценка, тем больше неопределенности и неточности. В свою очередь это привело к командному пониманию важности декомпозиции (способов декомпозиции существует уйма) и теперь даже есть командная договоренность, что любую задачу с оценкой больше 2 SP - мы разбиваем на меньшие и точность оценки у нас увеличивается от 20 до 50% по факту.
Оценка же в Канбан основывается на статистике, есть базовые метрики и базовые графики на основании которых можно оценивать задачи, не аналитически, как часто бывает в Scrum, а эмпирически. Вообще этих метрик намного больше и там на самом деле целый мир, но давайте начнём с базовых, с которых можно начать уже сегодня при анализе вашего процесса, даже если вы работаете по Scrum.

Типичный Kanban Board в Jira выглядит вот так:

Alt Text

Красной линией в начале здесь обозначена точка принятия обязательств - то что команда берёт в работу. В этот момент принимается обязательство по поставке рабочего элемента. С этого момента начинается отсчет времени выполнения рабочего элемента.
Черной линией обозначена точка поставки - после которой элемент работы считается выполненным.

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

  • Throughput (пропускная способность) - сколько задач проходит через доску или через систему от точки принятия обязательств к точке поставки. Эта метрика дает ответ на вопрос: ”сколько элементов мы выполняем за единицу времени?”. Например, команда выполняет 20 элементов бэклога итерации за две недели. А в проработанном общем бэклоге 100 элементов, грубо говоря есть еще работы на 5 итераций, но это не очень точно без учёта всех других показателей.

  • Lead Time (время производства или время выполнения) - время, в течение которого рабочий элемент переходит от точки принятия обязательств к точке поставки. Например, это может быть 5 дней.

  • Cycle time (время цикла) - время, в течение которого рабочий элемент проходит через часть процесса, например, через анализ и разработку, но без тестирования. Например, это может быть 3 дня.

  • Flow efficiency (эффективность потока, %) - рассчитывается по формуле:

Alt Text

Источник изображения: https://getnave.com/blog/flow-efficiency/

Active time - время непосредственной работы над задачей;
Waiting - время ожидания, в колонке (статусе) ожидания.

Визуализация этих всех метрик на графиках и диаграммах позволяет наглядно увидеть зависимости, тенденции и общее состояние эффективности потока. Основных диаграмм в Kanban методе три (CFD, CC и LTDC). Дальше я опишу их по очереди.

1. Cumulative Flow Diagram (CFD) - накопительная диаграмма потока в теории, например на три колонки To Do, In Progress, Done - будет выглядеть вот так:

Alt Text

Источник изображения: https://getnave.com/blog/how-to-read-the-cumulative-flow-diagram-infographic/
Tasks - кол-во задач;
Time - время;
To Do - делать (зеленый цвет на диаграмме);
WiP - Work in Progress - работа в процессе (бирюзовый цвет на диаграмме);
Done - сделано (синий цвет на диаграмме);
Apprx. Average Cycle Time - приблизительное среднее время цикла;
Average Throughput - средняя пропускная способность;
Arrival Rate - скорость от попадания в To Do до Done;
Departure Rate - скорость от попадания в In Progress до Done.

На практике в Jira без дополнительных плагинов, если у вас нет возможности использовать другой инструмент типа swiftkanban или kanbanize, CFD может выглядеть вот так:

Alt Text

Тут диаграмма построена за период более трёх лет (с 01.04.2017 по 28.06.2020), но показывает общую картину за весь период. Её можно зумить, уменьшать диапазон и анализировать более подробно. Хотя лучше использовать конечно плагин Nave, который можно ставить на Jira и строить очень много полезных отчётов и дашбордов автоматически.
Эта диаграмма очень полезна для поиска узких мест, простоев, неэффективности вашего процесса.

2. Control Chart (СС) - контрольная диаграмма показывает время цикла (Cycle Time) или время выполнения (Lead Time) для вашего продукта, версии или спринта. Для построения берется время, затраченное каждым элементом работы в определенном статусе (или статусах), и отображается в течение определенного периода времени. Контрольная диаграмма показывает нам момент события которое возникло в конкретную дату.

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

Для примера, я взял Control Chart той же команды, которая работает с Kanban board в Jira более трёх лет. При наведении курсора на красную линию можно увидеть всплывающую подсказку с метриками - Rolling average (среднее скользящее значение, синяя линия на графике) и Standard Deviation (стандартное отклонение). Если сложить эти два числа, то мы получим значение которое находится на верхней границе диапазона или на нижней. Average (красная линия) - это общее среднее значение, которое находиться между всеми задачами в выбранном диапазоне по времени.

Alt Text

Alt Text

Alt Text

По вертикали Elapsed Time - нелинейная шкала, которая показывает затраченное время или Circle Time в выбранных колонках на доске.

По горизонтали Issue Transition Date - показатель даты последнего события изменения состояния.

Alt Text

Alt Text

Alt Text

Alt Text

Alt Text

В данном примере вы видим, как эти показатели менялись за 3+ года. Суммарно через систему прошло 1996 задач - это пропускная способность (Throughput) за это период. В середине периода было ухудшение показателей, а потом улучшение, но всё таки в итоге немного хуже чем на старте работы команды. Это средние значения времени за которые элемент проходит через систему, и значение отклонения от этого показателя. В этом случае границы системы от In Progress (точка принятия обязательств) до Done (точка поставки). На эти цифры можно опираться при прогнозировании.

В самой Jira есть подсказки - линк в верхней части экрана “How to read this chart” - объясняет как правильно читать и анализировать этот график:

Alt Text

Visibility - это видимость, наглядно видно задачи, Lead Time которых сильно больше других. Точечно можно анализировать их, выявлять причины и работать над тем, чтобы в будущем не допускать подобных отклонений. Пример, если кликнуть на кружок события, появится попап в котором можно увидеть сколько по времени задача находилась на каждом из этапов работ.

Alt Text

Alt Text

Efficiency - эффективность процесса. Синяя линия является отображением Rolling average (скользящее среднее значение). Она должна со временем опускаться, что будет сигнализировать о том, что вы работаете над улучшением эффективности потока, сокращая Cycle Time элементов. В реальном примере Control Chart выше, мы видим, что со временем ближе к середине она поднималась, что сигнализировало об ухудшении эффективности потока. А затем линия начала плавно опускаться, что говорит об улучшениях. Но, можно и нужно проводить анализ на более коротких промежутках времени и тогда будет всё более точечно и понятно. Например, можно делать ежемесячный анализ этой диаграммы и сравнивать месяц к месяцу.

Alt Text

Predictability - предсказуемость, тут показывается, что необходимо со временем стремится к сужению стандартного отклонения при корректировках процесса, что в свою очередь позволит улучшить предсказуемость времени цикла (Cycle Time) и ускорить систему Опять же в примере выше к середине периода произошло расширение, а дальше плавное сужение, которое вернулось к начальным показателям. В целом значительных улучшений или ускорения системы за этот весь период не произошло. Если синяя линия близка к красной, то статистически это примерно +/- стабильная система.

Дополнительно в нижней части под Control Chart есть “Refine report”, где можно настроить фильтры по Columns, Swimlanes, Quick Filters. Выглядит это так:

Alt Text

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

3. Lead Time Distribution Chart (LTDC) - спектральная диаграмма распределения времени выполнения. Этой диаграммы в стандартных отчетах Jira нет, но она позволяет увидеть распределение частоты того, как часто элементы работы выполняются при различных значениях времени выполнения. Её можно строить в Excel по выгрузкам из Jira. Выглядит она вот так:

Alt Text

Если мы начнем измерять и анализировать то, как долго и в каком кол-ве задачи проходят через нашу систему, нам станет визуально понятно, какой min, avg, max у нас бывает Lead Time в целом.
Приведу пример, на диаграмме выше видно, что через систему прошло 200 элементов работы. Максимальный Lead Time у одной из задач был 9 дней, а большинство задач - 90 штук выполняются за 3 дня. Из этого следует, что на момент составления этой диаграммы мы можем обещать тем кого обслуживает наш сервис, что запрос будет обработан в период от 1 до 9 дней, но чаще всего это от 2 до 4 дней, если с процентами точности то (20+35+90+30=175 и 175/200=0.875) с вероятностью 87.5% мы уложимся в 4 дня. А с вероятностью в 100% уложимся в 9 дней. Конечно важно регулярно снимать и анализировать эти показатели, перед тем как что-то кому-то обещать, но основной принцип думаю понятен. С помощью LTDC можно давать прогнозы выполнения задач с определённой точностью исходя из статистических данных.

Конечно же такой подход не может существовать сам по себе, и он напрямую зависит от того что в вашу систему попадает на вход и насколько предсказуемо.
Есть такой Канбан анекдот: “Когда Билл Гейтс входит на стадион, то в этот момент, в среднем, все на стадионе миллионеры”. Задача менеджера который отвечает за попадающие в систему элементы бэклога - не пускать Билла Гейтса :) Другими словами не пускать в систему огромные долгоиграющие задачи, которые на порядки отличаются от обычного диапазона, в примере выше это значения от 1 до 9 дней. Или если всё таки пускать, то учитывать это при точности вашего прогноза.

Самый простой способ с чего можно начать?

Если сильно всё упростить, то для начала можно начать считать пропускную способность (Throughput) вашей системы за одинаковый выбранный период - неделю, спринт, месяц. Попробуйте проанализировать те данные за прошлые периоды, которые уже есть - интересные инсайты для размышлений обеспечены. Есть реальные Scrum-команды, которые меряют velocity команды в штуках закрытых задач и этого им достаточно для планирования. Формальной предварительной оценки задач там нет, но эффективная проработка и декомпозиция элементов бэклога будущих итераций обязательно присутствует.

Итоги

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

Регулярно анализируя даже только описанные выше основные диаграммы в Jira, метрики и постепенно улучшая процесс эволюционно можно добится улучшения показателей и повысить предсказуемость доставки элементов работы. Jira - не является лучшим инструментом для работы по Kanban, потому что плохо обеспечивает всю полноту возможностей для применения метода. Но в наших реалиях чаще всего присутствует в наличии в организациях, в которых мы работаем именно Jira. Kanban University рекомендует использовать следующие инструменты: Nave (плагин на Jira), swiftkanban и kanbanize, остальные инструменты пока не аккредитованы и не позволяют в полной мере использовать потенциал метода.

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

Recommended events

training
Dmitry Nezabytovsky  

Kanban Foundations is the author's class for those who want to understand in detail the essence of the Kanban method and learn how to apply it in their context.

training
Evgeniy Labunskiy  

A two-day course on the basics of Agile and the Scrum and Kanban frameworks. The certification course, upon its completion, participants receive personalized certificates ICAgile Certified Professional - Agile Fundamentals (ICP), which are recognized worldwide.

training
Alexey Krivitsky, Evgeniy Labunskiy  

This certified online course will reveal the world of large-scale product development for 5, 10 or 110 teams. On such a scale, a lot of questions arise for leaders and Scrum-masters of organizations

Recommended articles

Advanced Certified Scrum Master

Углублённая 6-недельная программа развития и поддержки Скрам Мастеров с сертификацией

25 идей, как остаться эффективной командой, работая из дома

23 марта мы провели мега-вебинар на 500+ человек, посвященный поиску идей, как командам эффективно работать по ремоуту и обмену опытом. Всего получилось больше 50 идей, все они изложены: здесь

Полная видеозапись вебинара: здесь!

Смотрите и будьте продуктивны!

Agile команды теперь работают из дома, WTF?

Это произошло. Стремительно. У нас были десятилетия подготовиться. Но мы были заняты работой. Теперь самое время взять ситуацию в руки и начать вырабатывать хорошие командные привычки работы из дома.

We are active on social networks and want to communicate. Add to our facebook page and join our communities.

For coaching and corporate programs:
+380 67 6783099 office
+380 63 8107225 Eugene
hello@scrum.ua

For public classes, registrations, accounts:
+380 67 6783099 office
+380 93 4974661 Kateryna
backoffice@scrum.ua

On all phone numbers - voice, sms, viber, whatsapp.

©2017 - 2020 Scrum Ukraine. All rights reserved.