Корпоративные тренинги по гибким моделям управления
group 3 equalizer 5

Структура Scrum — основополагающие элементы в структуре

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

Отсутствие какой-либо части означает, что вы реализуете не Scrum, а что-то другое.

Корпоративное обучение гибким моделям управления и бережливому запуску стартапов
Agile Scrum OKR Kanban Growth Hacking Customer Development Design Thinking Lean Startup Юнит–экономика Business Agility Test Driven Development Impact Mapping Jobs To Be Done Product Management Agile Retrospectives Scrum Mastership
  • Корпоративные тренинги с дополнительным онлайн–обучением и закреплением навыков через мобильное приложение на IOS и Android.
  • Мы имеем десятки успешных кейсов запуска новых продуктов в рамках крупных компаний — финтех–стартапы, маркетплейсы, классифайды, включая проекты на американском и китайском рынке.

Кен Швабер однажды сравнил Scrum с шахматами, и это отличная аналогия.

Вы не можете просто изменить правила игры в шахматы и при этом заявить, что играете в шахматы; нет никаких «домашних» правил. Если я решу, что королева может прыгать через фигуры на своем пути, чтобы добраться до другой фигуры, у меня будет совершенно новая игра (и скорее всего плохая).

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

3 роли в Scrum

Владелец Продукта — ЧТО

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

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

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

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

Команда разработчиков — КАК

Команда разработчиков отвечает за то, чтобы работа, выбранная в журнале Sprint Backlog, была выполнена.

Они владеют исключительно бэклогом спринта (Sprint Backlog), и никто не может вносить в него изменения без согласия команды. Хорошая команда разработчиков самоорганизуется и самоуправляется; они сами решают, как они будут работать, и какую работу они будут выполнять в спринт, чтобы максимизировать ценность, которую они создают.

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

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

Скрам Мастер — ПРОЦЕСС

Скрам Мастер отвечает за то, чтобы команда действительно следовала правилам Scrum.

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

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

5 событий в Scrum

Спринт

Спринт сам по себе является «бьющимся сердцем» Scrum.

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

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

Планирование Спринта

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

Это шанс не только решить, над чем работать, но и придумать план, как выполнить эту работу.

Без планирования спринта нет хорошего способа официально договориться о том, какая работа будет выполнена и как ее выполнять.

Ежедневный Скрам

Ежедневный Скрам (The Daily Scrum) — это то, как команда собирается один раз в день, не более 15 минут, чтобы поговорить о проделанной работе и спланировать следующие 24 часа.

Собрание Daily Scrum — его часто называют Daily Standup — не требует, чтобы команда стояла (хотя это считается лучшей практикой для совместно расположенных команд). Это также не отчет о состоянии всех в команде разработчиков. Члены команды должны разговаривать друг с другом и планировать свою работу, а не отчитываться перед Скрам Мастером и / или Владельцем Продукта, чтобы показать прогресс в достижении цели.

На самом деле, Скрам Мастеру или Владельцу Продукта даже не обязательно посещать ежедневный Scrum (хотя это крайне желательно). Как спринт обеспечивает быструю обратную связь, так и Daily Scrum — это ежедневное мероприятие «Проверяй и адаптируй», которое позволяет команде быстро менять курс, если необходимо что–то исправить, и следить за тем, чтобы они были в состоянии достичь целей спринта.

Демо Спринта

Демо Спринта, или Обзор Спринта (The Sprint Review) — позволяет показать работу которая была выполнена в рамках спринта заинтересованным сторонам.

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

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

Ретроспектива Спринта

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

Пожалуй, это самое важное событие «Инспекции и адаптации», которое имеется в Scrum.

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

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

3 Артефакта в Scrum

Бэклог Продукта

Бэклог Продукта (The Product Backlog) — это видение Владельца Продукта.

Он поддерживается в режиме реального времени и точно–в-срок, чтобы обеспечить работу, достаточную для следующих нескольких спринтов.

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

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

Бэклог Спринта

Бэклог Спринта (The Sprint Backlog) является частью бэклога продукта, состоящего исключительно из задач, которые команда разработчиков планирует реализовать в текущем спринте.

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

Инкремент Продукта

Окончательный результат Спринта — это Инкремент Продукта.

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

Коломенский Андрей из LeadStartup
Андрей Коломенский
— Мы в LeadStartup за прошлый год завершили 16 кейсов по росту прибыли и выводу новых продуктов на рынок.
Треть — убыточны, лучший кейс: 99% годового плана за полтора месяца. География рынков: Россия, США и Китай.
Если вы руководитель и отвечаете за деньги — давайте общаться. Дадим конкретику, как можно вырастить прибыль вашего продукта и релевантные кейсы.
Корпоративные программы LeadStartup
Корпоративные программы
Корпоративное обучение гибким моделям управления и бережливому запуску стартапов
Agile Scrum OKR Kanban Growth Hacking Customer Development Design Thinking Lean Startup Юнит–экономика Business Agility Test Driven Development Impact Mapping Jobs To Be Done Product Management Agile Retrospectives Scrum Mastership
  • Корпоративные тренинги с дополнительным онлайн–обучением и закреплением навыков через мобильное приложение на IOS и Android.
  • Мы имеем десятки успешных кейсов запуска новых продуктов в рамках крупных компаний — финтех–стартапы, маркетплейсы, классифайды, включая проекты на американском и китайском рынке.
Ответим вам по электронной почте в течение 1 часа
По телефону — мгновенно, ежедневно с 9:00 до 20:00