7

Scrum против изменений в ходе итерации

Предположим, что наша Scrum-доска выглядит так:

Что делать, если появляется некто, кто хочет добавить Е на нашу доску?

Scrum-команда, как правило, говорит что-то вроде "Нет, извините, мы обещали выполнить только A + B + C + D в этом спринте. Но вы легко можете добавить E в Product Bac klog. Если же Product Owner решит, что у этой задачи высокий приоритет, мы возьмем ее в следующий спринт". Спринт правильной длины дает команде возможность сфокусироваться и хоть что-то завершить, и в то же время позволяет Product Owner-у изменять и регулярно обновлять приоритеты.

А что сказала бы Kanban-команда?

Kanban может сказать "Да, пожалуйста, добавляйте Е в колонку "В планах". Но в этой колонке может быть не больше двух элементов, так что в этом случае вам придется убрать C или D. Сейчас мы работаем над А и В, но как только у нас появится возможность, мы возьмем верхний элемент из колонки "В планах".

Таким образом, время реакции (время, которое необходимо, чтобы отреагировать на изменение приоритетов) Kanban-команды – это время до того момента, когда освободится место в соответствующей колонке, согласно принципу "один элемент ушел – один пришел" (ограничение незавершенного производства).

В Scrum-е время реакции в среднем составляет половину длины спринта.

В Scrum-е Product Owner не может трогать Scrum-доску, так как команда взяла на себя обязательства по конкретному набору элементов на итерацию. В Kanban-е вы должны установить собственные правила для тех, кому разрешено изменять то, что на доске. Как правило, Product Owner-у дается крайняя левая колонка вроде "В планах" или "Готово к работе (Ready)", или "Backlog", или "Предложение (Proposed)", где он может вносить какие угодно изменения.

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

8

Scrum-доска очищается каждую итерацию

Scrum-доска на разных этапах спринта, как правило, выглядит примерно так.

Когда спринт закончился, доска очищается – все элементы убираются. Стартует новый спринт, и после планирования спринта у нас появляется новая Scrum-доска с новыми элементами в левом столбце. Технически это потери (мусор), но для опытных Scrum-команд обычно не требуется слишком много времени, и процесс обновления доски может дать прекрасное ощущение завершенности от закрытия запланированных задач. Это как мыть посуду после обеда – делать это неприятно, зато чувствуешь себя потом прекрасно.

В Kanban-е доска, как правило, штука постоянная – вам не нужно ее обновлять, чтобы начать все сначала.