…Скрам-команда обслуживает многих стейкхолдеров, и все они борются за внимание команды. Команда получает запросы и требования от стейкхолдеров, от каждого клиента, от отделов продаж и маркетинга. Кроме того, в ходе работы появляются баги и это тоже требует внимания. Частота и важность этих запросов меняется. Иногда их объем и срочность просто чрезмерны.
✥ ✥ ✥
Смена приоритетов или проблемы с эксплуатацией часто прерывают работу Скрам-команды в ходе Спринта. Требования отделов продаж и маркетинга, вмешательство стейкхолдеров могут послужить причиной хронических сбоев в работе, многократных провалов Спринтов, несоблюдения сроков релизов и даже провала компании.
Скрам-команда — общий ресурс, который закрывает потребности многих стейкхолдеров. Трагедия общин — это дилемма, возникающая, когда множество людей, действуя независимо и рационально, руководствуясь своими личными интересами, в конечном итоге истощают общий ресурс, даже если очевидно, что такой результат не отвечает чьим-либо долгосрочным интересам. Впервые описал эту дилемму американский эколог и философ Гаррет Хардин в знаменитой статье «Трагедия общин» («The Tragedy of the Commons»), опубликованной в журнале Science в 1968 году.
Часто неудачные решения Владельца Продукта ведет к тому, что к Скрам-команде начинают обращаться с конфликтующими запросами. Некоторым командам приходится даже работать над фичами, которых нет в Бэклоге Продукта.
Желательно, чтобы Скрам-команда отвечала за результаты своей работы (“eat your own dog food”). Если выявляется дефект, команде нужно его исправить как можно быстрее. Если создается специальная команда для исправления дефектов, Скрам-командане будет обращать внимание на скрытые дефекты.
Это, а также другие причины постоянно мешают работе Скрам-команды.
Поэтому:
Определите, сколько вас можно отрывать от основной работы, и не берите на себя больше, чем можно выполнить за это ограниченное время. Если объем буфера превышается, отмените Спринт.
Установите три простых правила, которые помогут наладить самоорганизацию и избежать прерываний работы.
Эта стратегия поможет команде корректировать план в ходе Спринта и повысить шансы на поставку готового Инкремента Продукта.
- Команда создает буфер для внеплановых элементов на основе эмпирического опыта. Например, предположим, что в среднем треть объема работ приходится на внеплановую работу, неожиданно поступающую в команду в ходе Спринта. Если средняя производительность команды составляет 60 поинтов, команда оставляет 20 поинтов как буфер времени на прерывания и вмешательства.
- Приоритет всех нетривиальных запросов должен устанавливать Владелец Продукта. (Грамматические ошибки на веб-страницах и ошибки компиляции — это примеры тривиальных ошибок, когда исправление настолько очевидно, что нет необходимости в дополнительной информации. Разработчики также могут потратить небольшое количество времени на исправление нетривиальных дефектов, прежде чем передать информацию о них Владельцу Продукта.) Владелец Продукта установит для некоторых элементов низкий приоритет, если они не несут ощутимой ценности. Другие элементы Владелец Продукта может перенести на следующий Спринт, даже если они несут непосредственную ценность. Если критичные элементы должны быть завершены в ходе текущего Спринта, то Владелец Продукта помещает их в буфер.
- Если буфер переполняется, то есть Владелец Продукта ставит в Спринт 21 поинт вместо запланированных 20, то Скрам-командаавтоматически прекращает Спринт и планирует его заново, а Владелец Продукта уведомляет стейкхолдеров, что сроки сдвигаются.
Важно договориться со стейкхолдерами об этих правилах и соблюдать их. Владелец Продукта должен всегда быть доступным для команды и стейкхолдеров. Во время отсутствия Владельца Продукта Скрам-команда может иметь собственного временного Владельца Продукта.
Владелец Продукта корректирует размер буфера, чтобы сбалансировать краткосрочное удовлетворение клиентов и будущую генерацию прибыли. Часто у Владельца Продукта есть сторонние метрики для расчета удовлетворенности клиентов, которые он может использовать для корректировки размера буфера.
Эта стратегия не связана с устранением дефектов, которые возникают в ходе Спринта из элементов бэклога (см. Рациональное ведение деятельности). Она также не связана с PBI, выполнение которых предусмотрено в ходе Спринта Владельцем Продукта во время Планирования Спринта, чтобы уменьшить технический долг. Низкая толерантность к дефектам в целом увеличивает производительность, но переполнение буфера обычно приводит к снижению производительности как минимум на 50 процентов. Чтобы сбалансировать силы, Владелец Продукта должен руководствоваться здравым смыслом. См. Whack the Mole.
✥ ✥ ✥
Эти правила повышают самоорганизацию и позволит избегать срывов Спринта.
Кроме того, люди будут стараться не заполнять буфер времени полностью, чтобы команда могла закончить работу досрочно и/или работать над устранением препятствий. Это важно, потому что Команды, которые заканчивают работу раньше, разгоняются быстрее. Более того, если команда использует Вчерашнюю погодудля определения размера буфера и буфер практически никогда не наполняется до предела, его размер будет постепенно уменьшаться, и проблема прерываний уходит.
Как ни странно, критичные проблемы от этого не становятся скрытыми или неразрешенными, так как Владелец Продуктаразмещает любой критичный элемент в Бэклоге Продукта. Это помогает команде увеличить производительность и повысить результативность последующих Спринтов. Обычно благодаря этому появляется больше времени на разрешение критичных вопросов и высвобождаются ресурсы.
Команда демонстрирует высокую степень Гордости за продукт, чтобы приостановить работу ради качества продукта и сохранении репутации. Связанные паттерны: Владелец Продукта, Бэклог Продукта, Команды, которые заканчивают работу раньше, разгоняются быстрее, Поток работы направлен внутрь и Пространство для завершения.
