В этой короткой статье я перечисляю основные изменения в новой версии Руководство по Скраму 2020. Если у вас нет времени, чтобы тщательно изучить руководство, эта статья для вас. Руководство доступно с 18 ноября в английской и русской версиях.
Цель изменений
Авторы Скрама утверждают, что главный мотив изменений — сделать Скрам менее предписывающим, более бережливым (lean) и более гармонично вписывающимся в разные контексты, особенно за пределами разработки программного обеспечения (ПО). И, знаете, Руководство значительно похудело. Теперь оно насчитывает лишь 13 страниц.
Перечень основных изменений
- Одна Скрам-команда, сфокусированная на одном продукте. Концепция отдельной команды внутри команды (Development Team), которая привела к поведению взаимоотношений «прокси» и «мы/они» между Product Owner и командой разработчиков, устранена. Теперь есть только Скрам-команда, сфокусированная на общей цели, с тремя разными зонами ответственности: Product Owner, Scrum Master и Developers. То-есть, теперь мы говорим не о ролях, а зонах ответственности (accountabilities) внутри одной системы. Как следствие, Скрам-команда коллаборативно отвечает за достижение Цели Спринта, за соблюдение определения готовности (Definition of Done) и т.д.
- Добавление Product Goal. Добавлена концепция Product Goal, которая фокусирует Скрам-команду на достижение более широкой цели. Каждый Спринт должен приближать продукт к итоговой Product Goal. Чем может быть эта Product Goal? В зависимости от контекста, это может быть миссия, видение продукта или же тактическая квартальная цель. Руководство специально использует нейтральный термин, чтобы дать вам возможность наилучшим образом определиться в вашем контексте.
- Место для Sprint Goal, определения готовности (DoD) и Product Goal. Предыдущие Руководства по Скраму описывали Sprint Goal и определение готовности (DoD), но они не были официальными артефактами и относились к правилам Скрама. Теперь каждый из трех артефактов содержит «приверженность». Для Product Backlog есть Product Goal, для Sprint Backlog есть Sprint Goal, для Increment есть определение готовности (DoD) (теперь без кавычек). Они существуют, чтобы обеспечить прозрачность и сфокусировать на прогрессе по каждому артефакту.
- Самоуправление вместо самоорганизации. В предыдущей версии команды назывались самоорганизующимися. Команда сама решала, кто и как будет выполнять работу. Версия 2020 года фокусируется на Скрам-команде, и подчеркивает важность самоуправления. Благодаря тому, что представитель бизнеса (Владелец Продукта) является частью системы, Скрам-команда может определять не только кто и как организовывает работу, но и направление движения.
- Три вопроса события Sprint Planning. В версии 2017 были описаны два вопроса Sprint Planning: «Что» и «Как». В Руководстве по Scrum 2020 года особое внимание уделяется третьему вопросу — «Почему» — относящемуся к Sprint Goal.
- Исчезли вопросы из Ежедневного Скрама. Описание Ежедневного Скрама значительно сократилось. Ушли рекомендуемые вопросы: кто, что делал и т.д. Теперь разработчики сами решают как наилучшим образом инспектировать прогресс к Цели Спринта.
- Один Владелец Продукта/Бэклог Продукта в независимости от количества команд. Если раньше и могли бы различные трактовки того, как правильно масштабироваться и сколько может быть Владельцев Продуктов и Бэклогов Продуктов, то теперь спор завершен. Руководство 2020 года явным образом говорит о том, что в случае, когда много Скрам-команда разрабатывают один продукт, то у них один и тот же Владелец Продукта/Бэклог Продукта.
- Скрам основан на lean. В предыдущих руководствах утверждалось, что Скрам основан на принципах эмпиризма. Теперь к ним добавлены принципы бережливого мышления (lean). Лично я очень рад этому, потому что всегда утверждал, что Скрам основан на идеях Toyota Production System (TPS).
- Отсутствуют обязательные атрибуты у элементов Бэклога Продукта (PBI). Версия 2017 требовала от нас четыре атрибута у каждого PBI: description, order, estimation, value. Теперь они могут отличаться в зависимости от уникального контекста, в котором разрабатывается продукт.
- Исчезло ограничение в 10% на Product Backlog Refinement (PBR). Уточнение Бэклога продукта остается ongoing activity и упоминается несколько раз в тексте, но ограничение по времени отсутствует, потому что может отличаться в различных контекстах.
- Исчезли кавычки с “Ready”. Элементы Бэклога Продукта (PBI) называются готовыми к выбору в Спринт, если они могут выполнены за Спринт. При этом слово ready осталось, но кавычки растворились.
Надеюсь, эта статья была полезной для вас. Все же, рекомендую ознакомиться лично с Руководством по Скраму 2020 лично. Удачного вам использования Скрама в ближайшие годы!
#статьи
- 18 мар 2021
-
18
Похоже, обновлённый гайд сделал Scrum доступнее, и не только для программистов. Выясняем, что поменялось и не маркетинговый ли это ход.
Автор статей о программировании. Изучает 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
Узнать больше
59 part series
This page provides a series of articles, blogs, videos and more that pertain to the 2020 version of the Scrum Guide released on November 18, 2020.
The Scrum Guide
Scrum is defined completely in the Scrum Guide by Ken Schwaber and Jeff Sutherland and is maintained independently of any company. The Scrum Guide is translated and available in over 30 languages.
The 2020 Scrum Guide Launch Event Recording
Ken Schwaber and Jeff Sutherland are joined by Dave West, JJ Sutherland, Don McGreal and Avi Schneier as they discuss the release of the updated Scrum Guide and celebrate 25 years of Scrum.
Scrum Guide 2020 Update — Scrum is Still Scrum
At Scrum.org we have used this update of the Scrum Guide as an opportunity to have some interesting discussions and our CEO Dave West has documented some of them for your review and attention.
Update to the Scrum Guide — What it means to Scrum.org
Today, the 18th of November 2020 Ken Schwaber and Jeff Sutherland released an update to the Scrum Guide. If you are interested in an overview of what has changed, read about the seven main changes described with some context.
Scrum Guide 2020 Update — What has been removed
Scrum is described as a framework, not a methodology. The Scrum Guide provides just enough prescription to allow Scrum to work and encourages its ‘users’ to be smart, adding practices and other things specific to them on top of the framework as needed to form their process.
Scrum Guide 2020 Update — Introducing the Product Goal
With the 2020 update to the Scrum Guide, three commitments were added to the artifacts. The idea of a commitment is to provide additional quality to the artifact to improve transparency. In the case of Product Backlog, the commitment is to the Product Goal.
Scrum Guide 2020 Update — Commitments
With the 2020 release of the Scrum Guide, Commitments were added for each artifact. The commitments provide a nice, structural way to describe some of the key characteristics of each artifact. The intent of this change was to provide clarity and make the Scrum Guide simpler to read and use.
Product Goal
One of the more challenging aspects of Product Management is to create a tangible relationship between the work we do today and the business strategy. Product Goals are an often overlooked mechanism that can help you in this area.
Scrum Guide 2020 — Product Goal
The Product Goal is now the commitment of the Product Backlog. This video with Professional Scrum Trainer Ralph Jocham explains the Product Goal. (2:26 Minutes)
Product Goal is a Commitment
There have been a few changes in Scrum Guide 2020, and I am really excited. These changes focus on ‘Values’ within the framework of Scrum…
Why, What, How — Sprint Planning
In the 2020 update of the Scrum Guide, the Sprint Planning section has had a very welcome update. Every part of Scrum has a purpose, a reason to why it’s included in the framework, and this update made the purpose — raison d’etre — of the Sprint Planning clearer. Let’s see how!
Scrum Guide 2020 — Sprint Planning
The Sprint Planning has been enriched with a third topic — Why. This video with Professional Scrum Trainer Ralph Jocham explains the change to the Sprint Planning event in Scrum. (2:24 Minutes)
A Home for Product Goal, Definition of Done, and Sprint Goal
In the 2020 Version of the Scrum Guide, the commitments were introduced for each artifact. These then became an element of Scrum; in that they need to be used to gain the maximum value that the Scrum Framework offers. They were always part of a Professional Scrum approach, now there is a clear connection of these commitments to the artifacts. They increase transparency, and the focussed delivery of Value. Each of the commitments now clearly support and sustain an artifact.
2020 Scrum Guide: Definition of Done Created By Scrum Team
In the 2020 Scrum Guide, the Definition of Done is created by the Scrum Team. In previous versions of the Scrum Guide, this responsibility was explicitly owned by the Development Team. I will explain the intention of the change and what it means for Scrum Teams.
Scrum Guide 2020 Update — Role to Accountabilities
With the 2020 release of the Scrum Guide, the term role was replaced with accountabilities. The purpose of this change was to place special emphasis that this is not a job description, but the bare minimum set of accountabilities necessary to execute Scrum. The blog describes how these accountabilities are split into 3 groups.
Accountabilities in Scrum: It’s A Complete Picture Now
What is up awesome people? I hope you had an awesome holiday break. As you may have noticed, there have been several changes introduced in Scrum Guide 2020. Scrum no longer emphasizes roles but instead accountabilities…
Scrum Guide 2020 — Accountabilities
The Scrum Guide 2020 defines Accountabilities within one team, Scrum Team. This video with Professional Scrum Trainer Ralph Jocham explains the Accountabilities. (3:21 Minutes)
Scrum Guide 2020: True Leadership is an Attitude
The readers going through this piece more or less know the definition of a Scrum Master. Co-Creators Ken & Jeff, in their Scrum Guide 2020, having introduced exclusively the framework for Scrum, have put it as: “Scrum Masters are true leaders who serve the Scrum Team and the larger organisation.” The article’s objective is introducing the shift in the mindset or attitude. This is a requisite to become a genuine leader, as far as my experience goes.
[VLOG] What’s New in Scrum Guide 2020?
If you prefer watching a video to understand the updates in Scrum Guide 2020, which are also my favourite updates, enjoy watching this video I’ve made.
The Scrum Guide 2020 Reordered
The Scrum Guide Reordered 2020 is based on about 95 percent of the text of the Scrum Guide 2020, extending its original structure by adding additional categories, for example, on self-management, commitments, or accountability.
What has NOT changed in the game of Scrum?
The 2020 version of Scrum Guide was released recently and everyone is talking about the changes been made in it and how it is going to impact their current ways of working as compared to its previous version.
The Agile Wire — Scrum Guide Updates
In this episode of the Agile Wire podcast — Professional Scrum Trainers Jeff Bubolz, Jeff Maleski and Chad Beier discuss the Scrum Guide 2020 changes.
Scrum.org 2020 Update by the Scrum Facilitators
In this podcast Scrum Facilitators from the Netherlands Sjoerd Kranendonk and Jasper Alblas discuss the new Scrum Guide (version 2020) with Scrum Coaches Steve Trapps and Andy Hiles from the UK.
Mis comentarios iniciales sobre la Scrum Guide 2020
Hoy ha salido la nueva Scrum Guide 2020.
Aún estoy digiriendo los cambios que he ido viendo mientras reviso la nueva guía scrum.
Estoy analizando y no descarto todas las grandes o pequeñas consideraciones.
Was ist neu im Scrum Guide 2020 Update? (7 Dinge, die Du unbedingt wissen solltest)
Heute, am 18. November 2020, pünktlich zum 25. Geburtstag von Scrum, haben Ken Schwaber und Jeff Sutherland den Scrum Guide aktualisiert.
Um eines gleich vorwegzunehmen: Scrum bleibt Scrum. Ein einfaches Rahmenwerk, welches es Teams ermöglicht, mit der Arbeit an komplexen Problemen zu beginnen. Und der Scrum Guide 2020 ändert daran nichts.
Einige Dinge sind jedoch neu und denen widmen wir uns jetzt.
Scrum Guide 2020 : Ce qui change
Pour le 25ème anniversaire de Scrum, ses co-créateurs, Jeff Sutherland et Ken Schwaber nous livrent le millésime 2020 du Guide Scrum.
Меньше конкретики и практичности
Объем Руководства сократился до 17 страниц вместо 26. Авторы указывают на то, что стиль Руководства стал менее предписывающий, оставляющий больше свободы для интерпретаций. Скрам многие критиковали за чрезмерную жесткость правил. Вероятно, авторы учли это в редакции 2020г.
С моей точки зрения, Руководство стало менее практичным и более абстрактным. Теперь и без того сложная для понимания роль скрам-мастера стала еще более размытой. А основные события Скрама лишились подробной повестки. Теперь новичкам еще труднее понять, что должно происходить на Обзоре спринта или Ежедневном Скраме. Понято, что три «стандартных» вопроса Ежедневного Скрама иногда задавались уж слишком механически, но для старта это вполне нормально. Надо же с чего-то начать! Вот пример, как изменилась прикладная часть Обзора спринта.
Было
- в число участников встречи входят Скрам-команда и ключевые заинтересованные лица, которых приглашает Владелец Продукта;
- Владелец продукта объясняет, какие Элементы Бэклога готовы, а какие нет;
- Команда Разработки рассказывает о том, что получилось во время Спринта, какие возникли проблемы и как они были решены;
- Команда Разработки демонстрирует готовую работу и отвечает на вопросы об Инкременте;
- Владелец Продукта описывает текущее состояние Бэклога Продукта. При необходимости он прогнозирует возможные даты завершения разработки Продукта, основываясь на текущих показателях прогресса;
- все присутствующие обсуждают, над чем стоит работать дальше. Таким образом Обзор Спринта предоставляет ценные данные для следующего Планирования Спринта;
- проводится обзор, как изменения рынка или потенциальное использование продукта могли изменить то, что нужно сделать в первую очередь;
- выполняется обзор сроков, бюджета, возможностей и позиций на рынке для будущих релизов или возможностей продукта.
Стало
Во время события Scrum Team и заинтересованные лица анализируют, что было достигнуто в ходе Sprint, и что изменилось в их окружении. На основе этой информации участники совместно решают, что делать дальше. Product Backlog также может быть скорректирован с учетом новых возможностей. Sprint Review — это рабочая сессия, и не сводится к презентации.
Скрам-команда стала единым целым
Теперь команда разработки не выделяется как «команда» внутри скрам-команды, а есть просто роль «Разработчики» (Developers) со своей зоной ответственности.
Это изменение однозначно в лучшую сторону, т.к. Владелец продукта на практике все равно был немного в стороне от команды разработки. Для него команда Разработки была своего рода инструментом. А сейчас это единая команда, которая идет к цели продукта как одно целое.
И зоны ответственности, про которые слушатели часто спрашивают на тренингах, стали еще лучше обозначены. Хотя, как я уже выше отметил, конкретики в действиях внутри своей зоны ответственности стало меньше.
Цель продукта, которой так не хватало
В прежней редакции 2017 Скрам начинался с имеющегося бэклога продукта. Но откуда он брался, из каких соображений выполнялось его первичное наполнение, оставалось за кадром. Приходилось на тренинге рассказывать про дизайн-мышление, развитие потребителей (customer development) и другие практики продуктовых изысканий, из которых рождается видение продукта, его стратегическое позиционирование. И только потом появляется первичный бэклог.
Я на тренингах и консультациях перед первичным наполнением бэклога прорабатываю с клиентами видение и стратегию продукта по шаблону Романа Пихлера
Сейчаc все встало на свои места. Теперь есть цель продукта, которая фокусируют всю скрам-команду на длительной дистанции, в то время как цель спринта фокусируют скрам-команду на спринт. Стало логичнее.
Фокусировка стала еще лучше
Продолжая тему фокусировки, стоит отметить, что теперь выстроилась законченная логика в отношении трех артефактов Скрама:
- есть бэклог продукта, который сфокусирован на достижении цели продукта
- есть бэклог спринта, который сфокусирован на достижении цели спринта. Шаблон Романа Пихлера удобно отображает и цель спринта и содержание бэклога спринта.
- есть инкремент, разработка которого сфокусирована на выполнении критериев готовности
Самоуправление, а не самоорганизация
Заменили самоорганизацию на самоуправление. Кто не знаком с определениями Щедровицкого понятий «руководство», «организация», «управление», такое уточнение ничего не меняет. Стилистически уточнение верное, но по сути, мало, что меняет.
Суть в том, что скрам-команда — автономная боевая единица. Сама ставит цели, сама решает, как их достигать.
Это основное, что изменилось. Рекомендую в любом случае прочитать самостоятельно и составить собственное мнение об изменениях.
Скачать Руководство по Scrum 2020
Время на прочтение
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, требования и пожелания.
- Основные поля в карточке: id, название, важность, оценка, релиз, описание, автор, исполнитель;
- Дополнительные поля в карточке. Например, поле «Тематика» – рейтинг товара в интернет-магазине сейчас не нужен, а в рейтинг входят пара задач. Тогда можно изменить «важность» всех задач с этой тематикой;
- Задачи лучше разбивать по одинаковым типам.
Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.
123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.
User Story
- Получение от заказчика Бизнес-цели. Составляем Impact Map для каждой бизнес-цели: Why?->Who?->How?->What? (Зачем?->Кто?->Как?->Что надо сделать?);
- Формулировка User Story:
Будучи пользователем <…> я хочу сделать <…>, чтобы получить <…>.
Как менеджер склада я получаю отчет о товарных остатках, чтобы БЫСТРЕЕ принять решение;
Формулировка без ЧТОБЫ (так лучше).
Как <пользователь>, я <что-то хочу получить>, <с такой-то целью>.
Как менеджер склада я получаю отчет о товарных остатках БЫСТРЕЕ. - Разделение «актеров» на группы: целевая, важная, менее важная и т.д. Присвоение уникальных названий актерам в этих группах, даже если есть одинаковые роли «Пользователи системы»;
- Написание истории с точки зрения этих актеров с указанием уникальных названий;
- В результате можно увидеть, какие истории необходимы для актеров целевой группы, важной группы итд. Следовательно можно выстроить приоритет;
- Действие. Важно описывать историю на уровне «Что?» делает, а не «Как?», описать проблему, а не ее решение. «Как?» находится вместе с командой;
- Ценность. Отказ от формулировки «Чтобы». Для каких-то историй можно указать ценность истории в формате «Чтобы», но не для большинства;
- Переход с понятия «ценность» (value) на понятие «влияние» (impact). История не обязательно должна иметь ценность, но обязательно должна оказывать влияние на того актера, который указан в истории. Это влияние в конечном итоге ведет к цели;
- User Story разбиваются по важности и функциональности и далее разбиваются на задачи в бэклоге.
Уточнение и оценка Product Backlog
Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?
Формируется Sprint. Sprint Planning Meeting. Scrum Poker
Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.
- Первая часть митинга могут участвовать все.
Право голоса у Product Owner и Developer Team. Выбор User Story и Задач из Product Backlog в Sprint Backlog;
Формулировка цели спринта — Sprint Goal. Определение ценности для бизнеса. Краткое описание бизнес-цели, ради которой выполняется данный спринт. Помогает команде принимать бизнес-обоснованные решения, или альтернативные решения. - Вторая часть митинга участвуют только Scrum Team. Наполнение Sprint Backlog.
Определение, каким образом будет реализован объем работ. Обсуждение технических деталей;
Scrum Poker (Planning Poker).
Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:
- Scrum Master ведет собрание;
- Product Owner представляет краткие обзоры каждой задачи;
- Происходит обсуждение, задаются вопросы;
- Участники Developer Team выбирают по одной карте, потом переворачивают;
- Если в результате голосования есть большой разброс в очках, то выслушивают двоих, перевернувших карты с минимальным и максимальным значением;
- Затем голосуют вновь и присваивают задаче Story Points.
Daily Scrum Meeting
Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.
- Проводится в одно и то же время;
- Длится строго не более 15 минут. Решение проблем выносится за рамки митинга и в составе лиц, непосредственно затронутых данным препятствием;
- Все отвечают только на три вопроса, отвечают друг другу, не Scrum Master-у: Что я сделал вчера? Что я буду делать сегодня? Какие проблемы есть у меня и команды на пути к цели?
Sprint Review Meeting
Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.
Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.
Sprint Retrospective Meeting. Ретроспектива.
Проводится в последний день спринта.
Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.
Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?