Наша Канбан трансформация идет полным ходом. Как и почему она началась я отразила в здесь. После проведения презентации для продуктовой команды, на котором мы рассказали о нашем концепте изменения процесса, у команды возникло много вопросов. Кроме того, вопросы возникли и у меня, стали видны некоторые проблемы и пробелы, о которых раньше и не задумывались.
Вопросы команды
1. Что делать с регрессом? При работе по Scrum у нас была разработана стратегия регрессионного тестирования результатов итерации. При переходе на Канбан текущую стратегию требуется доработать/изменить/сделать более гибким и динамическим. Решить будет ли он зафиксирован в MTM или будет проходить в рамках сессии исследовательского тестирования. Какой % кейсов следует дополнительно автоматизировать и т.д. Необходимо учесть, что у нас уйти в продакшен может как один исправленный баг, так и набор ЮС с новым/измененным функционалом.
Как мы применяем эвристику RCRCRC.
2. Обязательно ли все ЮС должны включать все этапы, представленные на канбан-доске? Нет, могут быть исследовательские задачи, или задачи требующие только аналитики или тестирования. Все такие вопросы будут разрешены при точном определении классов обслуживания (classes of service).
3. Что делать с большими ЮС, связанными с существенным изменением функционала? Здесь было предложено 2 решения. Первый: создаем такую ЮС и работаем с ней как с любой другой типовой задачей с соблюдением ограничений WIP. Второй: для таких ЮС создаем свой отдельный swimlane со своими ограничениями. В настоящее время решили остановиться на первом варианте.
4. Останутся ли у нас митинги? Все мероприятия, проводимые в рамках Scrum мы решили оставить: это грумминги, планирование, стендапы, ретро и демо. Только ограничить время их проведения и проводить все кроме стендапов по мере необходимости, стендапы оставляем ежедневные.
5. Что делать с багами, найденными в результате тестирования ЮС? Это оказался самый спорный и дискуссионный вопрос. Благодаря советам, полученным от @Docatisto , Алексея Пименова и Романа Петрова было принято следующее решение:
1. ЮС остается в графе Тестирование и помечается как заблокированная.
2. По результатам тестирования создается баг-репорт.
3. Его содержание обсуждается с командой и PO (product owner).
4. Заводится тикет на разработчика с описанием дефекта, тикет заводится в рамках текущей ЮС.
ВАЖНО: PO обязан следить за бэклогом: приоритезовать все новые таски, ЮС, баги, появляющиеся на доске.
Вопросы и Проблемы PO
- Непрозрачность процесса в разрезе сроков. Действительно, сейчас очень сложно сказать, сколько времени потребуется команде на реализацию определенной ЮС. Однако у нас есть наш опыт работы по Scrum, из TFS мы может получить всю необходимую статистику. Однако, состав команды изменился и у нас были четкие временные рамки спринта. Сейчас в процессе работы, мы сможем оценить нашу скорость выполнения работ более корректно.
- Каким образом будет вестись работа с большими ЮС, требующие длительного времени разработки и имеющие определенную дедлайн. Для ЮС с дедлайном определен свой класс обслуживания. Работа с ними будет вестись как было разобрано выше.
- Насколько предварительная оценка трудозатрат, размера ЮС будет соотвествовать действительности. Сейчас сложно ответить на этот вопрос, но в течении работы наши прогнозы будут более достоверны.
Итоги
На самом деле вопросов очень много и они возникают лавинообразно. Не факт, что принятые решения окажутся верными, но сейчас они кажутся нам максимально возможными с учетом имеющийся у нас опыта и знаний. Канбан- это путь постоянного улучшения и мы на этом пути.
MindMap
О нашей Канбан трансформации in English.