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

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

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

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

• логики поступательного развития;

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

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

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

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

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

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

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

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

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

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

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