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

Что мы имеем сейчас

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

1. Медленное реагирование на изменения. Брендинг изменился ЕЩЕ вчера, а у нас ТОЛЬКО середина спринта..
2. Длительное время доставки ценности.
3. Зачастую процесс создания продукта не прозрачен для всех участников.
4. В спринт берется больше задач,  чем команда может выполнить. Это может быть связано как с их неверной первоначальной оценкой, так и с требованиями бизнеса. Получаем «героические» итерации с большим числом переработок, сокращенным регрессионным тестированием. В итоге — это классические потери по Lean, пренебрежение качеством и мы не можем адекватно прогнозировать процесс.

А что мы хотим

Текущее состояние дел перестает устраивать не только бизнес, но и команду в целом. Что мы хотим:

1. Быстрое реагирование на изменения: более частые релизы, для удовлетворения нужд клиентов. Гибкий актуальный бэклог, соответствующий требованиям клиентов.
2. Постоянное улучшение процесса и продукта. Уменьшение всех типов потерь и, как следствие, сокращение издержек. MindMap о потерях.
3. Фокусировка на клиентах: высококачественный продукт в срок.
4. Повышение продуктивности и эффективности команды. Возможность максимальной реализации себя каждым из членов команды. Сбалансированная работа команды. Фокусировка на CI/CD.

Нам поможет Kanban

В качестве руководства к действию мы выбрали следующее Дэвида Андерсона и Энди Кармайкла опубликованного на edu.leankanban.com и переведенного на русский силами Scrum-сообщества России. В основе Kanban лежат 3 основных принципа: визуализация, ограничение WIP (кол-во незавершенной работы) и управление потоком. В данном руководстве они расширены до 6 основных практик:

1. Визуализируй
2. Ограничивай количество незавершенной работы
3. Управляй потоком
4. Делай правила работы явными
5. Внедряй циклы обратной связи
6. Улучшайтесь совместно, эволюционируйте на основе экспериментов

Наши первые шаги по внедрению Kanban

Как я уже писала в статье первый шаг на пути улучшения- это стандартизация имеющегося процесса согласно SDCA. Следующий шаг- это уже его улучшение согласно методологии PDCA. Для внедрения Kanban существует также системный подход STATIK.  Суммируя оба этих подхода, давайте рассмотрим что нами было сделано (DO (PDCA) и этапы 5-8 по STATIC)

Разрабатываем Kanban-доску

• Было решено ограничиться только онлайн доской, в качестве инструмента был выбран TFS, так как он в настоящее время используется командой.
• Формализуем поэтапно наш реальный процесс доставки ценности клиенту. Полученные этапы- это столбцы нашей доски.
• Выбираем единицу работ, которая будет являться элементами доски. В нашем случае это Пользовательские истории (US), работа по UC ведется в рамках тасков и баги.

Ограничиваем WIP (одновременно выполняющаяся работа)

Необходимо ограничить максимальное кол-во задач, которые могут находиться в каждой стадии.
В настоящее время это ограничение нами не сформулировано. Один из вариантов был-
ограничение по кол-ву участников каждой стадии. Будем экспериментировать!

Управляем потоком. Делаем правила явными

1. В Kanban каждая стадия может рассматриваться как сервис. Наша задача минимизировать кол-во багов, возникающих при переходе от стадии к стадии. Для этого формулируются Формальные политики для каждой стадии. Они нам помогут участникам понять: а действительно стадия завершена и задача может переходить к следующей. Кроме того в такие политики мы закладываем наличие обратной связи: согласование приемочных критериев, согласование стратегии тестирования, код ревью.
2. Определяем типы задач и политики работы с ними. В общем случае в Kanban задачи берутся в работу по принципу FIFO. Кроме того у на могут быть срочные и важные задачи, которые берутся в работу несмотря на ограничение WIP (например блокирующие релизные баги); задачи с фиксированной датой и т.д.
3. Определяем, будем ли мы предварительно оценивать трудозатраты по элементу доски и необходимо ли это?
4. Определяем все ли задачи мы будем отражать на доске или, например, только те, которые по времени занимают больше 15/30 минут.
5. Определяем правила реагирования на заблокированные задачи. Такие признаки обязательно должны быть визуализированы на доске. Они помогут нам определить бутылочные горлышки по процессу и продукту.
6. Корректируем процесс каждой из стадий. Например для тестирования было принято решение для каждой UC создавать 2 задачи при необходимости: для тест-дизайна и непосредственно выполнения тестирования. Кроме того, чтобы тестирование не стало бутылочным горлышком необходимо изменить стратегию регрессионного тестирования. В данном случае тот тест-план, который был разработан при работе по Scrum теряет свою актуальность, так как мы стремимся в сокращению времени производства.

Социализируем (этап 8 STATIK)

Провели собрание команды, на котором был представлен наш концепт, наше видение процесса, т.е. kanban-cистема и kanban-доска. Мы получили обратную связь, обсудили вопросы , наметили шаги по дальнейшей эволюции. Начали использовать!

В качестве итогов хотелось бы сказать, что мы только встали на этот путь, будем экспериментировать, находить баланс, становиться лучше!

Мы это: я и наш скрам-мастер- Сергей Котович и вся наша продуктовая команда.