Руководство по Scrum (Скрам): роли, события и артефакты

Руководство по Scrum (Скрам): роли, события и артефакты

Содержание

Введение

Это третья статья из серии статей об Agile (Аджайл). В предыдущих статьях мы начали погружение в мир Agile, рассмотрев основные ценности и принципы, которые лежат в основе этого подхода. Мы выяснили, как Agile помогает командам адаптироваться к изменениям и добиваться успеха в условиях неопределенности. Теперь настало время углубиться в одну из самых популярных и эффективных методологий Agile — Scrum (Скрам). В этой статье мы разберем ключевые элементы Scrum (Скрам), чтобы вы могли понять, как этот фреймворк помогает командам работать более эффективно и продуктивно.

Понимание Scrum (Скрам)

Для того чтобы глубже понять Scrum (Скрам) и его важность в мире Agile, необходимо рассмотреть его основные элементы, историю и философию, которые лежат в его основе.

Что такое Scrum (Скрам)

Scrum (Скрам) — это легкий фреймворк, который помогает людям, командам и организациям создавать ценность, предлагая адаптивные решения для комплексных проблем. Этот фреймворк требует создания среды, в которой:

  1. Product Owner (владелец продукта) упорядочивает работу по решению сложных задач в Product Backlog (бэклоге продукта).

  2. Scrum Team (Скрам-команда) в ходе Sprint (спринта) превращает выбранную работу в Increment (инкремент), несущий ценность.

  3. Scrum Team (Скрам-команда) и заинтересованные лица инспектируют результаты и вносят изменения для следующего Sprint (спринта).

  4. Процесс повторяется.

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

Scrum, как описано в Руководстве по Scrum, включает три ключевые роли: Product Owner (владелец продукта), Scrum Master (Скрам-мастер) и Developers (разработчики). Эти роли обеспечивают баланс между управлением, поддержкой и выполнением работы, помогая команде достигать поставленных целей. Скрам-команда участвует в четырех основных событиях: Sprint Planning (планирование спринта), Daily Scrum (ежедневный Скрам), Sprint Review (обзор спринта) и Sprint Retrospective (ретроспектива спринта). Эти события проходят в рамках Sprint (спринта), который служит контейнером для остальных событий и позволяет команде управлять своим рабочим процессом, создавая три артефакта: Product Backlog (бэклог продукта), Sprint Backlog (бэклог спринта) и Increment (инкремент).

Происхождение Scrum (Скрам)

Название “Scrum” было заимствовано из регби, где оно обозначает коллективную схватку, в которой команда работает вместе, чтобы продвинуть мяч вперед. В контексте проектного управления, Scrum (Скрам) работает по аналогии: команда совместно продвигает продукт, непрерывно улучшая его на каждом этапе разработки.

Scrum (Скрам) был разработан Кеном Швабером и Джеффом Сазерлендом в начале 1990-х годов как ответ на потребность в гибком подходе к разработке программного обеспечения, который бы обеспечивал быструю адаптацию к изменениям и высокую продуктивность.

Эмпирический процесс, ценности и принципы в Scrum (Скрам)

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

Основные ценности Scrum (Скрам) — приверженность, сфокусированность, открытость, уважение и смелость — помогают создать атмосферу, где команда может эффективно достигать поставленных целей. Эти ценности поддерживают открытую коммуникацию и взаимодействие внутри команды, что способствует успешной работе и решению сложных задач.

Scrum (Скрам) работает в коротких циклах, называемых Sprints (спринтами), в течение которых команда инкрементально доставляет ценность. Обратная связь, полученная в ходе спринта, позволяет проводить регулярную инспекцию и адаптацию, обеспечивая постоянное улучшение продукта и процессов. Scrum Team (Скрам-команда) несет ответственность за создание ценного Increment (инкремента) продукта, который инспектируется и корректируется в сотрудничестве с заинтересованными сторонами для будущих спринтов.

Scrum Team (Скрам-команда)

Scrum Team (Скрам-команда) включает одного Scrum Master (Скрам-мастера), одного Product Owner (владельца продукта) и Developers (разработчиков). Эта команда работает как единое целое, без разделения на подгруппы или иерархические структуры, что обеспечивает слаженность работы всех участников и направляет их усилия на достижение Product Goal (цели продукта).

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

Scrum Team (Скрам-команда) обычно небольшая, ее размер составляет до 10 человек, что позволяет ей оставаться гибкой и поддерживать эффективную коммуникацию. Если команда становится слишком большой, её делят на несколько компактных Scrum Teams (Скрам-команд), каждая из которых работает с теми же Product Goal (целью продукта), Product Backlog (бэклогом продукта) и Product Owner (владельцем продукта), что и исходная команда.

Scrum Team (Скрам-команда) отвечает за весь цикл создания продукта: от взаимодействия с заинтересованными сторонами до проверки, обслуживания, эксплуатации, экспериментов, исследований и разработки. Организация наделяет команду полномочиями управлять собственной работой, что позволяет сосредоточиться на выполнении задач и поддерживать стабильный темп работы в рамках спринтов.

Вся Scrum Team (Скрам-команда) несет ответственность за создание ценного и полезного инкремента в каждом спринте. Каждая из трех специфических ролей внутри команды играет ключевую роль в успешном достижении ее целей.

Эти аспекты организации Scrum Team (Скрам-команды) помогают поддерживать её эффективность, гибкость и способность адаптироваться к изменениям, что в конечном итоге ведет к успешному достижению цели продукта.

Scrum Master (Скрам-мастер)

Scrum Master (Скрам-мастер) несет ответственность за внедрение Scrum (Скрам) в команде и в организации, содействуя пониманию теории и практики Scrum (Скрам). Он поддерживает команду и организацию в принятии Agile-принципов, способствуя эффективной адаптации методологии Scrum (Скрам).

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

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

Scrum Master (Скрам-мастер) помогает Product Owner (владельцу продукта) в правильном использовании подходов для определения Product Goal (цели продукта), управления Product Backlog (бэклогом продукта), планирования в сложных условиях, а также содействует взаимодействию с заинтересованными сторонами.

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

Чтобы быть эффективным, Scrum Master (Скрам-мастер) принимает различные роли, такие как “лидер-слуга”, “фасилитатор”, “коуч”, “менеджер”, “ментор”, “учитель”, “устраняющий препятствия” и “агент изменений”, в зависимости от ситуации. Эти роли позволяют ему справляться с различными вызовами, с которыми сталкивается команда, и поддерживать непрерывное улучшение процессов.

Такой многосторонний подход позволяет Scrum Master (Скрам-мастеру) оставаться ключевым элементом в успешной реализации Scrum, обеспечивая команду поддержкой и направляя её в достижении поставленных целей.

Product Owner (владелец продукта)

Product Owner (владелец продукта) — это один человек, который несет ответственность за максимизацию ценности продукта через эффективное управление Product Backlog (бэклогом продукта). Он обеспечивает, чтобы работа Scrum Team (Скрам-команды) была согласована с Product Goal (целью продукта) и приоритизирует задачи для обеспечения ценности для заинтересованных сторон и пользователей.

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

Для успешной работы вся организация должна уважать решения Product Owner (владельца продукта). Эти решения отражаются в содержании и порядке элементов Product Backlog (бэклога продукта), а также в Increment (инкременте), который команда демонстрирует на Sprint Review (обзоре спринта).

Product Owner (владелец продукта) принимает на себя различные роли, такие как “визионер”, “партнер”, “представитель клиента”, “лицо, принимающее решения”, “экспериментатор” и “инфлюенсер”, чтобы эффективно управлять продуктом и максимизировать его ценность. Неправильное понимание ролей Product Owner (владельца продукта), например, лишь как автора пользовательских историй или же проектного менеджера, может привести к искаженному восприятию его обязанностей.

Developers (разработчики)

Developers (разработчики) несут ответственность за создание любого аспекта готового к использованию Increment (инкремента) в каждом спринте. Они участвуют в Sprint Planning (планировании спринта), создают и поддерживают Sprint Backlog (бэклог спринта), обеспечивают соответствие Increment (инкремента) Definition of Done (определению готовности), ежедневно адаптируют свои планы для достижения Sprint Goal (цели спринта) и поддерживают друг друга в профессиональном развитии.

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

Developers (разработчики) также участвуют в проведении мероприятий, таких как Daily Scrum (ежедневный Scrum), могут быть менторами, коучами и обучать других членов команды, особенно через практики, такие как парное программирование (Pair Programming), что способствует обмену навыками и обучению.

Developers (разработчики), наряду с остальными членами Scrum Team (Скрам-команды), должны придерживаться ценностей Scrum (Скрам), таких как приверженность, сфокусированность, открытость, уважение и смелость. Эти ценности играют ключевую роль в разрешении конфликтов, принятии новых идей, поддержании фокуса, приверженности инкременту и уважении к другим членам команды и их вкладу.

События Scrum (Скрам)

События Scrum (Скрам) призваны создавать регулярность и минимизировать необходимость в других встречах, которые не предписаны Scrum (Скрам).

Sprint (спринт) действует как контейнер для всех остальных событий Scrum (Скрам), что гарантирует их проведение в рамках единой и согласованной структуры.

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

Для уменьшения сложности рекомендуется проводить все события Scrum (Скрам) в одно и то же время и в одном и том же месте, когда это возможно.

Sprint (спринт)

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

Sprint (спринт) имеет фиксированную продолжительность — не более одного месяца, что обеспечивает короткие итерации для получения обратной связи и минимизации сложности и рисков. Новый Sprint (спринт) начинается сразу после завершения предыдущего.

Во время Sprint (спринта) не вносятся изменения, которые могут поставить под угрозу достижение Sprint Goal (цели спринта). Качество работы должно поддерживаться на высоком уровне, Product Backlog (бэклог продукта) уточняется, а объем работы, выбранной на Sprint (спринт), может быть уточнен или пересмотрен совместно с Product Owner (владельцем продукта) по мере необходимости.

Product Goal (цель продукта) является долгосрочной целью, отраженной в Product Backlog (бэклоге продукта), и направляет работу Scrum Team (Скрам-команды). Sprint Goal (цель спринта) — это краткосрочная, гибкая цель на Sprint (спринт), которая обеспечивает фокус и согласованность действий команды, помогая ей работать сообща.

Эмпирический подход играет ключевую роль в ходе Sprints (спринтов), позволяя Scrum Team (Скрам-команде) учиться на практике и постоянно совершенствоваться. Прогресс часто отслеживается с помощью таких инструментов, как диаграммы сгорания задач или кумулятивные потоки, однако они не могут отменить важность эмпирического обучения.

Sprint (спринт) может быть отменен, если Sprint Goal (цель спринта) потеряла актуальность. Такое решение может принять только Product Owner (владелец продукта).

Sprint Planning (планирование спринта)

Sprint Planning (планирование спринта) инициирует Sprint (спринт), определяя работу, которая должна быть выполнена. Вся Scrum Team (Скрам-команда) участвует в создании плана, который согласуется с Product Goal (целью продукта).

Product Owner (владелец продукта) заранее готовит команду к обсуждению самых важных элементов Product Backlog (бэклога продукта) и их вклада в достижение Product Goal (цели продукта).

Основные вопросы, обсуждаемые на Sprint Planning (планировании спринта):

  • Почему этот спринт важен? Product Owner (владелец продукта) предлагает, как продукт может повысить свою ценность, что приводит к созданию Sprint Goal (цели спринта), отражающей эту ценность.
  • Что можно сделать в этом спринте? Scrum Team (Скрам-команда), при поддержке Product Owner (владельца продукта), выбирает элементы из Product Backlog (бэклога продукта) для включения в Sprint (спринт), уточняя их по мере необходимости.
  • Как будет выполняться выбранная работа? Developers (разработчики) планируют необходимые шаги для преобразования элементов Product Backlog (бэклога продукта) в завершенный Increment (инкремент), при необходимости разбивая задачи на более мелкие части.

Результатом Sprint Planning (планирования спринта) является создание Sprint Backlog (бэклога спринта), который включает в себя Sprint Goal (цель спринта), выбранные элементы Product Backlog (бэклога продукта) и план их выполнения.

Sprint Planning (планирование спринта) ограничено по времени и занимает максимум восемь часов для спринта длиной в один месяц, причем для более коротких спринтов отводится пропорционально меньше времени.

Daily Scrum (ежедневный Scrum)

Daily Scrum (ежедневный Scrum) имеет основную цель — инспектировать прогресс в направлении Sprint Goal (цели спринта) и при необходимости адаптировать Sprint Backlog (бэклог спринта), чтобы команда оставалась на верном пути.

Daily Scrum (ежедневный Скрам) — это 15-минутное событие, которое проводится каждый день в одно и то же время и в одном и том же месте на протяжении всего Sprint (спринта). Developers (разработчики) сами выбирают структуру и методы проведения встречи, сосредотачиваясь на создании плана действий на следующий день. Если Product Owner (владелец продукта) или Scrum Master (Скрам-мастер) активно работают над элементами из Sprint Backlog (бэклога спринта), они могут участвовать в Daily Scrum (ежедневном Скрам) в качестве разработчиков.

Scrum Master (Скрам-мастер) следит за тем, чтобы Daily Scrum (ежедневный Скрам) проводился и учит команду укладываться в 15-минутный таймбокс. Однако ответственность за проведение встречи лежит на Developers (разработчиках).

Эта встреча улучшает коммуникацию, выявляет препятствия, способствует принятию быстрых решений и помогает избежать необходимости в дополнительных встречах. Developers (разработчики) могут корректировать свои планы не только во время Daily Scrum (ежедневного Scrum), но и проводить дополнительные встречи в течение дня для обсуждения и адаптации оставшейся работы.

Daily Scrum (ежедневный Скрам) позволяет команде оценивать прогресс и вносить необходимые коррективы для оптимизации вероятности достижения Sprint Goal (цели спринта). Это постоянное приспособление является центральным элементом процесса Scrum (Скрам).

Sprint Review (обзор спринта)

Sprint Review (обзор спринта) имеет основную цель — инспектировать результаты Sprint (спринта) и определить необходимые шаги для адаптации. Он обеспечивает согласованность между Scrum Team (Скрам-командой) и заинтересованными сторонами в отношении прогресса в достижении Product Goal (цели продукта).

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

Участниками Sprint Review (обзора спринта) являются Scrum Team (Скрам-команда) и ключевые заинтересованные стороны, приглашенные Product Owner (владельцем продукта). На встрече Scrum Team (Скрам-команда) обсуждает, что было завершено, а что осталось незавершенным, а Developers (разработчики) делятся успехами, вызовами и решениями, с которыми они столкнулись в ходе Sprint (спринта). Developers (разработчики) демонстрируют выполненную работу и отвечают на вопросы об Increment (инкременте).

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

Результатом Sprint Review (обзора спринта) становится обновленный Product Backlog (бэклог продукта), который отражает вероятные элементы для следующего Sprint (спринта), а также любые необходимые корректировки для использования новых возможностей или решения возникающих проблем.

Sprint Retrospective (ретроспектива спринта)

Sprint Retrospective (ретроспектива спринта) направлена на повышение эффективности и качества работы Scrum Team (Скрам-команды) путем анализа прошедшего Sprint (спринта) и планирования улучшений.

Scrum Team (Скрам-команда) обсуждает, как прошел Sprint (спринт) с точки зрения взаимодействия людей, процессов, инструментов и соответствия Definition of Done (определению готовности). Они анализируют, что сработало хорошо, какие проблемы возникли, как эти проблемы были решены, а также выявляют причины, которые могли сбить команду с пути, и исследуют их происхождение.

Scrum Team (Скрам-команда) определяет наиболее значимые изменения, необходимые для повышения эффективности. Эти улучшения приоритизируются и могут быть добавлены в Backlog (бэклог) следующего Sprint (спринта).

Sprint Retrospective (ретроспектива спринта) ограничена по времени и занимает три часа для Sprint (спринта) длиной в один месяц, с пропорционально меньшей продолжительностью для более коротких Sprints (спринтов).

К концу Sprint Retrospective (ретроспективы спринта) команда берет на себя обязательства по внедрению конкретных улучшений в следующем Sprint (спринте), что обеспечивает непрерывную адаптацию и совершенствование рабочих процессов.

Артефакты Scrum (Scrum)

Артефакты Scrum (Скрам) создаются для повышения прозрачности и предоставления четкой основы для инспекции и адаптации, что гарантирует единое понимание ключевой информации всеми участниками.

Для каждого артефакта существуют определенные обязательства:

  • Product Backlog (бэклог продукта): Связан с Product Goal (целью продукта), который направляет общее развитие и цель продукта.
  • Sprint Backlog (бэклог спринта): Привязан к Sprint Goal (цели спринта), которая определяет фокус и цель текущего спринта.
  • Increment (инкремент): Ассоциируется с Definition of Done (определением готовности), что гарантирует соответствие работы требуемым стандартам перед тем, как она будет считаться завершенной.

Эти обязательства усиливают эмпирический подход и поддерживают ценности Scrum (Скрам), помогая Scrum Team (Скрам-команде) и заинтересованным сторонам оставаться согласованными и сосредоточенными на прогрессе.

Product Backlog (бэклог продукта)

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

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

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

Product Backlog (бэклог продукта) тесно связан с Product Goal (целью продукта), — долгосрочной целью, которая направляет работу Scrum Team (Скрам-команды). В Product Backlog (бэклоге продукта) содержатся элементы, которые способствуют достижению этой цели. Scrum Team (Скрам-команда) фокусируется на выполнении одной Product Goal (цели продукта), прежде чем приступить к следующей.

Product Goal (цель продукта) определяет будущее состояние продукта и служит ориентиром для планирования и приоритизации в рамках Product Backlog (бэклога продукта).

Product Goal (цель продукта)

Product Goal (цель продукта) — это долгосрочная цель, которая предоставляет контекст и направление для Scrum Team (Скрам-команды), направляя работу, изложенную в Product Backlog (бэклоге продукта).

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

По мере того как Scrum Team (Скрам-команда) учится и итерационно улучшает продукт, Product Backlog (бэклог продукта) эволюционирует, чтобы лучше соответствовать Product Goal (цели продукта). Цель остается прозрачной для всех заинтересованных сторон, помогая поддерживать фокус команды.

Во время Sprint Review (обзора спринта) команда и заинтересованные стороны оценивают прогресс в достижении Product Goal (цели продукта), используя эти выводы для обеспечения информацией последующего Sprint Planning (планирования спринта) и поддержания согласованности с Product Goal (целью продукта).

Sprint Backlog (бэклог спринта)

Sprint Backlog (бэклог спринта) состоит из Sprint Goal (цели спринта), выбранных элементов Product Backlog (бэклога продукта) для Sprint (спринта) и плана по созданию Increment (инкремента).

Sprint Backlog (бэклог спринта) предоставляет четкую и актуальную картину работы, запланированной на Sprint (спринт), делая его высоко видимым и необходимым для отслеживания прогресса во время Daily Scrum (ежедневного Скрам).

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

Каждый Increment (инкремент) представляет собой конкретный шаг к достижению Product Goal (цели продукта), причем все Increments (инкременты) добавляют ценность к предыдущим Increments (инкрементам) и являются полностью интегрированными друг с другом. Выполненная работа должна соответствовать Definition of Done (определению готовности), чтобы считаться частью Increment (инкремента), который может быть доставлен в любой момент в течение Sprint (спринта), а не только на Sprint Review (обзоре спринта).

Sprint Backlog (бэклог спринта) — это динамичный инструмент, который обновляется и адаптируется по мере приобретения новых знаний в ходе Sprint (спринта). Если возникают неожиданные изменения, Developers (разработчики) сотрудничают с Product Owner (владельцем продукта) для корректировки объема работ при сохранении Sprint Goal (цели спринта).

Sprint Goal (цель спринта)

Sprint Goal (цель спринта) — это основная цель Sprint (спринта), которая обеспечивает Scrum Team (Скрам-команде) четкий фокус и стимулирует сотрудничество вокруг общей задачи.

Sprint Goal (цель спринта) устанавливается во время Sprint Planning (планирования спринта) и добавляется в Sprint Backlog (бэклог спринта). Хотя цель остается неизменной, объем работы может быть скорректирован в сотрудничестве с Product Owner (владельцем продукта), если изменятся сложность или требования.

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

Daily Scrum (ежедневный Скрам) фокусируется на инспекции прогресса в достижении Sprint Goal (цели спринта), подчеркивая ее важность и обеспечивая согласованность команды с целью на протяжении всего спринта.

Increment (инкремент)

Increment (инкремент) — это конкретный шаг к достижению Product Goal (цели продукта), который добавляется к ранее выполненной работе и обеспечивает постепенное улучшение продукта.

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

В рамках одного Sprint (спринта) может быть создано несколько Increments (инкрементов), и они могут быть доставлены заинтересованным сторонам до Sprint Review (обзора спринта), если они готовы.

Работа считается частью Increment (инкремента) только в том случае, если она соответствует Definition of Done (определению готовности), что гарантирует единообразие и качество.

Definition of Done (DoD, определение готовности)

Definition of Done (определение готовности) — это формальное описание стандартов качества, которым должен соответствовать Increment (инкремент), чтобы считаться завершенным и готовым к выпуску. DoD (определение готовности) служит обязательством разработчиков обеспечивать выполнение этих критериев.

DoD (определение готовности) обеспечивает прозрачность и общее понимание того, что значит “готово”, гарантируя, что все знают, какие стандарты должны быть соблюдены для того, чтобы Increment (инкремент) мог быть выпущен.

DoD (определение готовности) может включать обязательные организационные стандарты, но Scrum Team (Скрам-команда) может добавить дополнительные критерии, специфичные для их продукта. Если организационные стандарты отсутствуют, команда создает подходящее DoD (определение готовности).

Примеры Definition of Done (определения готовности):

Для мобильного приложения:

  • Приложение прошло все этапы тестирования на основных платформах (iOS и Android).
  • Нет известных критических ошибок.
  • Пользовательский интерфейс (UI) соответствует руководству по дизайну.
  • Выполнен код-ревью и все замечания исправлены.
  • Приложение прошло тестирование на производительность.
  • Приложение загружено в тестовую среду и проверено на работоспособность.

Для статьи в блог:

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

Соответствие DoD (определению готовности) гарантирует, что Increment (инкремент) завершен и соответствует высоким стандартам качества. Это помогает сосредоточиться на создании работы, которая соответствует необходимым критериям, прежде чем она может считаться “готовой” к выпуску.

Обучение Agile

Изучив ключевые аспекты Scrum, вы можете заметить, насколько важно глубокое понимание Agile-принципов для успешного внедрения этой методологии. Чтобы развить это понимание и укрепить свои знания, мы рекомендуем пройти наш курс Основы Agile. В этом курсе вы познакомитесь с фундаментальными ценностями и практиками Agile, которые формируют основу для работы в Scrum, Kanban, XP и других методологиях:

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

Заключение

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

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

В следующих статьях мы будем подробно рассматривать практики другого известного фреймворка Agile — Extreme Programming (XP, экстремальное программирование).

Поделиться:
Об авторах:

Agile Uni

Автор проекта, создает обучающие курсы и публикует в блоге обучающие статьи и другие материалы по Agile (Аджайл).

Александр Филиппов

Александр Филиппов — эксперт в управлении ИТ-проектами, сертифицированный Scrum Master (PSM I) и бизнес-аналитик с фокусом на Agile-методологиях. Он делится своими знаниями через статьи в блоге Agile Uni.

Связанные записи

Ценности и принципы Agile: от манифеста к практике

Ценности и принципы Agile: от манифеста к практике

Изучите основные ценности и принципы Agile (Аджайл) и узнайте, как популярные фреймворки помогают внедрять эти принципы на практике для успешного управления проектами.

Подробнее
Введение в Agile

Введение в Agile

Эта статья — первая в серии статей об Agile (Аджайл), в которой рассказывается об истории Agile, Agile-манифесте, его авторах, практических принципах и популярных фреймворках.

Подробнее
Запускаем Agile Uni: Ваш новый путь к мастерству Agile!

Запускаем Agile Uni: Ваш новый путь к мастерству Agile!

Agile Uni анонсирует запуск инновационной образовательной платформы, сосредоточенной на Agile (Аджайл). Это не просто платформа для обучения, а пространство для практического применения знаний, где теория сочетается с практическим опытом и актуальными публикациями в нашем блоге. Присоединяйтесь к нам, чтобы пройти путь от основ Agile до профессионального мастерства, начиная с нашего первого курса и регулярно обновляемого блога.

Подробнее