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

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

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

Во время спринта могут происходить непредвиденные ситуации. Они могут случаться в сложной работе в независимости от того, насколько хорошо действует команда. Например, разрабатывая новый программный продукт, команда может столкнуться с тем фактом, что некоторые фичи в реальности занимают больше времени, чем ожидалось. Если подобное случается, команда обсуждает это на ежедневном митинге (Daily Scrum Meeting) и приходит к решению. Также команда может обнаружить, что не сможет завершить к концу спринта все элементы бэклога, которые были определены на первом митинге по планированию. В этом случае обсуждение ситуации с владельцем продукта (Product Owner) того, какие элементы бэклога необходимы для достижения цели спринта, а какие можно в этот раз пропустить, помогут команде сфокусироваться на поставке. 

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

Должен быть баланс. Члены команды несут ответственность друг перед другом за выполнение первоначально согласованных элементов бэклога для спринта. Если команде регулярно не удается выполнить большую часть работы, запланированной на спринт, это должно быть вынесено на обсуждение на ретроспективе (Sprint Retrospective Meeting). Команды должны прийти к соглашению в отношении целевого процентного показателя выполнения для всех спринтов. Предсказуемость — важный аспект прогнозирования.

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

Заблуждение 2. В скраме один человек не может играть более одной «роли»

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

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

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

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

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

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

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

Конечно, скорость (Velocity) имеет значение, но это не мера производительности команды. Напротив, это дополнительный инструмент, который команда может использовать с целью планирования и прогнозирования своей работы. Понятие скорости даже не упомянуто в руководстве по скраму, и оно не является частью фреймворка. Если вам нужно измерить производительность команды, измеряйте ее на основе конечных результатов (outcomes) таких, как: прибыль, удовлетворенность клиентов, качество продукта, а не на основе второстепенных показателей (outputs) таких, как скорость или количество закрытых за спринт элементов бэклога.

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

Что такое скорость? Это дополнительная практика, используемая многими скрам-командами. С помощью нее можно выявить, какую часть бэклога команда превратила в инкремент продукта (Product increment) за спринт.

Часто понятие скорости используется в контексте меры, чтобы понимать, сколько стори поинтов (Story Points) команда закрывает за спринт.

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

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

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

Многие руководители ошибочно полагают, что скорость является лучшей мерой производительности команды и что хорошо работающие разработчики должны постоянно улучшать показатели скорости. Это не тот случай. Стабильная скорость может свидетельствовать о том, что разработчики хорошо работают и систематически превращают элементы бэклога в готовые инкременты. У разработчиков, со временем становящихся все более эффективными, может расти скорость, а может и не расти. Увеличение скорость может просто просто означать, что они переключились на новую систему поинтов. Точно так же нельзя сравнивать скорость одной команды со скоростью другой команды. Даже если они используют одинаковую систему поинтов, они могут применять разные поинты для элементов бэклога одинакового размера.

Понятно, что руководителям довольно сложно все это продумать. 

К счастью, есть более простой путь к измерению производительности команды. Создает ли ваша команда готовый инкремент каждый спринт? Живут ли они по ценностям скрам? Улучшаются ли показатели ценности продукта? Насколько команда оперативна? (Cycle Time, Lead Time) Это лишь некоторые из возможных вариантов измерения производительности команды. Основывайте свои измерения на том, что важно для продукта и помните, что каждая выбранная вами метрика — это только начало разговора. 

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

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

Я понимаю, почему люди так думают. Когда несколько скрам-команд работают вместе над одним продуктом, сложно продумать, как организовать эти команды. Я был свидетелем, как менеджеры неделями обсуждали эту тему. Многие считают, что единственный выход — разделить продукт логически на фичи, основываясь на логические области в коде и назначить одну или пару команд для реализации каждой фичи. Это не тот случай. Во-первых, когда команд меньше девяти, можно так организовать их работу, что любая из этих команд будет способна работать над любой частью системы. Такая организационная стратегия ведет к большей гибкости, позволяя команде фокусироваться на наиболее приоритетных задачах и обеспечивать более быструю поставку, чем это могут сделать фиче-команды. Во-вторых, лучше дать возможность командам самим определить удобный способ самоорганизации. Поделитесь с ними рекомендациями (например, до десяти человек в команде, включая владельца продукта; каждая команда должна обладать всеми необходимыми навыками для поставки готовых инкрементов к концу спринтов), предоставьте им обзор цели продукта (Product Goal) и предстоящей работы, и позвольте им самим решать, как лучше всего организовать ее выполнение.  

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

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

В то время как владелец продукта несет ответственность за бэклог продукта, бэклог — это то, над чем работает вся команда. Уточнение бэклога — компромисс (Product Backlog Refinement). Владелец продукта в первую очередь фокусируется на том, что он хотел бы добавить к продукту и почему. Разработчики концентрируются на взаимодействии с владельцем продукта, чтобы усовершенствовать ценную работу и определить объемы работы, чтобы они смогли поставлять ценный инкремент продукта каждый спринт. Закончив процесс уточнений, команда должна определить размер наиболее актуальных элементов бэклога так, чтобы они смогли выполнить их в рамках одного спринта, убрать как можно больше зависимостей и упорядочить работу, чтобы максимизировать ценность продукта.

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

Заключение

Если вы столкнулись с одним из этих заблуждений в своей работе, рассмотрите возможность отправить свою команду на обучение на практическом курсе Applying Professional Scrum.

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

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

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

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

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

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