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 - Также используется английское слово «release» – Прим. авт.].
? Развертывание – это установка версии с целью получения какой-либо информации. Для ввода продукта в эксплуатацию необходимо его развертывание, в то время как для развертывания можно не вводить в эксплуатацию.
? В конце каждого спринта команда получает результат спринта.
Руководство по Scrum называет результат спринта потенциально готовым к поставке инкрементом. Это выражение часто неправильно понимают: инкремент – это не всегда продукт. В Scrum 3.0 речь просто о результатах спринта, и я буду придерживаться того же мнения.
? Почему речь не о продукте? Как мы увидим в следующей главе, структурирующим элементом является скорее команда, чем продукт. Команда может работать над несколькими продуктами, последовательно или одновременно.
2.4.2 Спринт и ввод в эксплуатацию
Что насчет спринта? Включает ли последовательность процессов поставку конечным пользователям? Другими словами, всегда ли конец спринта соответствует вводу в эксплуатацию? Или для этого нужно ждать несколько спринтов?
Цель состоит в быстром предоставлении ценности. Решение о вводе в эксплуатацию основано на данной цели и не всегда совпадает с окончанием спринта. Это может быть во время спринта для одной команды или после нескольких спринтов для другой команды.
Ввод в эксплуатацию делается как можно раньше, чтобы поскорее предоставить ценность пользователям. Он не обязательно совпадает с концом спринта.
Течение и результат спринта, как правило, облегчают принятие решения. Например, в конце данного спринта принимается бизнес-решение о вводе в эксплуатацию в рамках следующего спринта.
Таким образом, ввод в эксплуатацию не связан со спринтом.
2.4.3 Спринт и развертывание
Что делать с результатом спринта, если не вводить его в эксплуатацию для конечных пользователей? Можно направить его заинтересованным сторонам для осуществления следующих целей (впрочем, эти варианты не единственные):
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию (https://www.litres.ru/pages/biblio_book/?art=66624184&lfrom=174836202) на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
notes
Примечания
1
См. раздел 1.2.5 – Прим. ред.
2
Блог автора можно найти по адресу: http://www.aubryconseil.com/pages/Livre-Scrum. Все материалы на нем представлены на французском языке. – Прим. ред.
3
В переводе: «софт пожирает мир», известная цитата Марка Андриссена, американского изобретателя, инвестора, основателя Netscape Communications и венчурного фонда Andreessen Horowitz. – Прим. ред.
4
Пермакультура (от англ. permaculture – permanent agriculture – «Постоянное сельское хозяйство») – подход к проектированию окружающего пространства и система ведения сельского хозяйства, основанные на взаимосвязях из естественных экосистем. – Прим. ред.
5
Ориг. назв.: Exploring Scrum, The Fundamentals. – Прим. ред.
6
3Back, Scrum3.0, Web, 2017. https://3back.com/scrum30/ – Прим. авт.
7
Kanban появился среди Agile-методов совсем недавно; на самом же деле Lean Software, где зародился Kanban, опирался на фундамент, заложенный еще производственной системой заводов Toyota в 1950-х годах. – Прим. авт.
8
Kanban также не является Agile-методом, это скорее метод улучшения процесса или метод управления потоком. В конце концов, остается только Экстремальное Программирование, которое можно назвать методом. – Прим. авт.
9
Как и не стоит обращаться к Scrum, чтобы войти в Agile-режим. – Прим. авт.
10
