Концептуальная база проекта как основа его развития

Планирование релизов

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

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

Таким образом, план релизов строится исходя из двух, возможно, противоречивых устремлений:

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

Следовательно, план выпуска релизов должен составляться менеджером при тесном контакте с системным архитектором, с одной стороны, а с другой — в ходе содержательного обсуждения с заказчиком. В частности, выделение ближайшей задачи проекта (см. лекцию 9) — это не что иное, как планирование первого релиза разрабатываемой системы. И этот релиз не должен противоречить логике развития.

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

Из этого следует, что план выпуска релизов должен составляться и утверждаться как можно раньше. Фактически все обязательные предпроектные работы (составление документов о концепции развития проекта и распределении ресурсов, построение плана-графика работ) исходят из пользовательского представления процесса разработки как последовательности поставок — релизов проектируемого изделия. В частности, при составлении плана выпуска релизов и его согласовании выясняется, какие решения неприемлемы для компании и для заказчика. Если проблемы окажутся неразрешимыми, то это свидетельствует о том, что от заказа придется отказаться, и чем раньше выяснятся подобные обстоятельства, тем менее болезненным будет разрыв отношений со всех точек зрения.

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

При первоначальном составлении плана релизов не стоит стараться слишком детализировать его этапы, если нет четких критериев, когда должен окончиться один этап и начаться другой. Вместо этого проект просто разбивается на 6–8-недельные итерации каждого релиза, исходя из возможностей реализации требуемых функций. Вопрос о том, какие функции к какой итерации должны быть отнесены, решается на основе принципа: ближе к началу проекта относят в первую очередь наиболее приоритетные функции, во вторую очередь — более простые для реализации функции. Последнее делается с целью оставить разработчикам время для более полного изучения предметной области в ходе подготовки первого релиза, а также для решения организационных вопросов. Подробное обсуждение этого вопроса представлено при изложении критериев предпочтения в разделе "Модификация модели фазы—функции" лекции 9.

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

1. Разбиение этапа — выделение в нем той части, которая может быть выполнена на данной итерации, и перенесение остального на другие итерации. Это делается, когда трудности возникают с реализацией высокоуровневых требований, от которых многое зависит;
2. Сдвиг работ — перенос запаздывающего рабочего продукта на следующую итерацию с сохранением даты окончания итерации. Этот прием применяется для требований с низким приоритетом, а также на ранних итерациях, разгрузка которых позволяет потратить освобождающееся у разработчиков время на дополнительное изучение предметной области;
3. Перераспределение работ — ускорение работ за счет привлечения к проекту дополнительных ресурсов (как правило, кадровых) с сохранением даты окончания итерации и запланированного объема работ. Этот прием можно применять для рабочих продуктов, которые поддаются декомпозиции на части, допускающие раздельное выполнение. Разумеется, он лишен смысла, если менеджер не располагает резервными ресурсами.

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