Все о SCRUM. Изучение, разработка, интеграция

2.3 Спринт

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 % написана спецификация.

2.4 Результат спринта

2.4.1 Несколько дефиниций

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

✓ Ввод в эксплуатацию – это создание ценности путем предоставления пользователям версии продукта ^[14].

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

✓ В конце каждого спринта команда получает результат спринта.

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

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

2.4.2 Спринт и ввод в эксплуатацию

Что насчет спринта? Включает ли последовательность процессов поставку конечным пользователям? Другими словами, всегда ли конец спринта соответствует вводу в эксплуатацию? Или для этого нужно ждать несколько спринтов?

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

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

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

Таким образом, ввод в эксплуатацию не связан со спринтом.

2.4.3 Спринт и развертывание

Что делать с результатом спринта, если не вводить его в эксплуатацию для конечных пользователей? Можно направить его заинтересованным сторонам для осуществления следующих целей (впрочем, эти варианты не единственные):

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

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

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

2.5 Все о спринтах

2.5.1 В ритме сериала

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

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

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

Я рекомендую фиксировать сезон по продолжительности, как и спринт. Другими словами, все сезоны одинаковы по времени. Мы вернемся к этому в главе 16.

Как и в спринте, команда сама определяет продолжительность сезона.

Рисунок 2.10 – Релиз заменен сезоном. Наблюдается сопротивление переменам.

Паттерн сезонного ритма состоит в ритмичном делении периода разработки на отрезки по 3 месяца, в которые проходят спринты.

Оказывается, в этом может помочь деление времени на триместры. Посчитаем: триместр длится около 13 недель.

✓ Команда проводит двухнедельные спринты, выходит 6 спринтов за сезон, плюс остается неделя, о которой мы скоро поговорим.

✓ Команда проводит трехнедельные спринты, у нее выходит 4 спринта за сезон.

Цикл спринтов может продолжаться в течение длительного времени, например, нескольких сезонов. Есть также предпремьерный сезон, конец сезона и пост-финальный сезон.

Рисунок 2.11 – Спринты и сезоны

2.5.2 Предпремьера: прелюдия

Период до начала спринтов составляет прелюдию.

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

Прелюдии посвящена целая глава (см. главу 13), мы к ней вернемся, когда познакомимся со всеми элементами Scrum.

2.5.3 Интерлюдия в конце сезона

Так как сезонов будет несколько, интерлюдия тоже будет не одна.

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

Зачем? Чтобы провести на другой скорости цикл инспекции/адаптации, который бы охватывал более устойчивые темы, чем те, что были в фокусе спринта.

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

Вот несколько вариантов того, чем можно заняться во время интерлюдии:

✓ празднование успеха команды,

✓ ретроспектива, посвященная окончившемуся сезону (см. главы 12 и 22),

✓ небольшое увеличение команды (см. главу 3),

✓ чистка бэклога (см. главу 8),

✓ прогнозы на следующий сезон (см. главу 16),

✓ открытый форум по вопросам Agility (см. главу 22),

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

2.5.4 Постлюдия по окончании сезонов

Существует ли последний сезон?

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

✓ Трансфер c целью техобслуживания. Обычно ввод в эксплуатацию выполняется после разработки и другой командой. В некоторых организациях разработкой и обслуживанием занимаются разные люди. В Agile-подходе такого разделения нет. Те, кто занимается разработкой продукта, знают лучше остальных, как оказывать поддержку, исправлять ошибки и дальше его развивать. Следует помнить: в отличие от концепции проекта, цикл спринтов не заканчивается на первой версии. Он продолжается на протяжении всей жизни продукта, который развивается по мере релизов. Можно также сказать, что обслуживание начинается после первого ввода в эксплуатацию. Тем не менее, в жизни продукта может наступить момент, когда поток входных данных уменьшается и больше не оправдывает команду такого размера. В таком случае команда может сама решить, как ей дальше работать. Это отличный момент для начала использования Kanban (см. главу 20).

✓ Трансфер с целью релиза. Это тот случай, когда вводом в эксплуатацию занимается не Scrum-команда ^[15].

✓ DevOps – это подход, позволяющий непрерывное развертывание, в рамках которого члены Scrum-команды берут на себя определенные обязанности. Они обычно лежат на специалистах из стадии эксплуатации/технического обслуживания.

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

Таким образом, постлюдия – это не момент завершения работы над продуктом, а момент, когда команда распадается.

2.6 Антипаттерны

2.6.1 Адский ритм

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

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

Давайте не забывать принцип Agile-манифеста об устойчивом ритме.

Что делать? Не думать о Scrum-спринте как о гонке, в которой команда всячески пытается найти секунду, чтобы отдышаться. Спринтуют здесь на самом деле не люди, а элементы бэклога.

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

Рисунок 2.12 – Одышка после тяжелого спринта

2.6.2 Смещенная стадия тестирования

Ситуация: по V-модели тестирование – это стадия, выполненная независимыми тестировщиками. При переходе к Scrum эта схема сохраняется, причем, тестировщики смещены на один спринт от разработчиков.

Последствия: поднимается цена исправления ошибки.

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

Тестирование проводится, скорее, с целью продвижения к цели, чем с целью контроля.

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

2.6.3 Бесконечные спринты

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

Последствия. Отсутствие фокуса на среднесрочной цели, усталость, рутина.

Как сделать лучше? Задать и поддерживать сезонный ритм.

2.6.4 Цикл по V-модели

Ситуация. Scrum ограничивается разработкой, для всего остального сохраняется традицонная V-модель.

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

Как сделать лучше? Расширить место Scrum в системном подходе, описанном в этой книге. Заменить традиционные этапы стадиями исследования и эксплуатации.

3
Привести команду к идеалу

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

Важность людей – человеческий фактор – является основным отличием Scrum и Agility. Ни программная инженерия, ни V-цикл, ни UML не придают человеческому фактору столь большую важность. Даже управление проектами и менеджмент недавно осознали ключевую роль людей в проектной работе, да и то чтобы быть в тренде. При этом поразительно, что на конференциях, посвященных Agility, участников больше всего интересуют темы, связанные с людьми. Популярны сессии по социологии отношений. Это соответствует первой ценности Agile-манифеста:

Люди и взаимодействие важнее процессов и инструментов.

3.1 Экосистема Scrum

Сердце Scrum – это люди, которые составляют команду и находятся в постоянном взаимодействии. Но чтобы внедрить Scrum-подход, одной команды недостаточно.

Помимо команды есть те, кто интересуется достигнутыми результатами.

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

Все они – часть одной экосистемы.

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

Экосистема Scrum включает команду, результаты ее работы на основе бэклога, всех, кто заинтересован в этих результатах.

Рисунок 3.1 – Экосистема

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

Экосистема также касается рабочего пространства, в котором работают команда и заинтересованные стороны.

3.2 Смена парадигмы

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

В Scrum-командах люди – не взаимозаменяемые ресурсы.

Менеджмент не ликвидирован: он стал делом каждого. Эта парадигма не уникальна в Scrum, она является частью гораздо более широкого движения, ставящего под сомнение тейлоризм ^[16] и его принципы.

Scrum поддерживает образ живой системы, а не машины, состоящей из взаимозаменяемых шестеренок.

Такой образ строится на самоорганизации и общих ценностях.

3.2.1 Самоорганизация

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

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

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

3.2.2 Общие ценности

Scrum поддерживает пять ценностей: решимость, уважение, приверженность, открытость и рассудительность.

Рисунок 3.2 – РУПОР Scrum

Следует отметить, что эти ценности появились только в версии Руководства по Scrum от 2016 года, и это изменение – единственное между версиями 2013 и 2016 годов (пр. пер: в оригинале получается аббревиатура FORCE, то есть сила).

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

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

Решимость, уважение, приверженность, открытоть и рассудительность, больше юмора – и вперед! Эти ценности не являются прерогативой Scrum-команд (я перечислил их в своей речи на свадьбе моей дочери). Но вместе они образуют единое целое, усиливая друг друга.

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

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