Модель процессов msf

Предложение Microsoft Solutions Framework, касающееся жизненно­го цикла [44], исходит из идеи механического «скрещивания» каскадной модели MSF (мы ее подробно обсуждали в лекции 7) и самой примитив­ной спиралевидной модели (подобной спирали охвата предметной облас­ти — см. лекцию 8). По мнению авторов, модель процессов MSF (см. рис 11.2) «объединяет в себе лучшие принципы каскадной и спиральной мо­делей. Она сохраняет преимущества упорядоченности каскадной модели, не теряя при этом гибкости и творческой ориентации модели спираль­ной, учитывает необходимость постоянного пересмотра, уточнения и оценки проектных требований, стимулирует активное взаимодействие между проектной группой и заказчиком, который оценивает ход и резуль­таты работы на протяжении всего проекта».

К сожалению, авторы предложения MSF не совсем точны в своих оценках модели. Как и в случае с RUP, в этой модели очевидно стремле­ние к универсальности, которое неизбежно приводит к огрублению си­туации в конкретных случаях и к необходимости словесного дополне­ния схемы. Недостатки моделей, основанных на раскручивающейся

спирали (см. лекцию 10), присущи ей в полной мере: невозможность от­слеживания временных соотношений между сроками выполнения ра­бот, трудности дополнения специфичных этапов. К тому же ориентация на всеобщность лишает модель и тех преимуществ, которые демонстри­рует, например, модель Боэма, снабженная конкретным механизмом интерпретации.

Если обратиться к процессам, которые отражают модель MSF, т.е. к их отдельному описанию, то становится заметным стремление авторов сделать методологию гибкой. К примеру, вот что они пишут о сотрудни­честве с заказчиком: «Вовлечение заказчика в проект является необходи­мым условием успешности проектов. Модель процессов MSF предостав­ляет заказчику широкий спектр возможностей для уточнения и модифи­кации проектных требований и установки контрольных точек (вех) для мониторинга работы над проектом. В свою очередь, это требует затрат времени со стороны заказчика и взятия им на себя определенных обяза­тельств». Однако далее говорится о том, что «MSF признает первостепен­ную важность договорных и юридических отношений между заказчиком, его поставщиками и проектной командой и необходимость управления этими отношениями». (Стоит сопоставить эти высказывания с соответст­вующим принципом Agile Manifesto [31] — см. лекцию 5.) Только из схе­мы ни первое, ни второе утверждение извлечь нельзя. И это пример сло­весного дополнения, к которому приходится прибегать при неудовлетво­рительном схематическом представлении модели.

Изучение методологии, провозглашаемой MSF, позволяет сделать вывод о том, что ее авторы достаточно тщательно проработали процессы менеджмента, когда основой организации коллектива разработчиков считается проектная группа с рассредоточенными ролями (мы об этом уже говорили в лекции 2). Но опять-таки в модели жизненного цикла это обстоятельство никак не отражено, что вполне объяснимо стремлением к всеобщности. Отсюда следует, что обсуждаемое предложение всегда в конкретных проектах должно адаптироваться. Сделать это проще, чем, к примеру, в случае RUP или жестких схем, которые только и допускает стандарт СММ [18]. Однако до уровня стратегии быстрого развития пред­ложения MSF не доходят и занимают промежуточное положение между жесткими и гибкими методологиями.

Жизненный цикл в методологиях быстрого развития проектов

Как утверждают сторонники быстрого развития, их методологии не нуждаются в том, чтобы четко фиксировать этапы развития разработки программного проекта (см., например, [3]). Однако они понимают, что само понятие жизненного цикла полезно для представления процесса разра­ботки в концептуальном плане. Что же касается деятельности менеджера, то в этом подходе в противовес жестким методологиям провозглашаются самодисциплина и сотрудничество вместо дисциплины и подчинения; планирование, контрольные и другие функции носят здесь такой харак­тер, который позволяет менеджеру в большей мере сосредоточиться на ру­ководстве командой, чем на управлении. В результате отслеживание про­цесса не требует, к примеру, специальных документов о достигнутых ре­зультатах и проблемах, для которых нужна специальная поддержка. По этой причине модели жизненного цикла быстрого развития не претенду­ют на инструментальность, и в таком ключе их рассматривать не имеет смысла. Тем не менее понятия контрольных точек и контрольных меро­приятий, распределения ресурсов, оценки остаются, хотя их содержание становится менее формализованным.

Жизненный цикл любой методологии быстрого развития можно описать следующим образом.

• Начальная фаза. Она выделена, поскольку приходится выполнять работы, которые не являются характерными для основного процесса.

• Серия максимально коротких итерации, состоящих из шагов:

• выбор реализуемых требований (в экстремальном программиро­вании — пользовательских историй);

• реализация только отобранных требований;

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

• короткий период оценки достигнутого (в зависимости от объема работ периода его можно назвать этапом или контрольным ме­роприятием).

• Фаза заключительной оценки разработки проекта.

Реальные быстрые методологии конкретизируют эту схему, допол­няют ее теми или иными методиками (пример того, как это делается в экстремальном программировании [3], будет рассмотрен ниже).

До последнего времени быстрые процессы было не принято формализовывать настолько, чтобы их можно было предлагать в качестве стан­дарта. И сегодня не приходится говорить, например, о сертифицирова­нии команды как «правильно» работающей по быстрой методологии, по­добном тому, что требует СММ. Тем не менее вопрос о сертификации бы­строго процесса приобретает актуальность — складывается своеобразная мода на гибкие методологии, отрицательно сказывающаяся на престиже подхода в целом. Стремление к сертификации сдвигает границу между гибкими и жесткими методологиями в сторону последних, и есть опасе­ния, что в результате быстрые подходы станут формализованными до та­кой степени, что их нельзя уже будет называть гибкими. Эта проблема от­мечалась во многих докладах на недавней конференции сторонников обсуждаемого подхода Extreme Programming and Agile Methods — XP/Agile Universe 2003 [37].

Тем не менее сегодня уже появилась компания, выполняющая проек­ты по методологии экстремального программирования, которая получила сертификат по одному из общепризнанных стандартов ISO 9001:2000 [39], свидетельствующий об определенных гарантиях качества организации про­ектной деятельности и получаемых результатов. Это произошло весной 2003 года по прошествии примерно года с момента подачи заявки на сертифика­цию [51]. Все, что для этого потребовалось сделать, свелось к приведению соответствия между процессами экстремального программирования и под­держиваемыми стандартом. В остальном процедура сертификации не нару­шила процессы производства программ в компании. Не потребовалось ни­какой настройки процесса, доведения его до требований стандарта. Не пре­терпела изменений база данных, в которой сохранялись пользовательские истории со сведениями о работе с ними. Документация, предназначенная для пользователей, построенная на базе априорного тестирования (см. лек­цию 2), признана соответствующей требованиям качества и т.д.*.

В последующих разделах мы конкретизируем общую для быстрых методологий схему на примере двух характерных подходов к разработке программных систем.

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

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

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

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

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

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

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

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

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

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

Адаптивная разработка (ASD) по Хайсмиту

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

Основу ASD составляют три нелинейные, перекрывающие друг дру­га фазы: обдумывание, сотрудничество и обучение, относящиеся к каждому периоду разработки, который завершается выпуском релиза (см. рис. 11.4). Подчеркивается, что планирование в окружении, которое требует адаптивности, является парадоксом, поскольку результаты в этом случае всегда непредсказуемы. При обычном планировании отклонения от пла­на являются ошибками, которые нужно исправлять. В адаптивных разра­ботках отклонения ведут к решениям, которые объективно обусловлены, а потому их следует считать правильными.

Неопределенность в столь непредсказуемой среде преодолевается за счет активного сотрудничества разработчиков. При этом внимание руко­водства направлено не столько на объяснения, что именно нужно делать, сколько на обеспечение коммуникации, при которой разработчики сами находят ответы на возникающие вопросы. Отсюда следует повышенное внимание к обучению, значение которого в предсказуемых методологиях часто занижается: все расписывается заранее, так что потом остается толь­ко следовать плану. Хайсмит пишет [41], что «... в адаптивном окружении обучения не избежать всем участникам проекта — и разработчикам, и их заказчикам, поскольку и те и другие в процессе работы должны пересмат­ривать собственные обязательства, а также использовать итоги каждого цикла разработки для того, чтобы подготовиться к следующему».

Из этого положения делается вывод, относящийся к жизненному циклу адаптивных разработок [41]: «Основное, наиболее действенное и первостепенное достоинство жизненного цикла ASD заключается в том, что этот процесс заставляет отказаться от интеллектуальных построений, которые являются источником самообмана. Он вынуждает оценивать собственные способности более реалистично».

Из приведенной схемы не ясно, как предлагается организовывать процесс, как компенсировать потенциально «расползающуюся» разра­ботку, когда по мере развития она обрастает все новыми возможностями, обусловленными практическими нуждами, но без общей (в других подхо­дах сказали бы — предсказуемой) архитектурной базы. Оставив все это в стороне, т.е. относя подобные вопросы к конкретной методологии, автор ASD освещает сложные моменты адаптивных разработок, в частности во­просы обеспечения сотрудничества и обучения во время реализации про­екта. И в этом ценность работы Хайсмита, поскольку полученные резуль­таты применимы в самых разных случаях.

Таким образом, можно сказать, что ASP — это не готовая методоло­гия, а базовая концепция для различных адаптивных разработок. Схема жизненного цикла не является сдерживавшим фактором построения конкретных методологий, которые вполне могут следовать самым разно­образным стратегиям, включать в себя те или иные методики. В этом от­ношении подход Хайсмита сближается еще с одной «серийной» методо­логией быстрого развития, предложенной А. Коуберном. Речь идет о се­мействе методологий Crystal [36]. Коуберн называет это семейством, так как убежден, что разным проектам нужны разные методологии. Он вво­дит следующую градацию проектов: по одной оси откладывается количе­ство занятых в проекте людей, по другой — критичность ошибок. Каждая из методологий семейства предназначена длЯ определенной ячейки полу­чившейся сетки. Таким образом, проект, в котором занято 40 человек, и на котором компания может позволить себе потерять некоторую сумму, будет работать по другой методологии, нежели проект для шести разра­ботчиков, от которого зависит существование компании.