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

Владелец Продукта — ЧТО Команда разработчиков — КАК Скрам Мастер — ПРОЦЕСС

Спринт, планирование Спринта, ежедневный Скрам, демо Спринта, ретроспектива Спринта

Бэклог Продукта Бэклог Спринта Инкремент Продукта

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

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

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

Давайте разберем каждый из элементов более детально.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обратите внимание, что это не цели бэклога, а именно цели рабочих процессов.

Например:

• «Общаться перед запуском нового обновления»

• «Сообщать когда требуется тестирование»

• «Собирать обратную связь после завершения части работы» и тому подобное.

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

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

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

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

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

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

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

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