Методологические стратегии

Сужение текущей задачи проекта: итеративное наращивание возможностей

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

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

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

На рис. 5.4 стратегия итеративного наращивания изображена в виде схемы.

Рис. 5.4. Итеративное наращивание возможностей системы

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

При рассмотрении схемы итеративного наращивания возможностей системы легко заметить, что конусы итераций можно, по крайней мере зрительно, представлять как конусы этапов. А нельзя ли в связи с этим считать итеративную стратегию частным случаем последовательной схемы определения этапов, в котором каждый этап есть итерация? Ответ на этот вопрос чаще всего отрицательный. Дело в том, что деление деятельности, которое мы назвали стратегией определения этапов, предполагает цель выполнения, связанную с использованием полученных результатов на следующем этапе. А это условие для итеративного наращивания не всегда выполняется. Но если помимо того, что в ходе итерации готовится релиз системы, она предполагает построение базы для реализации следующей итерации, то рассмотрение итераций как этапов проекта достаточно естественно. Однако остается еще одно отличие: при поэтапном делении проекта обычно цели и содержание всех этапов определяются на ранних стадиях, тогда как итеративное наращивание не связано с этим предположением и, более того, даже количество итераций, не говоря уж об их содержании, не фиксируется заранее.

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