5 распространённых заблуждений о Скраме

Согласно 15-му ежегодному отчету State of Agile, опубликованному в июле 2021 года на digital.ai, за последний год объем внедрения гибких методологий значительно вырос. В командах разработки программного обеспечения использование Agile выросло с 37% в 2020 году до 86% в 2021 году. Такой стремительный рост может означать, что многие сотрудники, работающие в рамках гибкой методологии, не проходили формальных обучающих тренингов, что формирует идеальную среду для распространения некорректной информации. В статье приведем несколько примеров наиболее распространенных заблуждений о скраме.

Заблуждение 1. Во время планирования спринта разработчики берут на себя обязательство завершить выбранные элементы бэклога продукта в рамках спринта

Цель митинга по планированию спринта (Sprint Planning Meeting) — спланировать работу предстоящего спринта. Во время планирования скрам-команда выбирает цель спринта и элементы бэклога продукта (Product Backlog items, PBI) для включения в следующий спринт, а также создает план реализации поставки выбранных элементов бэклога. Целью спринта (Sprint Goal) является поставка готового

Руководство по скраму (The Scrum Guide) не определяет роли. Вместо этого оно описывает три зоны ответственности, которые являются частью скрам-фреймворка. Любой член команды может управлять этими зонами ответственности.

Три зоны ответственности это: владелец продукта (Product Owner), разработчики (Developers) и скрам-мастер (Scrum Master). Ответственность владельца продукта состоит в том, чтобы максимизировать ценность работы, которую производит команда, и ключевым инструментом в выполнении этой задачи становится владение бэклогом для команды. Ответственность разработчиков заключается в том, чтобы каждый спринт создавать готовый к использованию инкремент; они самоуправляемы и обладают всеми навыками, необходимыми для поставки инкремента в каждом спринте. Третья зона ответственности принадлежит скрам-мастеру, который стремится усовершенствовать применение скрама путем обучения команды теории и практике скрама.

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

Скрам — это гибкий фреймворк, а не свод рабочих инструкций. Как уже упоминали ранее, он опирается на разум тех, кто его использует. Команда вправе решить, что зону ответственности владельца продукта можно совместить с другой зоной ответственности (скрам-мастера или разработчика) в одном из участников команды.

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

Но для команд из девяти, например, участников, для одного человека управляться одновременно более чем с одной зоной ответственности будет сложно.

Заблуждение 3. Скорость — это часть скрама и лучший способ измерения производительности команды

Конечно, скорость (руководстве по скраму, и оно не является частью фреймворка. Если вам нужно измерить производительность команды, измеряйте ее на основе конечных результатов (Evidence-Based Management guide) или посетите EBM-курсы. Чтобы обсудить метрики команды в контексте обучения команд с целью повышения производительности, посетите тренинг Professional Agile Leadership от Rebel Scrum.

Заблуждение 4. Если над одним продуктом работают несколько скрам-команд, каждая команда должна быть фиче-командой

Я понимаю, почему люди так думают. Когда несколько скрам-команд работают вместе над одним продуктом, сложно продумать, как организовать эти команды. Я был свидетелем, как менеджеры неделями обсуждали эту тему. Многие считают, что единственный выход — разделить продукт логически на фичи, основываясь на логические области в коде и назначить одну или пару команд для реализации каждой фичи. Это не тот случай. Во-первых, когда команд меньше девяти, можно так организовать их работу, что любая из этих команд будет способна работать над любой частью системы. Такая организационная стратегия ведет к большей гибкости, позволяя команде фокусироваться на наиболее приоритетных задачах и обеспечивать более быструю поставку, чем это могут сделать Nexus. «Чем проще — тем лучше». Собственно, поэтому скрам так популярен; сложная работа требует упрощенных структур. Чтобы узнать больше о масштабировании команд с помощью скрам, ознакомьтесь с курсом Scaling Professional Scrum.

Заблуждение 5. Только владелец продукта должен прописывать критерии приемки, прописывать, разделять и приводить в состояние готовности элементы бэклога

В то время как владелец продукта несет ответственность за бэклог продукта, бэклог — это то, над чем работает вся команда. Уточнение бэклога — компромисс (Applying Professional Scrum.

Скрам-мастеров может заинтересовать курс Professional Scrum Master, а владельцев продукта — Professional Scrum Product Owner. Вопросы можете задать в форме здесь.

Материал подготовлен в рамках курса «Agile Project Manager».

Всех желающих приглашаем на бесплатное demo-занятие «Как уточнять статусы задач и подружиться с соседями».

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

Разберем:
— Почему менеджеру важно всегда знать, что вы делаете и в каком оно статусе;
— Как понятно коммуницировать, когда вы не знаете, сколько займет решение очередной проектной задачи, и чтобы вас не спрашивали об этом по десять раз;
— Как рассказывать о проектных проблемах, чтобы в вас не кидались помидорами;
— Как просить о помощи и эскалировать, чтобы работало с первого раза;
— Как выстраивать и чинить отношения с соседними командами, если вы инженер;
— Как менеджеру задавать вопрос «Когда будет готово?», чтобы не злить команду.

Доклад будет интересен инженерам, тимлидам и проектным менеджерам, потому что все мы занимаемся коммуникацией, а не только задачки закрываем.