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

В этой короткой статье я перечисляю основные изменения в новой версии Руководство по Скраму 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 лично. Удачного вам использования Скрама в ближайшие годы!

Scrum ON!

Скрам — это дизайн совершенства!

В этой статье хочу поддержать тех, кто начал использовать Скрам и чувствует некоторое разочарование. На тренинге рисовалась идеализированная картинка, которая не “налезла” на реалии организации. Как говорит один мой друг: “ожидания и реальность”. Поясню, почем не нужно расстраиваться. Давайте разберемся. 

Проблема с холодильниками

В 50-х годах компания General Electrics выпускала холодильники с дверцами двух видов: открывающихся или на правую, или на левую сторону. Компания никак не могла найти баланс между выпуском двух вариантов. Когда спрос одной модели превышал предложение, то покупатели вынуждены были ждать и уходили к конкурентам. Когда предложение превышало спрос, холодильники простаивали на складах и приносили убытки.

Было испробовано несколько стратегий:

  • Сначала менеджмент вообще ничего не предпринимал.
  • Отдел продаж начал прогнозировать спрос в регионах.
  • Подключили математическую статистику для уточнения прогнозов.

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

“Решение” (resolution) и “растворение” (dissolving) проблем

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

Можно контролировать/управлять проблемами, приспосабливаясь к ним, а можно фундаментально устранять.

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

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

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

Проблема“Решение” проблемы“Растворение” проблемы
Распределенные команды и негативные последствия (недоверие, асинхронные зависимости, высокие издержки и потери при коммуникации).Эффективные электронные инструменты, качественная фасилитация, очные встречи, например, раз в квартал и т. д.Колоцированные команды, сидящие в одном помещении за одним столом.
Экономические потери, вызываемые очередями (длинные циклы, повышенная вариабельность, сниженное качество и мотивация).Управление очередями, сигнальные карточки (канбан), WIP-лимиты.“Идеальный поток”, работа в стиле one-piece flow, использование техник моб-программирования, swarming.
Зависимости между командамиУправление зависимостями (выделенные координаторы, встречи).Команды без зависимостей (кросс-функциональные и кросс-компонентные), которые непрерывно интегрируются.
Необходимость в координацииВыделенные координаторы, специальные централизованные встречи, координационные роли и подразделения.Создание условий для возникающей самоорганизации (децентрализованные техники координации, колокация команд, непрерывная интеграция в коде).
Читать далее «Скрам — это дизайн совершенства!»

Скрам — это легко! Просто используйте его, как есть!

Перевод оригинальной статьи Кена Швабера “Scrum is simple, use it as it is!”

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

  1. Малые, самоорганизующиеся и самоуправляемые команды;
  2. Принципы Lean;
  3. Эмпирический подход, проведение частых инспекций и адаптаций, чтобы направлять работу команд к наилучшему из возможных результатов.

Руководство по Скраму — это свод знаний, который однозначно определяет, что такое Скрам (а также, разумеется, чем Скрам не является). Руководство по Скраму не указывает вам, как использовать Скрам, как внедрять Скрам или как разрабатывать продукты по Скраму.

Люди изучали Скрам и учились его использовать, посещая курсы и конференции, читая книги и блоги и т. п., но в первую очередь — создавая полезные вещи на основе видений, концепций и желаний, опираясь на свое понимание Скрама. И по мере того, как они продвигались, Скрам приобретал смысл. Скрам помог им достичь результатов, но… Когда люди стали пытаться применять Скрам, они поняли, что сложность заключается в том, чтобы получить разделяемое всеми понимание того, какой желаемый результат, какие у них возможности, что их умения позволят создать, а также как работать вместе, чтобы всего этого достичь. Читать далее «Скрам — это легко! Просто используйте его, как есть!»