2 Разделение процесса на спринты
Я принял участие в десятках проектов в качестве разработчика или консультанта, и ни один из них не был похож на предыдущий, хотя используемые процессы и методы иногда совпадали.
Проекты по-разному развиваются с течением времени, и у каждого – свой собственный цикл разработки (или жизненный цикл). Цикл составляют стадии и контрольные точки. Стадии следуют друг за другом, а контрольные точки определяют переход к следующему этапу. Стадия преследует определенные цели. Контрольная точка служит для проверки того, что данный набор целей достигнут.
Рисунок 2.1 – В традиционном цикле стадии различаются
2.1 Изменение парадигмы
Течение цикла зависит от используемой модели (или процесса). Во Франции по-прежнему распространена V-модель, но компании, особенно крупные, обычно берут ее за основу для дальнейшей адаптации к их контексту и создания уже своей собственной модели.
В некоторых компаниях применение моделей является не просто рекомендуемым, а обязательным, в то время как в других организациях командам предоставляется больше возможностей.
И все же я часто отмечаю большой разрыв между моделью и ее реализацией в проектах, вне зависимости от того, была она рекомендована или навязана команде.
Этому есть причины:
✓ Модель разработана методологами-теоретиками и оказывается слишком удалена от реальности и неприменима на практике.
✓ Контрольные точки оказываются неэффективными, потому что для осуществления проверок и тестирования необходимо обратиться к огромному множеству документов, некоторые из которых – в сотни страниц.
✓ Команда пропускает контрольные точки – и накапливает работу, не выполненную на предыдущих этапах. Это создает неудобства в дальнейшем.
Все это давно известно.
В начале 1980-х годов была предложена альтернатива итеративной и поэтапной разработке, чтобы избежать подобных ситуаций. Эта идея была реализована частично и без привязки к Agility: одни команды быстро производят прототипы, другие их реализуют.
В то же время возникла противоположная идея индустриализации процессов, и пришлось подождать, пока она провалится на практике.
Scrum и Аgile-методы взяли предшественников за точку отсчета и пошли дальше с моделью цикла разработки, основанной на последовательном повторении одной стадии. В Scrum эта стадия называется спринт.
Спринт с точки зрения времени – повторяющаяся стадия фиксированной продолжительности.
Рисунок 2.2 – Повторение спринта
Все спринты протекают по одной схеме. В этом основное отличие от традиционных подходов, где каждый этап предполагает работу разного характера.
Еще одно фундаментальное отличие заключается в том, что Scrum – это не более чем фреймворк. Он не определяет наполнение каждого спринта: за это отвечает команда.
2.2 Итеративный и инкрементальный подход
Scrum основывается на итеративном и инкрементальном подходе к разработке продукта. Давайте разберемся, что это значит.
Инкрементальная, то есть поэтапная разработка – стратегия, при которой развитие продукта отмечается в конце каждого спринта. Инкрементальный подход позволяет создавать продукт по частям, где каждая новая часть добавляется к предыдущей.
Это контрастирует с традиционным подходом к проекту, где до завершения разработки ничего не готово. Хотя ничего – это тоже неправильно, так как появляются документы, созданные во время промежуточных контрольных точек. Но этого недостаточно, чтобы избежать туннельного эффекта.
Пока я писал эту книгу, использовал инкрементальный подход: сделал изначальный план (в виде карты мыслей), а затем писал главу за главой, не ориентируясь на порядок в плане.
Использование инкрементального подхода широко распространено в компаниях, которые занимаются разработкой продуктов. Часто можно слышать о поставках (то есть, частях системы, или инкрементах), которые значатся в контрактах с клиентами. Обычно такое деление на части носит технический характер, и ничего не работает до момента, когда все инкременты не состыкуются в единое целое.
Рисунок 2.3 – Густав Эйфель, инженер, практиковавший инкрементальный подход
Итерация – это процесс повторения. В математике и физике итерация представляет собой повторяющийся вычислительный процесс, который позволяет, например, решить уравнение путем последовательных приближений.
В сфере разработки ПО термин итерация используется для обозначения периода времени, в течение которого выполняются действия, которые будут повторяться в следующих итерациях. Этот термин часто соотносят с процессом.
Итеративный процесс позволяет проанализировать, что было сделано – с целью дальнейшего улучшения или завершения работы. Он основывается на идее, что трудно (если не невозможно) преуспеть в чем-то с первого раза. Обратная связь, собранная по результатам одной итерации, помогает вносить улучшения в следующую. Итерации прекращаются, когда достигнутый результат оценивается как удовлетворительный.
Пока я писал эту книгу, я также использовал итеративный подход: отправил первый черновик первому рецензенту. Благодаря обратной связи, я выпустил новую, улучшенную версию книги, которую отправил следующему рецензенту, и так далее.
Scrum объединяет оба подхода с концепцией спринта:
✓ в конце спринта появляется инкремент продукта;
✓ обратная связь на этот инкремент позволяет скорректировать цель следующего спринта.
Другими словами, спринт – это итерация, в результате которой появляется новый контент (инкрементальный подход) и улучшается контент, добавленный в предыдущий инкремент (итеративный подход).
Пока я писал эту книгу, я использовал итеративный и инкрементальный подход: не рассылал черновик всей книги своим читателям, но делал это глава за главой. На протяжении какого-то времени я работал над первой версией одной главы одновременно с пересмотром другой главы после получения на нее обратной связи от одного или нескольких читателей.
Ученые знают, как бороться с неопределенностью в сложных задачах при помощи подхода: сначала предлагается гипотеза, затем она проверяется, и после наблюдения за результатом решается, принять ее или отклонить.
По сравнению с простым итеративным подходом, когда запрашивается обратная связь, а затем принимается или отклоняется в соответствии с субъективным суждением, в научном методе все основывается на практической проверке. Если мы используем этот подход для разработки какой-либо функции продукта, наблюдение после эксперимента позволяет либо убедиться в ее ценности и продолжать над ней работать, либо понять, что она не эффективна.
Lean Startup популяризировал эту концепцию тестирования гипотез и коротких спринтов для получения информации о новом продукте. Мы все постоянно слышим термин MVP (Минимальный жизнеспособный продукт, Minimum Viable Product), который, на мой взгляд, плохо отражает его суть. Ведь речь идет не о продукте, пусть даже с минимальным количеством функций, но о результате, который позволяет проверить предположения, и, следовательно, узнать новую информацию.
Если гипотеза не подтверждается, команда переключается на другую функцию продукта.
Достижение MVP соответствует окончанию стадии иследования и началу стадии эксплуатации.
С точки зрения жизненного цикла продукта, Lean Startup используется на стадии исследования, а Scrum – на стадии эксплуатации.
Рисунок 2.4 – Две стадии разработки продукта
Концепция Lean Startup предполагает малозатратный по ресурсам этап проверки гипотезы несколькими конечными пользователями.
Представим, что эта книга была опубликована в Интернете, глава за главой. Я мог бы предположить, что эта глава интересна, ориентируясь на три покупки в течение недели после публикации ее плана. К концу недели я мог бы проверить свою гипотезу, прежде чем приступить к редактированию главы (а так как моя книга опубликована классическим путем, через издательство, я буду опираться на реакцию избранных рецензентов).
На стадии использования также можно использовать данный прием, проверяя на практике гипотезу о части продукта (см. главу о бэклоге).
2.3 Спринт
Помимо итеративного и инкрементального процесса, какие еще можно выделить характеристики Scrum-спринта?
✓ Короткие итерации: продолжительность спринта варьируется от недели до месяца.
✓ Строгая последовательность: спринты не перемешиваются между собой.
✓ Четкий ритм: спринты имеют одинаковую продолжительность.
Рисунок 2.5 – Разница между инкрементальным и Agilе-подходом
Продолжительность спринтов всегда одинакова, что помогает команде держать ритм.
Внимание: надо держать ритм! Это позволяет избежать перегрузки. Необходимо помнить, что команда не сможет перерабатывать очень долго. Заставлять ее выходить за пределы своих возможностей означает снижать качество ее работы и подрывать здоровье ее участников: увеличивается количество ошибок, уменьшается мотивация, инженерные практики пренебрегаются.
Спринт соответствует определенному временному отрезку. После начала спринта команда не может менять дату его окончания, даже если она уже достигла поставленной цели!
Почему так? Такой подход позволяет избежать почти законченного синдрома (минутку, я почти закончил!), из-за которого дата окончания спринта может быть неоднократно отодвинута.
Рисунок 2.6 – Отрезок времени
Помню, как еще до появления Scrum команды договаривались о дате контрольной точки. Когда они решали отложить обзор на два-три дня, по истечении этого срока оказывалось, что им нужно еще немножко времени на работу…
Концепция временных отрезков устраняет любые отсрочки: в запланированную дату команда проводит объективный обзор ее прогресса, а затем корректирует содержание следующих спринтов.
Рисунок 2.7 – Стая слепней помогает отрабатывать спринтерский бег на коротких дистанциях
Когда Scrum только появился, стандартной продолжительностью спринта был один месяц. Теперь видна тенденция сокращения спринтов до двух-трех недель. Если мы говорим о разработке ПО, то инженерные практики – непрерывная интеграция и развертывание – позволяют чаще выпускать новые версии продукта. Время, затраченное на развертывание версии, больше не является проблемой.
Продолжительность спринта кратна неделе: спринт не может длиться 13 или 17 дней. Так намного проще ориентироваться.
По части продолжительности. Здесь нет единого мнения, все зависит от контекста. Но она должна быть четко зафиксирована.
Результаты опроса, проведенного в мае 2015 на странице моего блога, показывают, что чуть меньше половины (44 %) команд проводят спринты продолжительностью в две недели, и почти для четверти (24 %) команд спринты составляют три недели.
Чтобы определить продолжительность спринта, существует несколько критериев, на которые нужно обратить внимание:
✓ Производительность и результативность команды.
✓ Готовность заинтересованных сторон давать обратную связь.
✓ Простота в подготовке событий спринта – спринт предполагает дополнительную работу по организации событий.
✓ Частота изменений – спринт представляет собой период стабильности. Когда начинается спринт, команда не должна отвлекаться на другие вещи, а состав команды не должен меняться. Любые изменения переходят на следующий спринт.
Определение продолжительности спринта является одной из задач начинающей команды (см. главу 13).
Цикл разработки – это последовательность стадий, каждая из которых отмечена определенными процессами. Для разработки программного обеспечения процессы обычно следующие: написание спецификации, архитектура (проектирование), написание кода, тестирование (интеграция и приемка). Для упрощения я буду использовать буквы С, A, К и T соответственно для обозначения этих действий на схемах.
В Scrum каждый спринт заканчивается рабочим результатом. Все процессы проводятся во время одного спринта.
Рисунок 2.8 – Спринты и процессы в параллели
Внутри спринта процесс не последовательный (С, затем A, затем К, затем T). Преобладающая идея – идея непрерывного потока, прерванного только в конце спринта.
Другой вариант – это так называемый последовательный цикл, разворачивающий последовательные процессы, по одному процессу на стадию.
Рисунок 2.9 – Последовательные процессы
При последовательном процессе для каждой стадии определяется цель, сформулированная списком документов к созданию. Стадия длится несколько месяцев, ее продолжительность варьируется: команда останавливается, когда цели достигнуты. Результатом работы считается документация, так как готовый продукт получается только в конце.
Следовать этому подходу буквально означает:
✓ 100 % готовность спецификации до перехода к проектированию.
✓ 100 % готовность проекта до перехода к написанию кода.
✓ 100 % готовность кода до перехода к тестированию.
Это утопичная модель. В реальности команда всегда возвращается к предыдущим стадиям: на стадии тестирования команда возвращается к написанию спецификации – и так далее.
Такое различие между моделью и ситуацией в реальной жизни является одной из причин неудач проектов по V-модели и получаемых в их результате продуктов среднего качества.
Agile-подход более прагматичен: работа над спецификацией и проектированием непрерывна. Архитектура развивается с новыми функциями.
На другом полюсе последовательного подхода есть команды, которые не ищут легких путей: в их разработке нет стадии написания спецификации или проектирования. Они сразу приступают к написанию кода, затем следует длительный период тестирования и исправления ошибок.
Scrum в этом плане сильно отличается. Здесь качество играет важную роль, и тестирование является частью каждого спринта. Для разработки программного обеспечения крайне важно проводить тестирование параллельно с написанием кода, чтобы как можно скорее обнаружить аномалии. Это также позволяет понять, есть ли необходимость в упрощении, если тестирование кажется слишком сложным.
Опытная Agile-команда в каждом спринте проводит 100 % тестов до того, как будет написано 100 % кода, и достигает 100 % готовности кода до того, как на 100 % написана спецификация.
2.4 Результат спринта
Начнем с того, что определим смысл терминов, которые будем в дальнейшем использовать.
✓ Ввод в эксплуатацию – это создание ценности путем предоставления пользователям версии продукта [14].
✓ Развертывание – это установка версии с целью получения какой-либо информации. Для ввода продукта в эксплуатацию необходимо его развертывание, в то время как для развертывания можно не вводить в эксплуатацию.
✓ В конце каждого спринта команда получает результат спринта.
Руководство по Scrum называет результат спринта потенциально готовым к поставке инкрементом. Это выражение часто неправильно понимают: инкремент – это не всегда продукт. В Scrum 3.0 речь просто о результатах спринта, и я буду придерживаться того же мнения.
✓ Почему речь не о продукте? Как мы увидим в следующей главе, структурирующим элементом является скорее команда, чем продукт. Команда может работать над несколькими продуктами, последовательно или одновременно.
Что насчет спринта? Включает ли последовательность процессов поставку конечным пользователям? Другими словами, всегда ли конец спринта соответствует вводу в эксплуатацию? Или для этого нужно ждать несколько спринтов?
Цель состоит в быстром предоставлении ценности. Решение о вводе в эксплуатацию основано на данной цели и не всегда совпадает с окончанием спринта. Это может быть во время спринта для одной команды или после нескольких спринтов для другой команды.
Ввод в эксплуатацию делается как можно раньше, чтобы поскорее предоставить ценность пользователям. Он не обязательно совпадает с концом спринта.
Течение и результат спринта, как правило, облегчают принятие решения. Например, в конце данного спринта принимается бизнес-решение о вводе в эксплуатацию в рамках следующего спринта.
Таким образом, ввод в эксплуатацию не связан со спринтом.
Что делать с результатом спринта, если не вводить его в эксплуатацию для конечных пользователей? Можно направить его заинтересованным сторонам для осуществления следующих целей (впрочем, эти варианты не единственные):