Блог

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

Сен 20, 2021

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

Цель тренинга

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

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

  • Выбрать элементы для бэклогов 1-го, 2-го и 3-го спринтов, беря их из существующего бэклога продукта.
  • Установить критерии готовности элементов бэклога в спринте.
  • Создать инкремент продукта в рамках бэклога спринта.
  • Продемонстрировать разработанный продукт другой команде.

Проведение тренинга

Подготовка

Участники остались в тех же командах, в которых были на предыдущем тренинге (Тренинг 2: «Наполнение и оценка бэклога проекта»). Владельцы продуктов и Скрам-мастера остались в своих ролях.

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

Повестка дня была рассчитана на 3 «двухдневных» спринта продолжительностью 15 минут каждый, плюс 5 минут для ежедневных Скрамов, проводимых одновременно в обеих командах. В конце каждого спринта команды устраивали его пятиминутный обзор для всех участников тренинга.

Определение критериев готовности

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

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

В обеих командах разработка продукта велась следующим образом:

  • Команды одновременно спланировали 1-й спринт, используя существующий бэклог продукта (потрачено 5 минут).
  • Основной период разработки продукта: 15 минут считаются как «первый день», затем 5-минутный Скрам и 15 минут – «второй день».
  • Обзор спринта и планирование 2-го спринта (по 5 минут на команду).
  • Создание бэклога 2-го спринта.

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

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

Демонстрация продукта

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

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

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

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

Дальнейшая разработка

После демонстрации инкремента 1-го спринта обе команды спланировали 2-й спринт, элементы которого также были разработаны с учётом «двухдневной» программы. Он также закончился демонстрацией инкремента продукта у обеих команд.

Несмотря на то что в бэклоге продукта оставались элементы, процесс разработки был прекращен после 2-го спринта. Это было сделано с целью продемонстрировать нестабильность «запутанной» части модели Кеневина, используемой большинством команд разработчиков программного обеспечения.

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

Основные положения тренинга

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

Новое в блоге

Первый курс на платформе GRSE TalentLab: Как мы обучали Angular с нуля

В июле 2024 года завершился первый онлайн-курс на базе нашей новой образовательной платформы - “GRSE TalentLab”. Курс был посвящен основам технологии Angular. Для удобства он был разделен на две части: подготовительную и основную. Подготовительный курс Цель...

Разработка через прототипирование

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

Современный подход к подготовке технической документации

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