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

В этой статье мы собираемся рассмотреть все новое в Scrum Guide 2020.

Руководство по Scrum - введение

Хотя Scrum зародился в 90-х, первая версия Scrum Guide появилась только в 2010 году. С годами он становился все более популярным, особенно среди ИТ-специалистов. Он продолжает адаптироваться к постоянно меняющейся реальности и потребностям людей. В 2020 году была выпущена 5-я версия Scrum Guide. Что изменилось с тех пор? 

1. Цель продукта

В Scrum Guide 2020 представлена совершенно новая концепция. До сих пор команда Scrum могла определить только одну цель - цель спринта .

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

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

Цель продукта - это долгосрочная цель команды Scrum. Они должны выполнить (или отказаться от нее) одну цель, прежде чем приступить к следующей.

2. Три вопроса планирования спринта: почему, что и как?

Внедрение Product Goal со всеми вытекающими из этого последствиями - большой намек в мир бизнес-анализа. Правда в том, что бизнес-аналитики годами пытались убедить Владельца продукта  и других членов команды Scrum ответить на вопрос, почему . До сих пор спринты больше касались What , а разработчики занимались стороной How . С « Why» процесс Scrum и планирование спринта будут совсем другими.

 Вопрос « Почему» является важной частью, потому что он помогает понять выгоду, которую может получить пользователь. Сосредоточтесь на том, для кого это нужно, что нужно делать и чего с его помощью можно достичь.

Вопросы « Почему» также помогают разработчикам понять ценность той или иной задачи, функции или пользы для бизнеса . Они помогают выполнить один из 7 принципов гибкого бизнес-анализа, то есть видеть целое . 

Еще один важный аспект вопросов « Почему» заключается в том, что он заставляет  выполнить анализ, чтобы определить, какой процесс является ценным, прежде чем элемент можно будет добавить в бэклог продукта. Он защищает бэклог продукта от того, чтобы он стал списком задач, которые никогда не будут выполнены. Опять же, это ответ на потребности бизнес-анализа. Это подход, упомянутый IIBA в Agile Business Analysis среди других. Не будет преувеличением сказать, что с новой версией Scrum Guide связь и понимание между Scrum и бизнесом будут лучше, чем когда-либо.

Что изменилось?

1. Руководство по Scrum уменьшено

Если вы знакомы с предыдущей версией Scrum Guide, вы сразу заметите, насколько меньше Scrum стал с новой версией. Теперь у нас всего 13 страниц вместо 19 - сокращение более чем на 30%. Это почему? В первую очередь были исключены некоторые повторяющиеся и сложные инструкции, а также вопросы в Daily Scrum . Раздел об отмене спринта в новом руководстве по Scrum также стал намного короче. Раньше ему был посвящен целый подраздел - теперь это буквально два предложения.

Спринт может быть отменен, если цель спринта устареет. Только Владелец продукта имеет право отменить Спринт.

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

2. Никаких вопросов во время ежедневного скрама.

Большое изменение. Метод трех вопросов  не всегда давал хорошие результаты. Часто гораздо эффективнее использовать ежедневный скрам, чтобы просмотреть все задачи в Sprint Backlog и обсудить их прогресс. Так легче понять, насколько близко (или далеко) команда от цели спринта. Никакая строгая форма нового Ежедневного Скрама не поощряет экспериментирование, чтобы приспособить Ежедневный Скрам к вашим потребностям.

Тем не менее, Руководство по Scrum подчеркивает, что вы должны постоянно следить за прогрессом в достижении цели Sprint , а не только во время ежедневного Scrum. Особенно, когда есть явные сигналы опасности. Если их заметит член группы, их следует немедленно передать. 

3. Акцент на определении "сделано"

Как мы уже упоминали, определение Готового теперь является обязательством Инкремента. Это означает, что Определение «Готово» служит способом обеспечения достаточного качества предоставляемого Инкремента . Определение «сделано» в новом руководстве по Scrum помогает каждому понять, что именно было сделано. Важно, чтобы все элементы бэклога спринта соответствовали определению готовности. Из этого правила нет исключений. Вот пара примеров:

1. Проверка кода завершена;
2. Функционал реализован и протестирован;
3. Подготовлены тестовые сценарии работоспособности;
4. Задача находится в столбце DONE;
5. Код развернут и доступен в промежуточной среде.

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

4. Акцент на цели спринта

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

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

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

5. Новые правила именования для команды.

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

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

6. Ответственность команды

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

Как мы уже отмечали, у Scrum Team теперь три роли. У каждого из них есть четкие правила ответственности. В соответствии с ними, Разработчики несут ответственность за:

1. Создание плана на Спринт, Бэклог Спринта; 
2. Повышение качества, следуя определению «сделано»; 
3. Приспосабливание ежедневного плана к цели спринта.

 Владельцы продукта несут ответственность за максимизацию ценности продукта в результате работы команды Scrum и за эффективное управление элементами бэклога продукта, что включает в себя :

1. Разработка и явное доведение до сведения цели продукта; 
2. Создание и четкое сообщение элементов бэклога продукта; 
3. Заказ элементов бэклога продукта;
4. Обеспечение прозрачности, видимости и понимания бэклога продукта

И последнее, но не менее важное: Скрам-мастер отвечает за создание Скрама, как это определено в Руководстве по Скрам, и за эффективность Скрам-команды .

7. Скрам-мастер важнее, чем когда-либо

В новом руководстве по Scrum четко сказано, что без Scrum Master не может быть Scrum .

Скрам требует, чтобы Скрам-мастер создавал среду.

Это не означает, что компании должны нанимать преданных мастеров Scrum . Вместо этого следует выбрать заинтересованное лицо, которое будет выполнять роль и брать на себя обязанности, возложенные на Scrum Master . 

В одном из заключительных абзацев Scrum Guide рассказывается, как именно реализовать все эти правила:

Структура Scrum, описанная здесь, неизменна.  Скрам существует только целиком и хорошо функционирует как контейнер для других техник, методологий и практик.

Руководство по Scrum 2020 - резюме

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

Применение вопроса « Почему» к каждому элементу и деятельности в проекте Scrum - еще одно хорошее изменение. Акцент на цели продукта переносит ответственность команды Scrum с процесса создания самого продукта на добавление его ценности. Это определенно улучшает отношения между командой Scrum и бизнесом и заставляет каждого члена команды Scrum лучше осознавать общую цель.

Подводя итоги, стоит сказать, что Scrum Guide 2020 настоятельно подразумевает, что Scrum по-прежнему (и, вероятно, всегда будет) основан на постоянном улучшении всех процессов: Scrum основан на эмпиризме и бережливом мышлении. Эмпиризм утверждает, что знание приходит из опыта и принятия решений, основанных на наблюдаемом. Бережливое мышление сокращает потери и сосредотачивается на главном . Мы можем ожидать, что в будущем Scrum Guide продолжит меняться, чтобы стать еще более гибким и сфокусированным на еще более полной привязке продукта к его бизнес-ценности. Мы также можем ожидать, что правила и значения Scrum будут становиться все более и более упрощенными и общими одновременно. Определение Scrum развивается, и Руководство по Scrum является хорошим индикатором того, куда он будет идти дальше.