Читать книгу Agile. Практическое руководство - Коллектив авторов - Страница 17
3. Выбор жизненного цикла
3.1 Характеристики жизненных циклов проектов
3.1.10 Гибридные жизненные циклы как способ обеспечения целевой пригодности
ОглавлениеКоманда проекта может создать гибридный жизненный цикл с учетом имеющихся в проекте рисков. Например, проект строительства кампуса может предусматривать реконструкцию и возведение нескольких зданий. При инкрементном подходе ресурсы были бы распределены так, чтобы завершение работ по некоторым зданиям произошло раньше, чем по другим, чтобы ускорить окупаемость инвестиций. Вероятно, то, что каждая отдельная поставка для данного конкретного здания выиграет в случае использования предиктивного жизненного цикла, достаточно хорошо известно.
Цель управления проектом состоит в создании бизнес-ценности наилучшим возможным способом при данных конкретных обстоятельствах. Не имеет значения, является ли этот способ agile или предиктивным. Вопрос, на который нужно ответить, состоит в следующем: «Как мы можем добиться наибольшего успеха?»
Требуется ли обратная связь в процессе создания командой ценности? Если «да», задачу поможет решить инкрементный подход. Есть ли необходимость в управлении рисками в ходе исследования идей? Если «да», задачу лучше решать с помощью итерационного подхода или подхода agile.
В случаях, когда организация не может поставить промежуточную ценность, она, вероятно, не сможет использовать подходы agile. И в этом нет ничего плохого: цель состоит не в том, чтобы использовать подходы agile сами по себе. Главное – выбрать жизненный цикл или комбинацию жизненных циклов, которые подходят для проекта, учитывают риски и культуру.
Суть подхода agile состоит в обеспечении частых поставок с учетом пожеланий заказчика. Такая поставка обеспечивает команде обратную связь. Команда использует обратную связь при разработке и пересмотре планов следующей части работы.
Государственное ведомство занималось проектом разработки приложения кредитного страхования. Задача этого многолетнего проекта состояла в замене устаревающей системы страхования новой, имеющей более эффективный пользовательский интерфейс и элементы системной интеграции. Основная часть проекта осуществлялась с использованием подхода agile на основе непрерывного поступления предложений и замечаний от бизнеса.
Расчеты ставок страховой премии были представлены Организацией экономического сотрудничества и развития (ОЭСР) в спецификации объемом 200 страниц. Было дано совершенно четкое разъяснение шагов, практически исключающее возможность ошибочного понимания (или подтверждения промежуточного результата бизнесом), программирование которых произвела отдельная команда, работавшая над шагами расчета самостоятельно. Две команды совместно работали над необходимыми для расчета входными переменными и тем, как потреблять и выводить на дисплей выходные значения, но в остальном занимавшаяся расчетами команда работала преимущественно в предиктивном порядке.
После завершения части работы, которую выполняла занимавшаяся расчетами команда, выходные данные расчета ставок премии были показаны на экранах и в отчетах. Затем бизнес-пользователи по каналам обратной связи сообщили свое мнение о внешнем виде и использовании этой информации. Обе команды работали параллельно, но у них практически не возникало необходимости во взаимодействии. То, что они физически находились рядом друг с другом, делало задачу отслеживания хода разработки проще, но, по большому счету, это были два отдельных подпроекта.