Руководство по скрам 2020 на русском

Автор статей о программировании. Изучает Python, разбирает сложные термины и объясняет их на пальцах новичкам. Если что-то непонятно — возможно, вы ещё не прочли его следующую публикацию.

В документе описан порядок проектной работы в команде: как поставить цель и спланировать работу над продуктом, выстраивать отношения между разработчиками, контролировать прогресс и так далее. Правилa Scrum периодически обновляются — их рекомендуют всем скрам-командам. Сейчас вышла пятая версия — мы рассмотрим её основные положения.

Справка о Scrum ↓

Справка о Scrum

Представьте жилой дом. Стены, крыша, фундамент — это каркас, на котором всё держится. Без каркаса не получится сделать ремонт и жить в квартире.

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

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

Подробный обзор нового руководства

• Scrum Guide 2020 на русском и английском языке.
• Презентация Кена Швабера и Джеффа Сазерленда — авторы гайда проводят двухчасовой стрим и рассказывают про новое руководство.
• Статьи и комментарии к новому руководству сообщества scrum.org.

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

Было: Scrum 2017

Владелец продукта встречается с заказчиком и соглашается за два месяца выпустить сайт вместе с мобильными приложениями под iOS и Android.

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

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

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

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

Стало: Scrum 2020

Владелец продукта встречается с заказчиком и получает предложение: за два месяца нужно выпустить сайт и приложения под iOS и Android.

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

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

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

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

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

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

Было: Scrum 2017

Есть задача: за шесть месяцев выпустить сайт с приложениями под iOS и Android. Шесть месяцев — крайний срок, после которого заказчик запускает рекламу и планирует продавать свои услуги через мобильные приложения.

Команда делит задачу на шесть спринтов и выбирает такой порядок:

1-й спринт: разработка сайта.

2-й спринт: тестирование сайта.

3-й спринт: разработка iOS-приложения.

4-й спринт: тестирование iOS-приложения.

5-й спринт: разработка Android-приложения.

6-й спринт: тестирование Android-приложения.

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

В новом руководстве на первом месте стоит вопрос: «Почему или в чём ценность спринта?» Каждый спринт должен соответствовать цели продукта:

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

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

Стало: Scrum 2020

Задача: за шесть месяцев выпустить сайт с приложениями под iOS и Android. Шесть месяцев — крайний срок, после которого заказчик запускает рекламу и планирует продавать свои услуги через мобильные приложения.

Определяем цели, которых можно достичь в рамках одного спринта:

1-й спринт: разработка сайта.

2-й спринт: тестирование сайта.

3-й спринт: разработка iOS-приложения.

4-й спринт: тестирование iOS-приложения.

5-й спринт: разработка Android-приложения.

6-й спринт: разработка Android-приложения.

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

Учитываем цель продукта, расставляем приоритеты и получаем такой план:

1-й спринт: разработка iOS-приложения.

2-й спринт: тестирование iOS-приложения.

3-й спринт: разработка Android-приложения.

4-й спринт: тестирование Android-приложения.

5-й спринт: разработка и тестирование сайта.

6-й спринт: резервное время на доработку мобильных приложений.

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

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

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

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

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

Было: Scrum 2017

Что предлагало руководство: команда должна ежедневно собираться на 15-минутную встречу, чтобы синхронизироваться и обсудить цели спринта.

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

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

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

Чтобы успеть провести совещание, один из участников по кругу задавал остальным одинаковые вопросы и получал краткие механические ответы:

— Что сделано: задача 15 и 20.

— Что запланировано: задача 25 и 30.

— Какие проблемы: никаких, или проблема находится в процессе решения.

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

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

Стало: Scrum 2020

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

Результат: команда концентрируется на решении проблем и использует совещания для ускорения разработки.

Скрам-команда может как угодно организовать работу над продуктом и отслеживать прогресс. Главное — чтобы принятые правила никто не нарушал.

Мы попросили практиков прокомментировать Scrum Guide 2020 и объяснить, какие изменения им понравились, что ухудшилось и могут ли IT-команды использовать обновлённый Scrum без помощи сертифицированного скрам-мастера.

Начнём с того, стоит ли нанимать скрам-мастера для внедрения нового Руководства. Ответ зависит от того, как команда работает сейчас:

• Если в команде классический Waterfall, люди по 30 лет работают в проекте и никто не хочет ничего менять, то самостоятельно перейти на гибкие методики работы с проектами вряд ли получится. В этом случае важно своевременно пригласить скрам-мастера, способного изменить систему.
• Если речь идёт о только что сформировавшемся коллективе, который готов пробовать и экспериментировать, то скрам-мастера может заменить тимлид или кто-то из руководителей.

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

Самое сложное — наладить Scrum-процесс с нуля. Если команда готовится к большим изменениям, я бы советовала нанимать скрам-мастера. В начале должен быть человек, который понимает Scrum и точно знает, что и для чего делать. Он сможет аргументировано донести и объяснить идеи Scrum каждому участнику команды.

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

Виктория Писаренко

Scrum Master / Agile Project Manager, Мюнхен; работает в проектах автоиндустрии, основатель Victoria’s Business Secrets Academy.

Scrum родился из практики: наблюдений, проб и опыта команд. Здорово, что Руководство обновляется. И хотя эти изменения кажутся небольшими, за счёт них можно лучше понимать и применять фреймворк.

Наверняка многие обратили внимание, что в новом Руководстве появилась Цель Продукта и что из Ежедневного Скрама убрали три вопроса, слепое следование которым превратило многие команды в зомби.

Я бы хотела выделить три неочевидных изменения:

• Scrum официально вышел за пределы разработки софта: в Руководстве убрали специфическую терминологию. Здорово, что больше команд могут увидеть для себя возможности в том, чтобы попробовать Scrum.
• Скрам-мастер теперь не лидер-слуга. Этот термин в русском переводе звучит странно в связи с тонкими различиями между «служить» и «обслуживать». Теперь скрам-мастер — «настоящий лидер, который служит скрам-команде и всей организации».
• Также скрам-мастер больше не фасилитирует События Скрама, а «убеждается в том, что они происходят, позитивны, продуктивны и не выходят за рамки ограничений по времени». Это очень важное изменение, которое корректирует неправильную трактовку ответственности скрам-мастера как «ведущего» встреч».

В целом новое Руководство побуждает команды и лидеров свериться с первоисточником и спросить себя: насколько в нас жив дух игры?

Юлия Аникеева

Скрам-мастер, Scrumband. Работала с «Альфа-банк», «АльфаСтрахование», «Ростелеком», «Крок»

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

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

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

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

Вот неполный список обязанностей скрам-мастера:

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

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

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

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

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

Научитесь: Профессия TeamLead
Узнать больше

Время на прочтение
8 мин

Количество просмотров 102K

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

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

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

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

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

• определение элементов бэклога продукта;
• правильное расположение элементов для оптимизации достижения цели;
• обеспечение понятности и прозрачности Product Backlog;
• обеспечение прозрачности и понятности требований, над которыми предстоит работать всей Scrum Team;
• общая оптимизация для достижения наибольшей ценности работы Development Team;
• ответственность за понимание бэклога командой разработки.

Scrum Team (скрам тим) – собирательный образ команды, состоящей из Development Team, Scrum Master и Product Owner. Команда полностью самодостаточна и не зависит от внешних специалистов или заказчиков.

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

1. Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
2. Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач. Тогда можно изменить «важность» всех задач с этой тематикой;
3. Задачи лучше разбивать по одинаковым типам.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

1. Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
2. Формулировка User Story:
   Будучи пользователем <…> я хочу сделать <…>, чтобы получить <…>.
   Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение;
   Формулировка без ЧТОБЫ (так лучше).
   Как <пользователь>, я <что-то хочу получить>, <с такой-то целью>.
   Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ.
3. Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
4. Написание истории с точки зрения этих актеров с указанием уникальных названий;
5. В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
6. Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
7. Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
8. Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
9. User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.

Уточнение и оценка Product Backlog

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

1. Первая часть митинга могут участвовать все.
   Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;
   Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения.
2. Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
   Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;

Scrum Poker (Planning Poker).

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

1. Scrum Master ведет собрание;
2. Product Owner представляет краткие обзоры каждой задачи;
3. Происходит обсуждение, задаются вопросы;
4. Участники Developer Team выбирают по одной карте, потом переворачивают;
5. Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
6. Затем голосуют вновь и присваивают задаче Story Points.

Daily Scrum Meeting

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

1. Проводится в одно и то же время;
2. Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
3. Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?

Sprint Review Meeting

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Меньше конкретики и практичности

Объем Руководства сократился до 17 страниц вместо 26. Авторы указывают на то, что стиль Руководства стал менее предписывающий, оставляющий больше свободы для интерпретаций. Скрам многие критиковали за чрезмерную жесткость правил. Вероятно, авторы учли это в редакции 2020г.

С моей точки зрения, Руководство стало менее практичным и более абстрактным. Теперь и без того сложная для понимания роль скрам-мастера стала еще более размытой. А основные события Скрама лишились подробной повестки. Теперь новичкам еще труднее понять, что должно происходить на Обзоре спринта или Ежедневном Скраме. Понято, что три «стандартных» вопроса Ежедневного Скрама иногда задавались уж слишком механически, но для старта это вполне нормально. Надо же с чего-то начать! Вот пример, как изменилась прикладная часть Обзора спринта.

Скрам-команда стала единым целым

Теперь команда разработки не выделяется как «команда» внутри скрам-команды, а есть просто роль «Разработчики» (Developers) со своей зоной ответственности.

Это изменение однозначно в лучшую сторону, т.к. Владелец продукта на практике все равно был немного в стороне от команды разработки. Для него команда Разработки была своего рода инструментом. А сейчас это единая команда, которая идет к цели продукта как одно целое.

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

Цель продукта, которой так не хватало

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

Я на тренингах и консультациях перед первичным наполнением бэклога прорабатываю с клиентами видение и стратегию продукта по шаблону Романа Пихлера

Сейчаc все встало на свои места. Теперь есть цель продукта, которая фокусируют всю скрам-команду на длительной дистанции, в то время как цель спринта фокусируют скрам-команду на спринт. Стало логичнее.

Фокусировка стала еще лучше

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

1. есть бэклог продукта, который сфокусирован на достижении цели продукта
2. есть бэклог спринта, который сфокусирован на достижении цели спринта. Шаблон Романа Пихлера удобно отображает и цель спринта и содержание бэклога спринта.
3. есть инкремент, разработка которого сфокусирована на выполнении критериев готовности

Самоуправление, а не самоорганизация

Заменили самоорганизацию на самоуправление. Кто не знаком с определениями Щедровицкого понятий «руководство», «организация», «управление», такое уточнение ничего не меняет. Стилистически уточнение верное, но по сути, мало, что меняет.

Суть в том, что скрам-команда — автономная боевая единица. Сама ставит цели, сама решает, как их достигать.

Это основное, что изменилось. Рекомендую в любом случае прочитать самостоятельно и составить собственное мнение об изменениях.

Скачать Руководство по Scrum 2020