Что делать с результатом спринта, если не вводить его в эксплуатацию для конечных пользователей? Можно направить его заинтересованным сторонам для осуществления следующих целей (впрочем, эти варианты не единственные):
✓ Снижение рисков – результат спринта можно использовать внутри команды разработчиков, возможно, технических экспертов. Это позволит минимизировать риски, связанные с технической частью и способностью команды интегрировать различные компоненты. Это также даст возможность узнать о качестве изнутри. Такой вариант особенно распространен во время первых спринтов.
✓ Получение обратной связи – результат спринта предоставляется выбранным заинтересованным сторонам. Это дает им возможность взять продукт под контроль и снижает риски, связанные с эргономикой. Они смогут оценить простоту использования функций и предложить новые. Обратная связь будет принята командой для последующего рассмотрения.
Развертывание в конце спринта, вне зависимости от ввода в эксплуатацию, дает возможность получить больше информации о результате работы команды.
2.5 Все о спринтах
Как и Scrum, в наши дни стали чрезвычайно популярны сериалы. Создатели того или иного сериала сначала проверяют интерес к своей идее, выпуская пилотную серию и подготавливая несколько эпизодов первого сезона. И если сезон будет хорошо принят зрителями, за первым на экраны выйдет второй, и третий, и еще больше, пока сохраняется интерес публики.
Эта аналогия спринта с эпизодом сериала поразила меня, и по этой причине я буду использовать термин «сезон» для обозначения последовательности из нескольких спринтов.
Ранее, в предыдущих изданиях этой книги, я использовал термин релиз. Но это постоянно приводило к путанице между периодом времени и поставкой в головах моих читателей. Поэтому я хотел бы заменить этот термин и в дальнейшем использовать слово сезон, когда речь идет о временном периоде, состоящем из нескольких спринтов.
Я рекомендую фиксировать сезон по продолжительности, как и спринт. Другими словами, все сезоны одинаковы по времени. Мы вернемся к этому в главе 16.
Как и в спринте, команда сама определяет продолжительность сезона.
Рисунок 2.10 – Релиз заменен сезоном. Наблюдается сопротивление переменам.
Паттерн сезонного ритма состоит в ритмичном делении периода разработки на отрезки по 3 месяца, в которые проходят спринты.
Оказывается, в этом может помочь деление времени на триместры. Посчитаем: триместр длится около 13 недель.
✓ Команда проводит двухнедельные спринты, выходит 6 спринтов за сезон, плюс остается неделя, о которой мы скоро поговорим.
✓ Команда проводит трехнедельные спринты, у нее выходит 4 спринта за сезон.
Цикл спринтов может продолжаться в течение длительного времени, например, нескольких сезонов. Есть также предпремьерный сезон, конец сезона и пост-финальный сезон.
Рисунок 2.11 – Спринты и сезоны
Период до начала спринтов составляет прелюдию.
Название нулевой спринт вызывает сомнения и приводит к недоразумениям, мы не будем его использовать. Следует понимать, что это этап, отличающийся от последующих спринтов.
Прелюдии посвящена целая глава (см. главу 13), мы к ней вернемся, когда познакомимся со всеми элементами Scrum.
Так как сезонов будет несколько, интерлюдия тоже будет не одна.
До этого мы видели, что спринты следовали один за другим, без интервала. В конце сезона рекомендуется делать передышку, скажем, на неделю.
Зачем? Чтобы провести на другой скорости цикл инспекции/адаптации, который бы охватывал более устойчивые темы, чем те, что были в фокусе спринта.
Это также поможет команде поддерживать желаемый ритм, который иногда нарушается в связи с непрерывной цепочкой спринтов.
Вот несколько вариантов того, чем можно заняться во время интерлюдии:
✓ празднование успеха команды,
✓ ретроспектива, посвященная окончившемуся сезону (см. главы 12 и 22),
✓ небольшое увеличение команды (см. главу 3),
✓ чистка бэклога (см. главу 8),
✓ прогнозы на следующий сезон (см. главу 16),
✓ открытый форум по вопросам Agility (см. главу 22),
✓ любая другая деятельность, не связанная с продуктом, – чтобы расслабиться или просто отвлечься.
Существует ли последний сезон?
Если команда прекращает работу над продуктом, это значит, что продукт мертв или передан другой команде. Последний вариант объясняется двумя возможными причинами:
✓ Трансфер c целью техобслуживания. Обычно ввод в эксплуатацию выполняется после разработки и другой командой. В некоторых организациях разработкой и обслуживанием занимаются разные люди. В Agile-подходе такого разделения нет. Те, кто занимается разработкой продукта, знают лучше остальных, как оказывать поддержку, исправлять ошибки и дальше его развивать. Следует помнить: в отличие от концепции проекта, цикл спринтов не заканчивается на первой версии. Он продолжается на протяжении всей жизни продукта, который развивается по мере релизов. Можно также сказать, что обслуживание начинается после первого ввода в эксплуатацию. Тем не менее, в жизни продукта может наступить момент, когда поток входных данных уменьшается и больше не оправдывает команду такого размера. В таком случае команда может сама решить, как ей дальше работать. Это отличный момент для начала использования Kanban (см. главу 20).
✓ Трансфер с целью релиза. Это тот случай, когда вводом в эксплуатацию занимается не Scrum-команда [15].
✓ DevOps – это подход, позволяющий непрерывное развертывание, в рамках которого члены Scrum-команды берут на себя определенные обязанности. Они обычно лежат на специалистах из стадии эксплуатации/технического обслуживания.
Если команда прекращает работу над одним продуктом, она может приступить к другому и, соответственно, новому сезону. Ключевым моментом является устойчивость команды.
Таким образом, постлюдия – это не момент завершения работы над продуктом, а момент, когда команда распадается.
2.6 Антипаттерны
Ситуация: во время спринтов команда делает все возможное, но иногда участники дают понять, что хотят время на передышку между спринтами. Команда говорит, что находится под давлением непрерывающихся спринтов.
Как сделать лучше? В легкой атлетике, если проводить аналогию, невозможно бежать без передышек, спортсменам необходимо время, чтобы восстановить силы.
Давайте не забывать принцип Agile-манифеста об устойчивом ритме.
Что делать? Не думать о Scrum-спринте как о гонке, в которой команда всячески пытается найти секунду, чтобы отдышаться. Спринтуют здесь на самом деле не люди, а элементы бэклога.
Scrum-разработка больше похожа на равномерный бег без ускорений, в одном темпе, без пауз на каждом этапе. Спринты следуют друг за другом, перерыв наступает только в конце сезона.
Рисунок 2.12 – Одышка после тяжелого спринта
Ситуация: по V-модели тестирование – это стадия, выполненная независимыми тестировщиками. При переходе к Scrum эта схема сохраняется, причем, тестировщики смещены на один спринт от разработчиков.
Последствия: поднимается цена исправления ошибки.
Как сделать лучше? В итеративном Scrum-подходе тестирование не происходит после разработки, а внедрено в каждый спринт. Оно не откладывается на конец спринта, команда начинает проводить тесты с первых дней.
Тестирование проводится, скорее, с целью продвижения к цели, чем с целью контроля.
Такой способ позволяет уменьшить время между появлением ошибки в ПО и ее исправлением.
Ситуация. Команда переходит из одного спринта в другой на протяжении нескольких месяцев, а то и нескольких лет.
Последствия. Отсутствие фокуса на среднесрочной цели, усталость, рутина.
Как сделать лучше? Задать и поддерживать сезонный ритм.
Ситуация. Scrum ограничивается разработкой, для всего остального сохраняется традицонная V-модель.
Последствия. Оптимизация является локальной и не отражается в цепочке создания ценности. Scrum теряет смысл.
Как сделать лучше? Расширить место Scrum в системном подходе, описанном в этой книге. Заменить традиционные этапы стадиями исследования и эксплуатации.
3Привести команду к идеалу
В первых трех изданиях не было главы, посвященной команде, хотя я говорил о ней в главе о роли Scrum-мастера и касался этой темы на протяжении всей книги. Однако мне было что сказать по этому вопросу, так как в течение многих лет я был частью или руководил самыми разнообразными командами. Но я считал, что команда сама постоянно развивается и формируется, исходя из опыта каждого ее участника. Мне казалось полезным знакомить читателей только с двумя основными Scrum-ролями: Владельцем продукта и Scrum-мастером. Я не осмеливался копать глубже, вероятно, будучи слишком сконцентрированным на левом полушарии мозга. Сегодня я освободил свое правое полушарие и нашел слова, чтобы рассказать обо всех участниках Scrum.
Важность людей – человеческий фактор – является основным отличием Scrum и Agility. Ни программная инженерия, ни V-цикл, ни UML не придают человеческому фактору столь большую важность. Даже управление проектами и менеджмент недавно осознали ключевую роль людей в проектной работе, да и то чтобы быть в тренде. При этом поразительно, что на конференциях, посвященных Agility, участников больше всего интересуют темы, связанные с людьми. Популярны сессии по социологии отношений. Это соответствует первой ценности Agile-манифеста: