ФИНЭКОСОФТ

Rose Ritchie, Сертифицированный Ведущий Менеджер проектов, IBM
Bernie Michalik, Сертифицированный Ведущий IT Архитектор, IBM

Оригинал статьи: http://www.ibm.com/developerworks/rational/library/may06/ritchie/index.html?S_TACT=105AGX15&S_CMP=EDU

От журнала "The Rational Edge": Часто, разработчики информационных систем, твердо уверенные в правильности применения итеративного подхода в проектах, вынуждены работать с клиентами, которые по разным причинам придерживаются традиционного метода "водопада". Данная статья посвящена вопросу, как помочь таким организациям перейти на методологию Rational Unified Process.

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

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

Несмотря на перечисленные причины, использование Rational Unified Process®, или RUP®, во всех этих проектах имеет больше смысла, чем применение водопада. В каждом случае мы были способны изменить наш план проекта и общий подход с целью адаптации итеративных практик. Эта статья написана на данном опыте, и мы пробежимся по методам, использованным нами при переходе от одного подхода к другому.

Как был сформирован изначальный план и почему именно так?

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

Почему применение RUP имеет больше смысла?

В ряде наших проектов после совместного анализа нашего водопадного плана с клиентами оказалось, что использование RUP-ориентированного плана проекта имело больше смысла, чем использование водопадного плана, по причинам, таким как:

• Клиенты хотели ускоренных результатов. Некоторые клиенты не хотели ждать окончания проектирования для старта самой разработки. Они выявили некоторые требования и стремились продемонстрировать как можно быстрее хотя бы часть работающего приложения своим заказчикам.
• Клиенты не делали или не успевали выявить все высокоуровневые требования перед назначенной датой выпуска первого релиза. Иногда клиент не выявляет все требования перед завершением запланированной фазы проектирования по причине обнаружения конфликтов или других ограничений (т.е. существует подвешенное решение, которое не может быть разрешено в течение еще некоторого времени).
• Клиенты хотели получить более тесную интеграцию временных шкал и текущего состояния бюджета проекта. Несмотря на неопределенность в требованиях и других аспектах проекта, некоторые клиенты хотели получить более управляемый план проекта. Т.к. каждая фаза проекта - это некоторый замкнутый промежуток времени, мы могли точно определять проектное расписание, определять требуемые для фазы ресурсы и, таким образом, предсказывать состояние бюджета проекта на конец каждой фазы.
• Клиенты и разработчики хотели начать заниматься ранним смягчением риска несвоевременной поставки системы. Для некоторых наших клиентов запуск работающего приложения, как можно раньше, помогал снизить риск, что приложение не будет поставлено вовремя. Этим командам разработчиков, старающимся рано развертывать в проекте работающие компоненты приложения, особенно, если компоненты были связаны с новыми технологиями, технология помогала бороться с риском неуспешного выполнения проекта.
• Клиенты хотели иметь возможность сокращать объем работы при уменьшении бюджета проекта. Обеспечивая возможность определения заранее лишь высокоуровневой функциональности в проекте, RUP-подход предоставил бы клиентам гибкость в варьировании содержания проекта в зависимости от текущего состояния его бюджета. В случае же водопадного подхода нам пришлось бы провести громадную работу по проектированию на много релизов вперед, даже если финансирование будет обеспечено только для одного первого релиза.

Что мы изменяли?

При реструктуризации наших проектных планов от водопада в сторону RUP, было несколько направлений, которые мы изменяли:

• Структура проекта. Изменение структуры проекта было ключевым изменением. Мы уходили от водопадных фаз, таких как общее проектирование системы, проектирование релизов, сборка, тестирование, развертывание и т.д. к технологии RUP с множеством повторяющихся итераций в фазе Обработки (Elaboration), за которыми следовало множество итераций в фазе Конструирования (Construction). Итерации повторялись столько раз, сколько требовалось, и все заканчивалось фазой Передачи системы (Transition).
• Временные рамки. Каждая итерация просчитывалась с точки зрения, сколько времени она требовала, еще перед ее стартом. Если мы определяли, что было недостаточно времени в итерациях Обработки и Конструирования для выполнения работ, то мы сдвигали часть этих работ на следующую итерацию. Это отличалось от того, как мы подходили к фазам в водопадных проектах, в которых мы могли расширить фазу для полного завершения проектирования, сборки, тестирования или развертывания.
• Использование ресурсов. При нашем водопадном подходе у нас были ресурсы, которые невозможно было бы использовать в последующих фазах сборки, тестирования и развертывания. При RUP подходе наши ресурсы были задействованы постоянно. А в некоторых проектах у нас был специалист, выполнявший разные роли в различных фазах.

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

Что мы сохраняли?

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

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

Роли и ресурсы. Мы сохраняли те же роли и ресурсы в наших проектах, даже если изменялось содержание проектов. Мы хотели получить аналогичное количество трудоемкости проектирования, разработки и тестирования, которые выполнялись бы теми же группами специалистов. Кроме того, некоторые роли, несвязанные с разработкой приложений (поддержка инфраструктуры) были сохранены.

Артефакты поставки в проектах и другие документы. Ряд документов, которые мы планировали производить в нашем водопадном проекте, мы также планировали выпускать и в нашем RUP проекте. Клиенты все также хотели получить ключевые артефакты (например, основной План тестирования) в независимости от нашего подхода. Иначе говоря, мы выпускали документ, который описывал настройку инфраструктуры в каждом проекте, в частности, как настраивать сервера, программное обеспечение и др. и мы делали это независимо от того, использовали ли мы RUP или водопад.

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

Что получали в результате?

При переходе от водопада к RUP мы нашли, что:

• RUP помогал нам управлять требованиями и достигать результата, даже когда клиенты не знали изначально точно, что же они хотели. Изменения должны были четко управляться и дополнительные фазы добавлялись для аккомодации новых требований. Ограничение рамок проекта по времени (Timeboxing) и множественные итерации помогали нам управлять изменениями. Множественные итерации в фазе Обработки означали, что, если мы не успевали выполнить нашу работу за одну итерацию, то мы могли перенести работу на следующую итерацию, но только в случае, если клиент все еще желал этого. Иначе говоря, если мы обнаруживали в Обработке, что требуется больше работы, чем было запланировано, то мы могли управлять изменениями, сдвигая часть работы на следующую итерацию. Или мы даже могли добавить дополнительные итерации, если клиент чувствовал, что он получит от этого пользу в дальнейшем. Если клиент был ограничен бюджетом, то дополнительные итерации могли быть отменены, т.к. клиент обычно к этому моменту получал многое благодаря уже выполненным итерациям.
• Множественные итерации в фазе Конструирования также помогали при управлении требованиями. Разрабатывая части приложения в итерационной манере, мы могли получать подтверждение от клиентов по реализации требований в каждой итерации. Если приложение не соответствовало ожидаемым запросам, то мы могли внести изменения на следующей итерации. Также это помогало в области управления содержанием проекта (Scope Management).
• RUP помогал нам беспрерывно контролировать качество. Поскольку мы поставляли код в конце каждой итерации, RUP позволял начинать тестирование, как можно раньше, что снижало риск слишком позднего обнаружения основных дефектов в проекте.
• Моделирование визуально помогало клиентам раскрывать, что они хотят, а нам понять эти пожелания. Косвенно, это также помогало нам развивать отношения с нашими клиентами. Они чувствовали себя более вовлеченными и влияющими на направления разработки приложения. А это приносило им комфорт и уверенность, что приложение будет разработано вовремя и будет соответствовать их пожеланиям.
• Использование принципов построения компонентной архитектуры позволяло нам поставлять автономное, функционирующее приложение клиентам для целей раннего тестирования. Это также было полезным, помогая команде разработчиков снижать простои и распределять работу.

Когда необходимо рассматривать применение RUP взамен водопада?

Далее представлены некоторые индикаторы, показывающие, когда необходимо рассматривать возможность применения RUP взамен подхода, основанного на водопаде:

1. Клиент испытывает трудности в различных аспектах водопадного подхода. Например, клиент спорит, что слишком много времени должно пройти, чтобы увидеть хотя бы какой-то результат работы по проектированию. Или клиент высказывает пожелания, что ему необходимо больше гибкости или требуется раннее управление рисками. Или когда клиент хочет увидеть работающие компоненты на ранних стадиях проекта и это не просто прототипы или примеры реализации, а реальный работающий код, который станет частью всего приложения.
2. Клиент использует один или более инструментов Rational в настоящий момент. Если это так, то он уже знаком с пользой от использования средств IBM Rational и подхода, который те приносят. Вы можете убедить клиента, что использование RUP еще больше повысит пользу от применения этих средств.
3. Разработка программного обеспечения является ключевым аспектом проекта и/или программное обеспечение является объектно-ориентированным. Если проект в основном является перепроектированием сетевого или серверного приложения с небольшим количеством программной разработки, возможно, вы получите больше пользы от традиционного водопадного подхода. Иначе говоря, если основная часть разработки будет написанием скриптов или использованием процедурного языка, традиционные методы могут быть достаточными.
4. Клиент заявляет, что у него нет уверенности в части требований. Это может произойти из-за наличия некоторых нерешенных вопросов или если еще не стартовал связанный проект или работа в связанной области. Или есть неопределенность, которая мешает в проекте полностью собрать все требования в течение одной фазы.

В большинстве своем, если ответы на эти вопросы "да", то вы должны рассмотреть использование RUP в проекте.

Что надо делать в первую очередь?

• Обратитесь к эксперту RUP, который сможет помочь вам. Эксперт RUP может помочь при переходе от водопада к RUP. Он имеет опыт в применении RUP и поможет вам идентифицировать и распланировать работу с преодолением любых возможных проблем, связанных с переходом.
• Исследуйте пользу от применения RUP и итеративной разработки. После того, как переход выполнен, вас могут спросить: не является ли это изменением ради самого изменения? Тогда возьмите обучающие материалы по RUP, взвесьте существующие наработки (это другая область, в которой может помочь эксперт RUP) и почитайте статьи, в особенности учебного плана, об успешном внедрении RUP.
• Воспользуйтесь преимуществом интегрированного набора инструментария IBM Rational. База знаний RUP предоставляет руководства по использованию этого инструментария в процессах. Средства Rational и процессы могут быть использованы независимо друг от друга, но когда они используются вместе, то могут стать чрезвычайно мощным фактором при выполнении проекта.
• Адаптируйте лучшие практики RUP и руководствуйтесь духом RUP. Перестройки плана проекта недостаточно. Для успеха необходимо руководствоваться духом RUP и следовать лучшим практикам для достижения наилучшего результата.

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

Заключение

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

Даже при хорошем водопадном плане больше преимуществ можно получить при переходе к плану на основе Rational Unified Process. Для выполнения данного перехода необходимо оценить, являются ли клиент и проект хорошими кандидатами для проведения изменений. В случае хороших кандидатов, перед тем, как проследовать далее, полезно оценить, что следует изменить, а что оставить, как есть. Однако, при рассудительном подходе к изменениям, вы можете столкнуться с проектом, который получает лучшее от обоих вариантов и достигает более высоких результатов.