Украинскую версию статьи можно прочесть тут.

Иногда бывает, что команды уходят от работы по 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 выглядит вот так:

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

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

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

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

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

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

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

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

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

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

Источник изображения: 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 может выглядеть вот так:

Тут диаграмма построена за период более трёх лет (с 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 (красная линия) - это общее среднее значение, которое находиться между всеми задачами в выбранном диапазоне по времени.

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

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

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

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

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

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

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

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

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

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

Если мы начнем измерять и анализировать то, как долго и в каком кол-ве задачи проходят через нашу систему, нам станет визуально понятно, какой 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 нельзя внедрить с нуля - его можно применить к какому-то рабочему процессу, который у вас уже есть и который вы хотите улучшить. Спасибо за внимание, надеюсь материал был вам полезен.