является формальным требованием, недельные спринты представляются приемлемым минимумом.

Давайте посмотрим на команду с однодневными спринтами.

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

Есть даже бо́льшая опасность: команда просто сосредоточится на ежедневной работе и продвижении в ней и потеряет перспективу. У них не будет времени инспектировать и адаптировать весь процесс целиком, или исследовать пути улучшения качества, или привязаться к общим стратегическим целям и задачам. Каждый день они просто будут пытаться выпустить больше функционала.

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

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

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

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

3.7. КАК МАСШТАБИРОВАТЬ СКРАМ

Были описаны обязательные элементы скрама, правила игры и правила, которые тесно связывают эти элементы вместе. Они остаются неизменными и не зависят от масштаба.

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

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

Есть несколько тактик, которые позволяют играть в скрам в большем масштабе в зависимости от контекста.

3.7.1. Скрам одной команды

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

У команды разработки есть все необходимые компетенции, чтобы превратить за один спринт несколько элементов бэклога продукта в потенциально готовый к выпуску инкремент продукта, руководствуясь определением готовности. Команда разработки автономно управляет своей работой через бэклог спринта и проверяет направление движения и соответствие контексту организации с помощью ежедневного скрама. Владелец продукта вовремя предоставляет разъяснения по части функциональности и бизнеса. Скрам-мастер тренирует команду и организацию, служит и помогает им.

Одна команда – это скрам-команда, в которой есть владелец продукта, одна команда разработки и один скрам-мастер. Чтобы делать поставки функций продукта, которые от начала до конца предоставляют ценность конечному пользователю, команда разработки должна быть тем, что обычно называют фиче-команда.

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

3.7.2. Многокомандный скрам

Для больших продуктов или получения более быстрых результатов может возникнуть необходимость создавать и выпускать продукт при помощи нескольких скрам-команд.

Несколько скрам-команд создают один продукт. Они работают над одним бэклогом продукта. Общая система имеет одного владельца продукта, несколько команд разработки и одного или нескольких скрам-мастеров. Каждая команда разработки составляет бэклог спринта для своей работы, исходя из прогноза. Каждая команда разработки самоадаптируется с помощью ежедневного скрама и гарантирует интеграцию своей работы с результатами других команд разработки.

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

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

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

Помогающий оптимизировать целое скрам скрамов происходит до индивидуальных командных ежедневных скрамов. Наиболее подходящие представители команд разработки собираются вместе, чтобы обменяться информацией о ходе разработки, главным образом фокусируясь на состоянии интеграции продукта. Далее каждая команда разработки может оптимально перепланировать и подстроить свой бэклог спринта внутри мультикомандной экосистемы. В результате несколько команд оптимизируют совместное продвижение к интегрированному инкременту продукта, чтобы получить его не позднее конца каждого спринта. Технически зрелый инкремент может быть выпущен после оценки владельцем продукта, имеет ли этот инкремент необходимую степень полезности и не сдерживается ли его выпуск неизвестным объемом предстоящей разработки.

Несколько скрам-команд используют одни и те же критерии качества продукта, выраженные в определении готовности. Они, возможно, решат, что проще работать с одинаковой продолжительностью спринта, чтобы упростить планирование, интеграцию, выпуск и оценку работы. Будет предусмотрен дополнительный объем работ в индивидуальных бэклогах спринтов, чтобы работа была всегда интегрированной.

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