Одним из сложнейших для выполнения является принцип Scrum не беспокоить команду во время спринта. Он часто не соблюдается в организациях, которые только-только внедрили Scrum. Принцип нарушается – и команда не достигает цели спринта.
Kanban предлагает смягчить этот принцип и рассматривать срочные задачи как поток изменений на уровне задач.
Если появляется срочная задача, команда добавляет ее в таблицу задач, при этом их количество также ограничено.
Любое нарушение этого принципа ставит под сомнение цель спринта. Всякий раз, когда команда переключается на выполнение срочной задачи, стоит поднять вопрос о корректировке цели спринта. Если срочная задача потребовала у команды значительного количества времени, скорее всего, имеет смысл ее пересмотреть. Однако изменение цели спринта имеет последствия для заинтересованных сторон, о чем тоже нельзя забывать.
Рисунок 20.2 – Горячая линия для срочных задач
Ограничение помогает снизить риск постоянных корректировок. Однако применить этот принцип на практике непросто: человеку, пришедшему к команде со срочной задачей, будет сложно принять ответ не сейчас. Возможно, за этим последуют изменения в культуре.
Ограничивается количество срочных задач вообще или только тех, что в процессе выполнения? Или и то, и другое?
Команда, которая пробует эту технику, должна сама прийти к ответу, а также договориться о числе, при котором достигается предел. Пределы устанавливаются эмпирическим путем. Разумно браться за срочные задачи по очереди.
Команде нужно решить, как действовать в случае возникновения срочной задачи: взяться за ее выполнение немедленно, после завершения задачи или после завершения истории. Желательно все же не отвлекать разработчика от его работы.
Можно попробовать визуализировать срочные задачи с введенным ограничением. Это поможет команде меньше отвлекаться во время спринта. Команде, которую часто отвлекают, эту практику следует применять с осторожностью. Ее следует использовать только на временной основе.
Рисунок 20.3 – Срочные задачи в таблице
Напомню, для каждого спринта можно создавать резервные пустые истории и наполнять их возникающими срочными задачами.
20.3 Ограничение историй
Для понимания паттерна ограничение незавершенной работы следует сперва прочитать главу 9 «Планирование спринта».
• Быстрая реакция на изменения
Команды, которые овладели принципами и ценностями Scrum и соблюдают ритм спринта, иногда разочаровываются, что не могут быстро внедрить срочные изменения.
Мы знаем, что во время планирования спринта, в самом конце, истории переходят в колонку в процессе.
Команда Peetic в среднем завершает 10 историй за спринт, при этом одновременно работает над тремя – не больше. В начале спринта 7 историй ждут своей очереди.
Они готовы и ожидают своего момента, уступая место более срочным, которые могли быть обнаружены командой уже после начала спринта.
Таким образом, команда может быстрее реагировать на изменения во время спринта и уменьшить давление со стороны на этапе планирования.
• Явное ограничение
Паттерн ограничение незавершенной работы состоит во введении явного ограничения на количество историй в процессе. В классическом Scrum ограничение исходит из продолжительности спринта.
На схеме мы видим ситуацию, когда команда добавила две истории во время спринта.
Процесс планирования спринта выглядит следующим образом: собрание заканчивается, когда достигается предел, и команда пополняет список, когда истории заканчиваются.
Рисунок 20.4 – Ограничение незавершенных задач
Этот паттерн дополняет роение. Ограничение соответствует количеству одновременно находящихся в процессе историй.
Следуя принципу приверженности и вовлечения, команда не ставит под сомнение концепцию цели спринта. Это означает, что первые истории среди тех, что не вошли в спринт, также будут реализованы.
Во время спринта можно провести дополнительные сессии планирования, если по результатам схватки было решено пополнить список историй.
Рисунок 20.5 – Повтор событий спринта
• Преимущества
Основное преимущество заключается в том, что команда лучше реагирует на изменения.
Ограничение незавершенных историй укрепляет Agility и помогает команде адаптироваться к изменениям.
Индикаторы спринта, как, например, burndown-график, становятся ненужными.
Упрощается создание доски спринта. Для историй и задач в процессе необходимо меньше места, и их количество стабильно от спринта к спринту (введенное ограничение меняется нечасто).
Можно ввести ограничение по типу историй, чтобы каждому из них присвоить определенную производительность.
Команда Peetic установила ограничение в три истории. Это значит, что в бэклоге всего три позиции для историй в текущем спринте, одна из которых отведена для технической работы.
• Риски
Этот паттерн требует быть осторожным в отношении следующих пунктов:
✓ Поэтапное планирование затрудняет определение цели спринта и ее достижение.
✓ Добавление историй во время спринта требует хорошего понимания критериев готовности.
✓ Простота процесса может сподвигнуть Владельца продукта запросить еще больше изменений во время спринта.
Для лучшего понимания паттерна ограничение с самого начала необходимо сначала ознакомиться с главами 6 и 7.
Далее можно расширить принцип, внеся ограничение размера частей бэклога (истории в доработке, готовые истории).
Паттерн лотков состоит в визуализации рабочего процесса, что совпадает с первым принципом Kanban. Ограничение лотков позволит еще сильнее сократить список задач.
Поскольку песочница предназначена для общего сбора запросов и идей, не рекомендуется ее ограничивать – в ином случае это станет препятствием.
• Ограничение в стартовом лотке
Верхний предел позволяет ограничить количество готовых историй.
Нижний предел для готовых историй позволяет перейти к сессии доработки для дальнейшего пополнения списка.
При достижении верхнего предела команда начинает обсуждение. Достижение нижнего предела столбца означает, что пора добавить новые элементы, чтобы избежать их нехватки в дальнейшей работе.
Рисунок 20.6 – Ограничение в стартовом лотке
• Ограничение в лотке доработки
Паттерн ледяного лотка уже сам по себе является способом ограничения размера лотка доработки. Если он используется командой, то нет нужды, чтобы как-либо еще ограничивать размер лотка доработки – кроме тех случаев, когда это возможность не допустить преждевременного разделения epic-истории на части.
Ограничение имеет смысл, если лоток доработки еще не ограничен рамками сезона.
На моей практике были ситуации, когда команды накапливали истории сотнями и в течение длительного времени.
Внесение ограничения приводит к уменьшению размера бэклога. В нормальных условиях число историй, на котором надо вводить ограничение, вдвое больше количества готовых историй.
20.4 Ограничение функциональностей
Ограничивать истории хорошо, ограничивать функциональности еще лучше. Верно ли это утверждение? Давайте проверим.
Функциональности помещаются в kanban-таблицу, столбцы которой представляют рабочий процесс.
Внесение ограничения в столбце приводит к уменьшению списка незавершенных функциональностей. Давление, вызванное ограничением, побуждает к обсуждению того, что важнее для команды: начать или закончить?
В том случае – если функциональность вводится в эксплуатацию конечными пользователями сразу после ее завершения – ограничения помогут сгладить процесс, тем самым сократив так называемое время цикла.
Kanban-доска функциональностей, особенно если она является инструментом сразу для нескольких команд, считается эквивалентом kanban-портфеля и упрощает планирование на среднесрочную перспективу.
Рисунок 20.7 – Ограничение функциональностей
Приносить ценность с помощью функций – хорошо, еще лучше – убедиться, что есть реальное воздействие на участников.
Организации, использующие технику impact mapping для стратегического планирования, в некотором роде применяют Kanban, исследуя только одно воздействие за раз (плюс обратная связь).
Обсуждение ограничений желательно вести согласно такой иерархии: воздействие, функциональность, затем история и, наконец, задача.
20.5 Метрики и индикаторы
Kanban предлагает новые метрики.
Время такта – это время, необходимое для прохождения элементом всей цепочки, от формулировки запроса до его использования. В нашем контексте это имеет смысл только для функциональностей.
Его легко измерить, достаточно в нужный момент добавить к функциональности дату.
Но с другой стороны, создание индикатора, использующего время такта – как, например, контрольный график – мне не кажется целесообразным, учитывая небольшое количество функциональностей.
Время цикла – это время, за которое элемент проходит через весь рабочий процесс или его часть, и время, на которое команда может положиться после того, как измерения покажут стабильность.