Все о SCRUM. Изучение, разработка, интеграция

Все, что здесь представлено, остается в Scrum-фреймворке, сохраняется структура и, в частности, спринты. Мы несколько изменили процесс планирования спринта, чтобы сделать его более гибким: в работу запускаются только начатые истории (см. главу 9).

Kanban-практика, которую мы накладываем на этот процесс, ограничивает работу. Давайте посмотрим, какие паттерны нам в этом помогут на уровне задач, историй и функциональностей.

20.2 Ограничение незавершенной работы

20.2.1 Ограничение количества незавершенных задач

Начнем с введения верхнего предела для самого маленького элемента: задач.

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

Очень часто в среднем столбце находится огромное количество элементов – те задачи, которые на данный момент в процессе выполнения. Их даже больше, чем людей в команде. Иногда на одного человека приходится по 5–6 задач, а то и больше! Конечно, некоторые задачи могут быть заблокированы препятствиями, надо сперва их устранить, чтобы вернуться к выполнению. Но зачастую в процессе находится непростительно много задач.

Ограничение текущих задач способствует обсуждению внутри команды и улучшает ситуацию. Это отправная точка для дальнейшего продвижения.

20.2.2 Визуализация и ограничение срочных задач

Одним из сложнейших для выполнения является принцип Scrum не беспокоить команду во время спринта. Он часто не соблюдается в организациях, которые только-только внедрили Scrum. Принцип нарушается – и команда не достигает цели спринта.

Kanban предлагает смягчить этот принцип и рассматривать срочные задачи как поток изменений на уровне задач.

Если появляется срочная задача, команда добавляет ее в таблицу задач, при этом их количество также ограничено.

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

Рисунок 20.2 – Горячая линия для срочных задач

Ограничение помогает снизить риск постоянных корректировок. Однако применить этот принцип на практике непросто: человеку, пришедшему к команде со срочной задачей, будет сложно принять ответ не сейчас. Возможно, за этим последуют изменения в культуре.

Ограничивается количество срочных задач вообще или только тех, что в процессе выполнения? Или и то, и другое?

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

Команде нужно решить, как действовать в случае возникновения срочной задачи: взяться за ее выполнение немедленно, после завершения задачи или после завершения истории. Желательно все же не отвлекать разработчика от его работы.

Можно попробовать визуализировать срочные задачи с введенным ограничением. Это поможет команде меньше отвлекаться во время спринта. Команде, которую часто отвлекают, эту практику следует применять с осторожностью. Ее следует использовать только на временной основе.

Рисунок 20.3 – Срочные задачи в таблице

Напомню, для каждого спринта можно создавать резервные пустые истории и наполнять их возникающими срочными задачами.

20.3 Ограничение историй

20.3.1 Ограничения для спринта

Для понимания паттерна ограничение незавершенной работы следует сперва прочитать главу 9 «Планирование спринта».

• Быстрая реакция на изменения

Команды, которые овладели принципами и ценностями Scrum и соблюдают ритм спринта, иногда разочаровываются, что не могут быстро внедрить срочные изменения.

Мы знаем, что во время планирования спринта, в самом конце, истории переходят в колонку в процессе.

Команда Peetic в среднем завершает 10 историй за спринт, при этом одновременно работает над тремя – не больше. В начале спринта 7 историй ждут своей очереди.