Обзор Scrum

Обзор Scrum

В Scrum менеджер проекта называется Scrum Master, а команда проекта называется Scrum Team. Существует владелец продукта, который определяет приоритеты функций и требований, которые необходимо разработать в бэклоге продукта.

Методология Scrum использует спринты для предоставления небольших этапов работы и сбора обратной связи от клиентов.

Существует три (3) опоры Scrum:

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

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

• Прозрачность — Общий язык и стандарты для обеспечения согласованности и общего понимания.
• Проверка — Частый обзор прогресса Scrum и результатов для получения обратной связи. Важно не скрывать прогресс проекта.
• Адаптация — Легко интегрировать полученную обратную связь и решать возникающие проблемы.

Компоненты процесса Scrum

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

Основные компоненты фреймворка Scrum следующие:

• Роли Scrum: Scrum Master, Владелец продукта, и Scrum Team
• Артефакты: План спринта, План продукта, График сгорания, журналы, и т.д.
• События Scrum: Планирование спринта, Обзор спринта, Ежедневный стендап, Ретроспектива спринта, и т.д.
• Спринты

На приведённой ниже диаграмме показаны ключевые элементы фреймворка SCRUM. Этот процесс реализован в Инструмент Agile-разработки — Схема процесса Scrum.

Роли Scrum

Когда организация принимает решение внедрить Scrum, одним из первых шагов является понимание того, чем отличаются роли Scrum от традиционных ролей исполнения проектов. Несмотря на то, что в Scrum всего три основные роли, они не всегда соответствуют названиям ролей, с которыми мы знакомы. Давайте начнём с краткого определения каждой из них:

Продуктовый владельцы

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

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

Мастер скрам

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

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

Команда скрам

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

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

• Команда должна быть самоорганизованной. Все члены команды должны управлять своими усилиями для выполнения порученных задач. В агильном скраме отсутствует лидер команды или руководитель по линейной иерархии. Каждый должен быть достаточно вовлечен, чтобы выполнять свои обязанности и вносить вклад в успех команды. Если один не справляется, страдает вся команда.
• Команда должна быть межфункциональной. Все члены команды должны обладать знаниями и навыками, необходимыми для создания полного, готового к использованию продукта или услуги. Эксперты могут использоваться при необходимости, но только в качестве наставников для передачи знаний команде и заполнения конкретных пробелов.
• Продуктовый владельцу необходим бизнес-взгляд. Продуктовый владелец представляет голос клиента и должен передавать их потребности мастеру скрам и команде разработки. Обычно это должность на полной ставке.
• Мастер скрам не является линейным менеджером. Они обеспечивают необходимое наставничество для команды разработки и помогают устранять любые препятствия, с которыми сталкивается команда.

Продуктовый бэклог

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

Пользовательские истории — Разные представления о том, как пользователи взаимодействуют с результатами проекта (продукт, услуга или результат). Благодаря пользовательским историям команда определяет функции и функциональные возможности, необходимые для результатов.

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

Примечание: вам не нужно создавать все истории для всего проекта до начала работы (это одно из преимуществ гибкого подхода). Начните с историй, которые вы знаете, и по мере получения новых знаний добавляйте в бэклог и переприоритезируйте по мере необходимости.

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

В отличие от водопадного подхода, гибкие команды не планируют всё заранее. Здесь команда планирует немного: что необходимо для текущего спринта (спринты обычно длятся от 2 до 4 недель), выполняет его, извлекает уроки, а затем снова планирует следующий спринт.

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

Также устанавливается определение «Готово». Определение «Готово» можно рассматривать как критерии приемки для элементов бэклога.

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

Ежедневный стендап (ежедневная встреча Scrum)

Команда использует эту встречу для взаимных микропоручений, выявления проблем и обеспечения бесперебойного хода работы спринта внутри команды. Обычно она длится 15 минут. Команда отвечает на следующие вопросы:

• Что я завершил с момента последней встречи Scrum?
• Каков мой план на сегодня? Что я намерен завершить с этого момента до следующей встречи Scrum?
• Есть ли какие-либо препятствия (проблемы, вопросы или риски), которые мешают мне?

Помните, что эта встреча не является отчетной — она не предназначена для решения проблем, а для осознания их наличия (если они есть). Если требуется встреча для решения проблем, организуйте её отдельно.

Встреча по итогам спринта

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

Важно отметить, что элементы работы, которые не завершены на 100% в соответствии с определением «Готово», установленным на этапе планирования, не будут демонстрироваться, поскольку они не являются «Готовыми».

Встреча по итогам спринта (ретроспектива)

Это происходит после встречи по итогам спринта. Цель — помочь команде извлечь уроки из спринта. Процесс ориентирован на непрерывное улучшение, а не на обвинение команды, если что-то пошло не так в ходе спринта.

Команда анализирует, как стать более эффективной, и определяет другие области для улучшения.

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