Читать книгу Все о SCRUM. Изучение, разработка, интеграция - Клод Обри - Страница 12

2.3.1 Четкий ритм

Помимо итеративного и инкрементального процесса, какие еще можно выделить характеристики Scrum-спринта?

✓ Короткие итерации: продолжительность спринта варьируется от недели до месяца.

✓ Строгая последовательность: спринты не перемешиваются между собой.

✓ Четкий ритм: спринты имеют одинаковую продолжительность.

Рисунок 2.5 – Разница между инкрементальным и Agilе-подходом

Продолжительность спринтов всегда одинакова, что помогает команде держать ритм.

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

2.3.2 Отрезок времени

Спринт соответствует определенному временному отрезку. После начала спринта команда не может менять дату его окончания, даже если она уже достигла поставленной цели!

Почему так? Такой подход позволяет избежать почти законченного синдрома (минутку, я почти закончил!), из-за которого дата окончания спринта может быть неоднократно отодвинута.

Рисунок 2.6 – Отрезок времени

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

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

Рисунок 2.7 – Стая слепней помогает отрабатывать спринтерский бег на коротких дистанциях

2.3.3 Продолжительность спринта

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

Продолжительность спринта кратна неделе: спринт не может длиться 13 или 17 дней. Так намного проще ориентироваться.

По части продолжительности. Здесь нет единого мнения, все зависит от контекста. Но она должна быть четко зафиксирована.

Результаты опроса, проведенного в мае 2015 на странице моего блога, показывают, что чуть меньше половины (44 %) команд проводят спринты продолжительностью в две недели, и почти для четверти (24 %) команд спринты составляют три недели.

Чтобы определить продолжительность спринта, существует несколько критериев, на которые нужно обратить внимание:

✓ Производительность и результативность команды.

✓ Готовность заинтересованных сторон давать обратную связь.

✓ Простота в подготовке событий спринта – спринт предполагает дополнительную работу по организации событий.

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

Определение продолжительности спринта является одной из задач начинающей команды (см. главу 13).

2.3.4 События спринта

Цикл разработки – это последовательность стадий, каждая из которых отмечена определенными процессами. Для разработки программного обеспечения процессы обычно следующие: написание спецификации, архитектура (проектирование), написание кода, тестирование (интеграция и приемка). Для упрощения я буду использовать буквы С, A, К и T соответственно для обозначения этих действий на схемах.

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

Рисунок 2.8 – Спринты и процессы в параллели

Внутри спринта процесс не последовательный (С, затем A, затем К, затем T). Преобладающая идея – идея непрерывного потока, прерванного только в конце спринта.

Другой вариант – это так называемый последовательный цикл, разворачивающий последовательные процессы, по одному процессу на стадию.

Рисунок 2.9 – Последовательные процессы

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

Следовать этому подходу буквально означает:

✓ 100 % готовность спецификации до перехода к проектированию.

✓ 100 % готовность проекта до перехода к написанию кода.

✓ 100 % готовность кода до перехода к тестированию.

Это утопичная модель. В реальности команда всегда возвращается к предыдущим стадиям: на стадии тестирования команда возвращается к написанию спецификации – и так далее.

Такое различие между моделью и ситуацией в реальной жизни является одной из причин неудач проектов по V-модели и получаемых в их результате продуктов среднего качества.

Agile-подход более прагматичен: работа над спецификацией и проектированием непрерывна. Архитектура развивается с новыми функциями.

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

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

Опытная Agile-команда в каждом спринте проводит 100 % тестов до того, как будет написано 100 % кода, и достигает 100 % готовности кода до того, как на 100 % написана спецификация.