вторник, 14 января 2014 г.

Как перейти на Kanban из Scrum или Scrumban-а? Часть 1


Что лучше Scrum или Kanban? Не думаю что есть ответ, они для разных целей.
Нужен ли вам Kanban? Так же зависит от ваших целей.

Мое мнение - они фокусируются на разном.
В Scrum больше фокуса на реализации scope спринта. То есть важно уметь нарезать правильно истории и задачи, правильно их оценивать, реагировать на проблемы с ними, и все это заканчивается результатом - Успех или неуспех в реализации scope Спринта беклога. Не успех - давайте нарезать по-другому, давайте оценивать лучше, давайте обсуждать лучше.
В Kanban (я надеюсь) больше фокус на саму поставку историй, на скорость поставки, на их ценности. Именно поэтому я решился на изменение.

Scrum имеет сильное преимущество перед Kanban - он более строгий и формальный. Он дисциплинирует команду, PO, Заказчика. Вы не можете обеспечить стабильный scope Спринта на 2 недели? Заказчик все время требует перекрасить кнопку в красный и именно сегодня? Это не в Scrum процессе проблемы - это у вас проблемы. Вы оцениваете в часах, а потом требуется от разработчиков чтобы оценки исполнялись с высокой точностью? Вы не можете зафиксировать объем одной истории и при реализации она сильно пухнет? Вам нужно через все это пройти и научится. Потому я уверен что успешный опыт Scrum процесса нужен это эволюции команды и других участников проекта.

Почему мы перешли на Kanban?

В процессе работы мы перешли от чистого Scrum в сторону Scrumban, и последующий переход на Kanban был довольно логичен.

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

Далее как я писал ранее про теорию ограничений возникло желание увеличить скорость выпуска путем увеличения усилий по аналитике, то есть к моменту Планирования по истории должны быть готовы все необходимые артефакты по историям - OK от Заказчика, готовые/согласованные SpecByExamples, скетчи/прототипы интерфейсов. Это увеличило длительность и сложность процесса аналитики и сделало его более формальным. В результате у нас появляются Draft Спринта (задачи, которые должны быть готовы к Планированию и которые мы вероятнее всего возьмем в Спринт) и Pre-Draft Спринта (задачи, которые мы грумим, если есть время). То есть 2 предварительных спринта по 2 недели. Мы делаем аналитику на месяц вперед.

Для Draft и Pre-Draft спринтов я создал отдельные аналитические Kanban доски, где описаны какие стадии и в какой порядке должны пройти истории в процесс аналитики. Чтобы формализовать процесс и сделать его визуализацию. То есть там есть столбцы на OK от бизнеса, на предварительное обсуждение с РО для формирование общего vision, на разработку скетчей, прототипов и спек.

Kanban board, Agile Jira
Настройка SQL выборки для доски 

Kanban board, Agile Jira
Настройка столбцов и статусов

У нас Scrum и 3 Kanban доски для работы. Это можно назвать Scrumban.

Продолжение следует.

Комментариев нет:

Отправить комментарий