Всё, что менеджеру проектов надо знать о Kanban
История и суть явления
Метод появился в компании «Toyota» в 1959 году. К айти имеет косвенное отношение, почитать про него можете в Википедии.
Канбан, как инструмент в IT-менеджменте был представлен Дэвидом Дж. Андерсоном в компаниях Microsoft (2005) и Corbis. А широкое распространение и название, как метод, получил в 2007 году.
В отличие от Скрама, Канбан не слишком строг. Скрам не может применяться частично, если вы используете не все практики, это уже не Скрам. В случае с Канбаном, нет правильного и неправильного Канбана, вы можете использовать те практики, которые вам лучше подходят.
Канбан может применяться не только в айти, но и везде, где есть регулярное производство с повторяемыми этапами, через которые должна проходить каждая задача.
Канбан-доска
Главный принцип Канбана — визуализация при помощи канбан-доски. Рассмотрим её подробно.
Левая колонка — очередь. По-хорошему, надо раз в пару недель проводить встречу по наполнению её задачами, но на практике обычно заинтересованные лица закидывают туда задачи по мере поступления. Можно установить ограничение на максимальный размер очереди.
Правее очереди следует расположить колонки допроизводственных этапов, на которых происходит сбор требований, оценка и утверждение задачи. Дальше идёт черта — точка принятия обязательств. Если задача пересекает эту черту, это означает, что она передана в производство и совершенно точно должна быть сделана и влита в продукт.
Перед последней колонкой вторая черта — точка отдачи обязательств, переход задачи через неё означает, что команда ручается, что с задачей всё в порядке.
Количество карточек в каждой колонке, кроме первой (это на ваше усмотрение) и последней, должно быть ограничено реальной максимальной пропускной способностью команды, она определяется экспериментально.
Канбан-доска — не только инструмент визуализации процесса, но и рефлексии. Внимательно рассмотрев доску, можно выявить производственные этапы, которые на самом деле не нужны, и наоборот недостающие этапы. По размеру очереди задач и накалу страстей на битве заказчиков за места в этой очереди, можно определить, насколько «жив» продукт.
Также при помощи этой доски вы можете выявить узкие места, «бутылочные горлышки», в которых скапливаются задачи и замедляют цикл производства.
WIP-лимиты
WIP (work in progress) — это количество элементов, находящихся в работе в настоящий момент. Его не надо путать с WIP-лимитом, ограничением на количество элементов в работе на настоящий момент времени, введённым для достижения некой цели.
Единой формулы для расчёта этого лимита не существует, он подбирается экспериментально. Одно можно сказать определённо — этот лимит вовсе не должен быть маленьким.
Использование WIP-лимита повышает определённость в работе. Потому что чем больше элементов в разных состояниях, тем тяжелее ими управлять и контролировать.
Для того, чтобы посмотреть максимальный WIP-лимит по команде, потребуется отчёт CFD (cumulative flow diagram) или накопительная диаграмма потока.
Каденции
Каденциями называются регулярные встречи при помощи которых вы можете поддерживать и улучшать канбан-процесс в команде.
Канбан-митинг
Пятнадцатиминутная ежедневная встреча. Команда собирается и обсуждает:
- Что нам мешает?
- Как осуществляется поток работы?
- Что мы можем улучшить?
Очень важно обсудить все заторы и затруднения в работе над задачами. Возможно, кому-то из участников нужно оказать помощь.
Встреча по пополнению
Получасовая встреча, проводится раз в неделю. Обсуждаем с заинтересованными лицами, какие новые задачи имеет смысл взять в работу и как переприоритизировать существующие, у них могла поменяться актуальность. Если получаса не хватает, можно общаться и дольше.
Обзор сервиса поставки
Получасовая встреча, раз в две недели. В этой встрече должны участвовать ключевые заказчики, менеджер и представители команды разработки. Обсуждаем удовлетворённость заказчика, показываем метрики, думаем, как же нам улучшить работу команды.
Встреча по планированию поставки
Эта встреча нужна, если у вас есть выделенные релизы. В современных айти-проектах всё чаще используется непрерывная интеграция, когда фичи вливаются в продукт по мере готовности, но всё становится сложно, если у вас есть несколько соседних продуктов и нужно обеспечить синхронность релизов.
Если это так, имеет смысл перед поставкой провести планирование списка фич, которые должны войти в поставку и обсудить, что для этого нужно сделать. Обязательно нужно спланировать мероприятия по обучению пользователей работе с вливаемой функциональностью.
Обзор рисков
Часовая ежемесячная встреча. Имеет смысл собраться со всей командой и обсудить, какие риски появились на горизонте, какие могут сработать, а какие уже сработали и влияют на поставку.
Обзор операций
Это кросспродуктовая встреча, на которой обсуждается межкомандное взаимодействие. Собраться с менеджерами соседних продуктов и обсудить, что мешает делать кросспродуктовые доработки. Раз в месяц достаточно.
Обзор стратегии
Самая редкая встреча, её достаточно проводить раз в квартал. Собираемся с руководством компании, обсуждаем рынок, среду, глобальные вопросы. Ставим цели для команды на квартал. Выявляем стратегические проблемы, корректируем тактику команды.
Метрики в Канбане
Важнейшая метрика в Канбане называется Lead Time — время прохождения задачи от точки принятия обязательств до точки отдачи обязательств. Чем быстрее задача проходит от одной точки до другой, тем команда эффективнее. Кроме того, есть ещё такие метрики:
- Cycle Time – время, которое задача находилась в разработке от момента, когда ей начали заниматься, до момента, когда она прошла фазу конечной поставки.
- WIP – количество задач одновременно находящихся в работе. Разделяется по разным стадиям работы над задачей.
- Wasted Time – время, которое задача проводит в различных очередях, а не непосредственно в работе.
- Effectiveness – процент времени, которое тратится непосредственно на работу с задачей, а не на ожидания в различных очередях.
- Throughput – количество задач, которое может выполнять команда в единицу времени (день, неделя, месяц).
Делаем правила явными
Нужно проговорить с командой и зафиксировать в виде документа все канбан-правила, которые будут применяться в вашей команде. Особенно важно описать критерии, по которым карточка перемещается из одной колонки в другую и при каких условиях она может быть перенесена обратно.
Хорошо и правильно проговорить с заказчиками правила приоритизации задач. Надо также надо обсудить протоколы, по которым будет проводиться работа со более и менее срочными задачами. Когда людям понятны правила, они готовы и хотят играть работать самостоятельно.
Кейс внедрения канбана в реальной практике
Когда я только начинал практику руководителя разработки, столкнулся с проблемой. Есть внутренний заказчик в виде группы внедрения, есть исполнитель в виде SQL-отдела. От заказчика к исполнителю постоянно поступает поток запросов на SQL-доработки — всевозможные отчёты, скрипты, кастомные импорты. И существует постоянно высказываемая претензия — совершенно невозможно понять, когда та или иная доработка будет сдана.
Оказалось, что отдел использует TFS (сейчас Azure DevOps Server), однако совершенно бессистемно. Кто-нибудь из руководства заводит запрос на доработку, вешает его на рандомного разраба и заказчики ждут у моря погоды. Если какой-то запрос нужен срочно, ответственный внедренец прибегает к руководству департамента и начинает орать. CIO транслирует ор в программиста, он в приоритетном порядке запиливает доработку. Тестировать её некогда, поэтому она сразу накатывается на базу заказчика. Если возникают проблемы, они никак не регистрируются, внедренец просто приходит в отдел SQL, подсаживается к программисту и просит поправить.
Частично этот кейс был рассмотрен в статье «Единая точка входа», но там больше про унификацию входящих обращений, в этой же статье мы поговорим про визуализацию и контроль при помощи канбана.
В первую очередь было принято решение визуализировать очередь. Хотелось использовать веб-приложение, потому что внедренцы крайне не любят ставить сторонние приложения (лол) и вообще, большую часть времени проводят в аутлуке. Выбор пал на trello. Первоочередной задачей стало завести на трелло-доске все открытые запросы на доработку из TFS. Trello тогда умел создавать карточки на основании писем, отправленных на специальную почту, а TFS умел экспортировать воркайтемы в эксель. Мой разраб минут за сорок накидал VBA-скрипт, импортировали запросы.
А вот дальше мы пошли вразрез с классическим канбаном. Вместо столбцов, отражающих этапы работы, мы завели по столбцу на каждого разраба и добавили в эти столбцы карточки запросов, над которыми они работали в данный момент.
Ситуация улучшилась, вместо: «Я не знаю, когда мы сделаем эту задачу», появилась возможность говорить: «Перед этой задачей в очереди ещё шесть задач, сможем взять её в работу после них». Удалось достигнуть договорённости — мы объявляем срок по задаче только после того, как она поступает в работу разрабу, но за этот срок уже отвечаем по полной программе.
Мы стали встречаться со старшим внедренцем два раза в неделю и обсуждать сроки по задачам, взятым в работу, а также положение разных задач в очереди. Так как 80 % задач были от одного и того же заказчика, мы разрешили внедренцу менять очерёдность задач этого заказчика. Если было нужно подвинуть задачи другого заказчика, внедренцы договаривались между собой.
Порядка стало больше, но возникла проблема с приёмкой задач. Так как внедренцы не торопились принимать задачи, их карточки намертво повисали в колонках разрабов, стали копиться внушительные хвосты. Так как решить проблему на организационном уровне не удалось, мы сменили инструмент.
kanbanize.com, в отличие от trello на тот момент поддерживал свимлайны. То есть, можно было завести для каждого разраба дорожку, а колонками сделать уже актуальные статусы, что сильно ближе к нормальному канбану. Кроме того, этот сервис позволял добавить кастомные поля к каждой карточке, что было для нас очень важно, так как кроме TFS-идентифкатора, каждый запрос имел CRM-идентификатор, которыми оперировали внедренцы.
В целом, сочетание организационных мер с правильно подобранным инструментом и методологией, позволили преодолеть кризис и сделать разработку предсказуемой. Негатив от внедренцев закончился.
