Итерация (стадия, временной отрезок), в рамках которой производится разработка продукта в Scrum, называется спринтом (Sprint). Спринт обычно составляет 1‒4 недели (40‒160 рабочих часов), и его продолжительность неизменна на всем протяжении разработки. Изменение продолжительности спринтов неизбежно приводит к потере командой рабочего ритма и снижению эффективности ее работы. Каждый спринт должен заканчиваться новой версией продукта (инкремент).
Итерация в Scrum
Спринт начинается с планирования, в ходе которого команда должна найти ответы на два вопроса: 1) какой объем работы можно выполнить в предстоящем спринте и 2) как она будет выполняться.
После обсуждения требований с владельцем продукта команда декомпозирует требования в конкретные задачи для реализации этих требований. Эти задачи составляют содержимое Журнала Спринта. Затем создается план, чтобы все задачи были выполнены до конца спринта.
В течение спринта команда собирается на ежедневные «летучки»-совещания (Daily scrum), чтобы обсудить текущие проблемы.
Спринт завершается Обзором Спринта (Sprint Review), в рамках которого Владелец продукта предъявляет инкремент, то есть новый билд продукта с разработанным в рамках спринта функционалом.
После этого команда проводит Ретроспективу Спринта (Sprint Retrospective). На ней определяются области работы, требующие улучшений.
Такой порядок повторяется в конце каждого спринта.
Один из важнейших показателей при использовании Scrum – ритм работы команды, то есть скорость, с которой выполняются задачи без перенапряжения сил. Для поддержания рабочего ритма важно:
1. обеспечить фокус команды на задачах проекта без отвлечения на посторонние задачи;
2. правильно оценивать время выполнения задачи;
3. отслеживать прогресс по спринтам.
Для оценки времени на выполнение задачи ты можешь использовать любой из методов, изложенных в параграфе «Планирование ресурсов». А для отслеживания прогресса по спринтам неплохо подходит диаграмма сгорания (Burndown chart). Она сравнивает планируемую скорость работы команды с реальной.
Особенность Scrum – упор на самоорганизующуюся, многофункциональную команду. Это позволяет снизить затраты на координацию и управление, но может привести к повышению затрат на отбор персонала, его мотивацию и обучение.
Пример диаграммы сгорания
Кроме того, несмотря на кажущуюся простоту, Scrum часто используют неправильно. Для таких случаев существует даже особое понятие – Ограниченный Scrum (ScrumBut); это использование лишь части принципов Scrum. Такой подход приводит к существенному ухудшению производительности по сравнению даже с отсутствием методологии. Классические примеры ScrumBut:
1. отсутствие критериев готовности (Definition of Done);
2. неодинаковая длительность спринтов;
3. длительность спринта более 4 недель;
4. проведение «летучек» (Daily Scrum) не каждый день;
5. отсутствие ретроспектив и т. д.
Чтобы компенсировать недостатки разных подходов и усилить их достоинства, часто предпринимаются попытки создания различных гибридных методологий, которые могут удачно использоваться в игровой разработке.
Один из примеров такого подхода – использование V-модели для создания прототипа игры с последующим переходом к Scrum для цикличного наращивания функционала и развития проекта. В этом случае роль группы обеспечения качества возрастает: тестирование проводится с самого начала проекта и далее тестируется результат каждой итерации (спринта).
Использование гибких подходов в разработке накладывает на работу тестировщика дополнительную ответственность, связанную с достаточно сжатыми сроками итераций, в рамках которых разработчикам нужно не только нарастить функционал приложения, но и постараться исправить наиболее серьезные дефекты. В этих обстоятельствах тестировщику нужно уметь правильно не только определить критичность дефекта, но и правильно его приоритизировать, то есть определить сроки его исправления.
2.4.2. Использование ветвления (Branching)
Разработка в разных ветках (branching) – это методология, которая позволяет команде разработчиков работать над различными версиями кода в отдельных ветках, которые могут быть слиты в основную (main branch) после того, как функциональность будет разработана и протестирована. Это позволяет разработчикам изолировать свои изменения от других членов команды, ускорить процесс разработки и снизить вероятность конфликтов в коде.