Kanban для Scrum-команд

Как я писал в статье “Чем Scrum отличается от Kanban и при чем тут Agile”, основная цель Scrum — создать новый продукт. Чтобы это реализовать, собирают кросс-функциональную Scrum-команду и итеративно-инкрементально выпускают версии продукта несущие ценность.

Зрелая Scrum-команда обычно хорошо сработалась и обладает высокой экспертностью как в продукте, так и в своей работе.

Чем такой команде может помочь Канбан-метод? Ведь Kanban-метод фокусируется совсем на других вещах — на том, чтобы работа подразделения стала предсказуемой, подразделение знало свои возможности, и, главное, чтобы заказчики планировали загрузку подразделения, исходя из этих данных.

Рабочий ритм без выгорания

Один из принципов Agile звучит так:

«Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely»

Перевод: “Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки”

То есть, Agile не поощряет работу по выходным и по ночам ради успеха продукта. Нужно найти оптимальный для команды и бизнеса ритм работы, которого и придерживаться.

Но на что опираться при выборе оптимальной нагрузки?

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

То есть, говоря в терминах Канбан-метода, Scrum-команде надо определить свою оптимальную пропускную способность и выяснить, сколько задач за спринт она может выполнить без переработок и с достаточной ценностью для заказчика.

Откуда брать данные для анализа?

Одной из метрик Scrum-команды является Velocity — некий ориентир возможности команды по загрузке на каждый спринт. Для его определения используют график Velocity Chart, где можно посмотреть, сколько команда планировала сделать в каждом спринте и сколько реально удалось сделать.

Но с этим графиком есть одна сложность. Как правило, значение Velocity делается в относительных единицах трудоемкости задач — Story Points. На графике мы видим сумму всех оценок задач в Story Points. Такой подход скрывает от нас количество сделанных задач.

Если мы смотрим на Velocity Chart и видим, например, цифру 30 Story Points — что это значит на практике? Значит ли это, что команда сделала одну задачу на 30 SP? Или что она сделала 10 задач по 3 Story Points?

График Velocity Chart нам этого не расскажет. А именно эту цифру нам надо знать, чтобы посчитать пропускную способность команды и выбрать оптимальную нагрузку.

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

Вот пример графика пропускной способности:

Но здесь много значений пропускной способности — от маленьких до больших. Какое же из них взять за основу? Среднее значение брать довольно рискованно, так как это может сыграть с командой злую шутку.

Представьте себе: в комнате находится 3 сотрудника с зарплатой 50 тыс. рублей. Среднее значение зарплаты в комнате — 50 тыс. рублей. И вот в комнату входит ТОП-менеджер с зарплатой 3 млн. рублей, и средняя зарплата людей в комнате сразу подскакивает до 787,5 тыс. руб. Это явно завышенное значение, на основе которого никаких долгосрочных выводов делать нельзя.

Более правильно было бы использовать медианное значение. Медианное значение зарплаты для вышеописанной ситуации будет равно 50 тыс. рублей, вне зависимости от того, есть ТОП-менеджер в комнате или нет.

Точно так же использование среднего значения для анализа пропускной способности для Scrum-команды будет некорректным.

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

Достоверная оценка сроков задач

Обычная практика при работе по Scrum — использовать коллективную относительную оценку задач. В этом есть большой смысл для сплочения команды, для обмена опытом и наращивания зрелости команды.

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

Вероятностное прогнозирование

Вместо экспертного прогнозирования, можно использовать исторические данные о работе команды, и применить подход вероятностного прогнозирования. Используя этот подход, можно давать оценки сроков задач с точностью 80-90%, что является вполне достаточной точностью для большинства бизнес-задач.

Что нужно, чтобы это сделать?

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

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

Допустим, у нас есть исторические данные за 3 месяца по времени выполнения задач типа “дефект”. Тогда мы можем построить график распределения времени выполнения этого типа задач. Такой график называется Lead Time Distribution.

На вертикальной оси откладывается количество завершенных задач, на горизонтальной — время выполнения задач (Lead Time).

График показывает нам, сколько задач за какое время было выполнено. Например, одна задача была завершена за 6 дней, а 7 задач было выполнено за 9 дней.

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

Из курса высшей математики известно, что вероятность события — это соотношение количества N успешных событий (в нашем случае успех — это завершение задачи за 11 дней или быстрее) к общему количеству событий M:

P = N/M

где N — количество задач, время выполнения которых было в пределах 11 дней — их на графике 25 штук,

а M — общее количество задач на графике за 3 месяца — на графике видно, что всего за этот период было выполнено 30 задач.

Таким образом, получаем:

P = 25/30 ≈ 0, 83 

Чтобы повысить точность прогноза, можно пристальнее посмотреть на задачи типа “дефект” и разделить их по какому-то еще признаку. Например, по затронутому модулю, или по наличию или отсутствию интеграций, которые были затронуты дефектом, и т.д. Таким образом, мы можем получить несколько видов дефектов, и по каждому из них построить свое распределение Lead Time. Это позволит увидеть еще более точную картинку, и давать прогноз еще точнее.

Имея достаточно исторических данных, Scrum-команда может опираться на прогноз времени завершения задач с точностью 80-90% и радикально сократить время на планирование спринта.

Налаживаем контакт со смежниками

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

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

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

Канбан-метод предлагает коллекционировать эти причины, и периодически производить их группировку по источникам.

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

Получится несколько “кластеров” причин. Как внутренних причин — тех что можно решить силами самой команды. Так и внешних причин — тех, на которые команда не может повлиять напрямую.

Например среди внешних причин могут получиться такие кластеры:

• “согласования”;
• “ждали команду шины данных”;
• другое

Зачем коллекционировать эти данные?

Они позволяют нам понять, какие причины ожиданий являются повторяющимися и систематическими. А также позволяют оценить их влияние на работу команды.

Например, если по данным видно, что количество блокировок по причине “ожидание команды шины данных” постоянно растет, то стоит поднять вопрос о выделении отдельного ресурса шины данных для работы команды или о том, чтобы перетаскивать компетенции по шине данных к себе в команду.

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

Заключение

Канбан-метод позволяет:

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

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

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