Kanban - как жить по цветным бумажкам

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

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

Зачем канбан?

1. Прозрачность работы, рабочего процесса
2. Быстрое внедрение новых фич, переход от больших релизов к более мелким и частым
3. Наглядное планирование, ограничение числа незавершенных задач
4. Структурирование работы команды. Не начинаем новое, пока не закончили старое
5. Выявление "бутылочного горлышка" команды (этапов, которые тормозят процесс производства)
6. Представители других команд могут ориентироваться на наши сроки просто глянув на доску

Ценности канбан:

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

РОЛИ В КАНБАНЕ:

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

С ЧЕГО НАЧАТЬ:

Начали мы с того, что выделили стену под наши канбан-нужды. Потом разделили ее на части:

Очередь
Оценка
Аналитика
Разработка
Тестирование
Приемка

Через все части провели FastLine - линия, по которой карточки едут без очереди и лимитов, обычно это криты с прода.

Каждую часть разделили пополам - "в работе" и "готово". Определили WIP-лимит (work in progress) для каждого этапа разработки, т.е. то количество задач, которое каждый отдел может выполнять в один отрезок времени. Иногда расчет делается: количество человек минус 1. Т.е. если в команде 6 разработчиков, то WP равен 5. Но это не всегда работает. WIP-limit нужен для ограничения числа незавершенных задач. Если работы по задаче остановлены, но не завершены, ее лучше убрать в очередь, а потом вернуть на доску, когда придет ее черед. Но задача канбана, в том числе, понять - почему в работу попадают задачи, завершить которые сразу невозможно.

Определили какой из этапов мы считаем стартом разработки, повесили карточки CP - commitment Point, т.е. готовность к старту. Именно после пересечения этого места на доске на карточке задачи проставляется первая дата. На выходе повесили второй CP - когда релиз уходит в продакшн, это последняя дата на карточке. Определили, зафиксировали и повесили критерии перехода карточки по доске. Пока все критерии не соблюдены, карточка переехать не может.

Статьи на тему WIP-limit и CommitmentPoints можно почитать, например, тут: https://kanbanize.com/blog/what-are-commitment-points-in-kanban/

НЕКОТОРЫЕ ПРАВИЛА:

В оценку карточку заносит менеджер запросов. Он же решает когда карточка пересечет первый commitmentPoint и проставит даты и номера релизов
Карточка работы по задаче вешается на одни сутки. Нельзя повесить карточку на два дня. Если задача займет 2-3 дня, то следует ее декомпозировать и ставить на сутки конкретную цель (хотя бы "30% кода по методу apply написано").
Блокер вешается не больше, чем на 5 дней. Если он переезжает все дальше, это уже проблема, которую надо подстветить.
Все карточки ресурсов "припаркованы" на отдельной доске (у одного члена команды 3 ресурса, т.е. 1 карточка это треть рабочего дня). Если к концу ежедневного митинга какие либо карточки остались на парковке, значит у людей есть свободное время, которое можно распределить на другие задачи. От чистки бэклога до самообучения.
Для лидов и сотрудников приемки изначально заводятся 1-2 карточки, которые ходят по доске, остальное рабочее время они тратят на другие задачи (менеджмент, поддержка инфраструктуры).
Карточка может ходить по доске и в обратную сторону, но желательно до такого не доводить.
Регулярно необходимо проверять очередь - актуализировать ее, выкидывать то, от чего отказались.
На ежедневном стендапе присутствуют все, в том числе удаленщики в скайпе.
Стендап начинается с зачитывания карточек в обратную сторону - с приемки к тестированию и т.п.
Каждая карточка зачитывается быстро, вслух. После того, как прочтена карточка задачи, исполнитель по ней отчитывается, сделал он запланированное, или нет, а потом озвучивает планы на следующий день.
ежедневный митинг должен занимать не больше 20 минут. Хорошее время - 10 минут.
По окончании митинга доски фотографируются и выкладываются в общий чат, для удаленщиков
Не стоит переезжать на электронные канбан-доски пока процессы не установятся, пока команда не войдет в ритм, т.е. минимум 3-4 месяца необходимо использовать физические бумажные карточки. Лучше 6 месяцев. Но некоторые команды оставляют именно этот вариант насовсем.

Виды карточек канбан:

Главная карточка - прямоугольная карточка задачи. На ней мы пишем саму задачу (долгосрочную или краткосрочную). У нее должен быть номер issue в Jira, короткое описание, релиз, в котором задача пойдет в прод, дата начала работ (после пересечения первой CommitmentPoint), предполагаемая дата установки в прод. Когда релиз уйдет в продакшен, пишем третью дату (после пересечения второй CommitmentPoint). Также нужно указать размер задачи, ее приоритет и проект, в рамках которого она разрабатывается. Каждая карточка представляет конкретный элемент работы, создающий ценности для заказчика.

Определение размера задачи (в ч\часах):

XXS < 60
XS < 180
S < 400
M < 800
L < 1600
XL < 3200

Карточка работы по задаче заполняется ежедневно. На ней мы записываем как совершённый факт то, что будет сделано до завтрашней встречи (проверено, исправлено etc.). Эта карточка ВСЕГДА заполняется на 1 день, от стендапа до стендапа. Если работы по задаче вестись не будут, мы либо вешаем на нее блокер (что мешает - отсутствие ресурса, информации или еще что-то).
К ежедневной задаче мы добавляем карточки количество ресурсов (маленьких квадратики со своим именем), которое планируем потратить именно на эту задачу до завтра из расчета 1 карточка примерно 2.5 часа. Если на задачу планируется потратить меньше часа, ресурс можно не вешать.

Карточки задачи бывают плановые (желтые), технические (голубые), розовые (проблемы из прода).

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

Чек-лист добавляется к карточке задачи, если задача будет в работе более 5 дней. В таком случае она декомпозируется на более мелкие задачи и расписывается с примерными датами окончания каждого этапа.

Регламент канбан:

Ежедневные встречи (standup-ы). Состав участников - вся команда. Итоги встречи публикуются в чате (фото доски).
Еженедельные встречи по пополнению доски новыми задачами проводятся раз в неделю. Состав участников - представители бизнеса, владелец продукта.
Ревью сервиса поставки. Состав участников - вся команда. Важно проводить ретроспективу раз в месяц всей командой, чтобы понять, какие есть проблемы, как их решить.
Чтобы ускорить ежедневные митинги, карточки со своими задачами на день (от митинга до митинга, т.е. на сегодня и завтрашнее утро) необходимо готовить заранее. Те, кто присутствует на митинге удаленно, может попросить коллег в офисе записать свои задачи на карточке, скинуть свой статус в чат по канбану.

Сценарий "проезда" карточки по доске Канбан:

0. Карточка попадает в очередь
1. Владелец Продукта инициализирует продвижение карточки на доску в раздел ОЦЕНКА
2. По окончании оценки, при соблюдении всех критериев, карточка переезжает в ОЦЕНКА.Готово

ОЦЕНКА. Критерии окончания работ:
• оценки выложены
• проставлены estimate в Jira
• размер карточки заполнен
• дата выхода в прод определена

3. Когда появляются ресурсы Аналитики, карточка переезжает на следующую доску
4. После того, как анализ закончен и реализован, при соблюдении всех критериев, карточка переезжает в Аналитика.Готово

АНАЛИТИКА. Критерии окончания работ:
• нарисованы диаграммы
• Swagger контракты опубликованы
• ревью пройдено
• компонент выложен в Jira
• статус в Jira “resolved”

5. При наличии ресурса разработки, карточка переезжает в раздел РАЗРАБОТКА
6. Когда разработка закончена, все критерии соблюдены, карточка переезжает в РАЗРАБОТКА.Готово

РАЗРАБОТКА. Критерии окончания работ:
• код написан и опубликован
• DevTest пройдены
• ревью кода пройдено
• статус в Jira “resolved”
• задача переведена на тестирование
• номера релизов определены

7. При наличии ресурса тестирования карточка переезжает в раздел ТЕСТИРОВАНИЕ
8. По окончании тестирования, при соблюдении всех критериев, карточка переезжает в ПСИ (приемо-сдаточные испытания)

ТЕСТИРОВАНИЕ. Критерии окончания работ:
• завершено модульное тестирование
• проведено интеграционное тестирование
• готов документ для передачи релиза
• нет критичных и блокирующих дефектов

9. Когда приемка готова, карточка переезжает во ВНЕДРЕНИЕ

Внедрение. Критерии окончания работ:
• получено заключение об успешном нагрузочном тестировании
• коннективности организованы
• закончена приемка на смежных системах

По согласованию с участниками и при наличии ресурсов, карточка может проезжать мимо некоторых столбцов/разделов (например, если не нужно тестирование, или если оно было проведено параллельно).