Скрам: Правила игры. Карманное руководство

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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