Модели жизненного цикла в некоторых реальных методологиях программирования

Модель жизненного цикла экстремального программирования

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

увеличить изображение
Рис. 11.3. Модель жизненного цикла в экстремальном программировании

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

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

Как только в проекте исчерпывается постоянно пополняемый пул заказываемых для реализации пользовательских историй, исчезает стимул для развития проекта. Эту ситуацию Бек называет смертью проекта. Со смертью проекта использование построенной системы не прекращается. Напротив, отсутствие новых требований к ней свидетельствует о том, что пользовательские нужды обеспечены адекватной поддержкой. Но возможны и другие, менее оптимистичные причины для "смерти". Это либо переход пользователей к применению конкурирующей разработки, которая оказалась более подходящей, либо невозможность в разумные сроки реализовать необходимые возможности системы (по сути дела, обе причины означают одно и то же). Во всех случаях смерть проекта надо достойно встретить. Соответствующие работы указаны на схеме.

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

Отметим, что с точностью до 12 методик, которые объявляются Беком как суть подхода, [3] при изучении этой методологии вполне применимы общие понятия, рассмотренные раньше. Так, деятельность менеджера экстремального проекта в полной мере иллюстрирует следование принципу выяснения отклонений и корректировки траектории (см. лекцию 5).

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