Разработчики и самоуправление в Скраме

Руководство по Скраму 2020 года определяет Разработчиков как людей, приверженных созданию любого аспекта пригодного к использованию Инкремента в каждом Спринте. Часто люди неправильно понимают, что для них означает «самоуправление». Речь идет не о том, чтобы делать все, что им заблагорассудится, а о том, чтобы определить наилучший способ достижения Цели Спринта. Это различие имеет решающее значение для понимания того, как работают эффективные Скрам-команды.

Что означает самоуправление

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

Подотчетности, а не роли

Руководство по Скраму исключило концепцию «команды разработки» как подкоманды. Теперь «Разработчики» являются одной из трех подотчетностей в рамках единой Скрам-команды. Это изменение подчеркивает коллективную ответственность. В структуре Скрам-команды нет индивидуальных должностей, таких как «тестировщик» или «архитектор». Каждый, кто несет подотчетность Разработчика, работает над достижением Цели Спринта. Это способствует общей ответственности за Инкремент и поощряет кросс-функциональное сотрудничество.

Ежедневный Скрам и самоорганизация

Ежедневный Скрам является основным событием для Разработчиков, чтобы проверять прогресс в достижении Цели Спринта и при необходимости адаптировать Бэклог Спринта. Это их встреча. Они определяют структуру и методы, если это сосредоточено на прогрессе в достижении Цели Спринта. Это событие является ярким примером их самоуправления в действии. Они никому не отчитываются, а координируют свои действия друг с другом.

Во время Ежедневного Скрама Разработчики могут задавать себе такие вопросы, как:

• Какую работу нам нужно выполнить сегодня, чтобы достичь Цели Спринта?
• Кто лучше всего подходит для выполнения какого элемента Бэклога Продукта или задачи?
• Есть ли какие-либо препятствия, мешающие нам двигаться вперед?
• Нужно ли нам скорректировать наш план на оставшуюся часть Спринта?

Разрешение препятствий

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

Влияние на производительность

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

Start with the Foundations module →

Or take the full Scrum Master track →

Обязанности самоуправляющихся Разработчиков

Самый частый вопрос по этой теме — какие именно обязанности у самоуправляющихся Разработчиков. Scrum Guide 2020 отвечает кратко, поэтому вот развернутый ответ. Самоуправляющиеся Разработчики отвечают за создание плана Спринта (Sprint Backlog), за ежедневную адаптацию этого плана, за качество через соблюдение Definition of Done, за профессиональную ответственность друг перед другом и за внутренние решения о том, кто что делает, когда и как.

Обрати внимание, чего в списке нет. Разработчики не решают, что строить (это Product Owner), и не следят за процессом (это Scrum-мастер). Самоуправление — это ограниченная автономия, а не полная свобода.

Распространенные заблуждения о самоуправлении

• Самоуправление не означает отсутствие менеджера. Линейные менеджеры остаются для найма, развития и компенсации. Они просто не раздают ежедневные задачи внутри Спринта.
• Самоуправление не означает консенсус. Команда может и должна принимать быстрые решения. Голосование по каждому тикету убивает поток.
• Самоуправление не означает хаос. Рабочие соглашения, сильное Definition of Done и четкая Sprint Goal делают автономию безопасной.
• Самоуправление не означает, что Скрам-мастер бездельничает. Он коучит команду к самоуправлению и защищает ее от внешнего вмешательства.

Как выстроить самоуправление в новой команде

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

• Начинай каждый Спринт с четкой Sprint Goal. Автономия без цели — это просто импровизация.
• Запишите рабочие соглашения команды и пересматривайте их на каждой ретроспективе.
• Запретите тикеты с одним исполнителем в первый месяц; заставьте парную работу, чтобы знания распространялись.
• Позволь команде вести Daily Scrum без Скрам-мастера в комнате, когда доверие сложилось.
• Считай, сколько решений команда приняла в этом Спринте без эскалации. Это и есть настоящая метрика самоуправления.

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