Эта статья в действительности представляет собой подборку из трех статей и содержит проверенные рекомендации по применению динамичных (aglie) стратегий в рабочих группах, использующих унифицированный процесс Rational (IBM Rational Unified Process или RUP).
Дисциплинируем жизненный цикл динамичной (agile) разработки
Марк Лайнс
Динамичные проекты могут иметь бесконечное число итераций и заканчиваться только вследствие израсходования бюджета. Причинами этого часто оказываются реализация окончательной отделки функций на ранних итерациях и необоснованное изменение требований. RUP структурирует динамичный подход к разработке посредством концентрации на устранении неопределенности требований и естественного усиления контроля за процессом по мере того как проект приближается к завершению.
Я заметил в проектах динамичной разработки одну нежелательную тенденцию - проекты проходили итерацию за итерацией, и этому не было видно конца. Некоторые проект-менеджеры как будто забывают о принципе жесткого руководства и руководствуются принципом динамичной разработки "клиент всегда прав". Это приводит к непрерывному изменению требований от итерации к итерации. Часто, как только рабочие элементы, например, требования изымаются из стека реализации на текущей итерации, в стек тут же добавляется такое же или большее количество рабочих элементов. Время и деньги быстро расходуются, оставляя большое количество требований, которые необходимо выполнить.
Истинное значение RUP в таких ситуациях заключается в том, чтобы помочь рабочим группам понять, что не все итерации одинаковы. Уокер Ройс (Walker Royce) писал, что жизненный цикл проекта состоит из двух стадий 2. Первая стадия, составляющая приблизительно первые 20-40% жизненного цикла, называется стадией Проектирования (Engineering). Эта стадия складывается из Начальной фазы и фазы Уточнения унифицированного процесса (UP), которые в свою очередь можно разбить на несколько итераций. Стадия Проектирования характеризуется значительной неустойчивостью в отношении всех аспектов проекта - планов, требований, архитектуры и программного кода. Это естественно и ожидаемо, поскольку заинтересованные лица от бизнеса и техники стремятся понять, что представляет собой решение системы и как его реализовать.
Вторую стадию жизненного цикла Ройс описывает как стадию Производства, которая охватывает фазы Конструирования и Передачи жизненного цикла UP. Эта стадия характеризуется реализацией остальных (примерно 60-80%) требований при помощи проверенных методов, утвержденных на ранних итерациях стадии Проектирования.
Адаптируемая жесткость в управлении изменениями по ходу выполнения проекта
В ходе стадии Проектирования мы стараемся избегать обременения пользователей процедурами управления изменениями. Они, в свою очередь, не должны ожидать четкого распределения обязанностей до реализации рабочей группой части требований, что позволит получить базовую линию показателей, от которых можно экстраполировать некоторые четко определенные обязанности. С учетом этого поведения допустимо (в разумных пределах) добавлять, изменять и переопределять приоритеты требований в стеке на ранних итерациях, которые пользователи оценивают как подготовительные.
Создавая в фазе Уточнения приращения функциональности, связанной с аспектами риска для данного программного обеспечения, мы сможем избавиться от большей части неопределенности, связанной, например, с осмыслением и утверждением требований. Риски, связанные с неопределенностью требований, снижаются при помощи таких методов как прототипирование, раскадровка, визуальное моделирование и регулярные демонстрации работоспособных приращений программного обеспечения заинтересованным сторонам проекта. По завершении этой стадии обычно предполагается предоставление обязательств в отношении объема проекта и выполнения графика. Хорошая новость об этом подходе - пользователям предлагают отчитаться о выполнении требований гораздо позже, чем в традиционном каскадном проекте. До того как мы обяжем их более жестко соблюдать процедуры управления изменениями или, как называет их Скотт Амблер, процедуры "предотвращения изменений", у них будет время начать работу и понаблюдать, как развивается создаваемое ими программное обеспечение.
Плохая новость заключается в том, что в какой-то момент нам все же придется усилить жесткость управления изменениями. Вряд ли будет разумным ожидать от рабочей группы поставки IT-проекта выполнения обязательств в отношении бюджета и графика, если объем требований постоянно изменяется.
Я советовал рабочим группам считать фазу Уточнения проекта временем для изучения и экспериментов. Для IT-специалистов это время выяснить, что можно сделать и как это можно сделать. Кроме того, для пользователей самое время выяснить, чего конкретно они хотят.
По завершении учебно-испытательной фазы Уточнения мы переходим к Производственной стадии проекта. В этот момент проект-менеджерам необходимо ужесточить управление изменениями, в противном случае они рискуют невыполнением обязательств рабочей группы по поставке. На рисунке 1 показан этот аспект ужесточения управления процессом. Обратите внимание, что кривая жесткости управления изменениями не обязательно должна в фазе Конструирования стремиться вверх так быстро, как показано на этой схеме. Это зависит от уникальных особенностей вашей организации и проекта. Для пользователей, работающих по договору, возможно, будет необходимо учредить жесткие процедуры управления изменениями в начале фазы Конструирования. Если у вас более доверительные отношения с вашими пользователями, то можно отложить ужесточение процедур управления процессом на конец фазы Конструирования, при этом кривая жесткости управления изменениями переместится вправо.
Рисунок 1. Жесткость процедур управления изменениями усиливается по мере выполнения проекта
Ключ к успеху - обучение заинтересованных сторон
К сожалению, многие менеджеры проектов "динамичного RUP" никак не изменяют своего поведения, т. е. определяют соответствующие ожидаемые результаты по мере перехода от итерации к итерации в ходе жизненного цикла.
Пользователей часто не инструктируют по поводу смещения акцента между фазами унифицированного процесса, которые, как любит говорить Гари Эванс (Gary Evans), по сути, представляют собой времена года проекта. Они видят, что им предоставлена существенная свобода в отношении изменений на ранних этапах проекта, и, конечно, предполагают, что так будет на всем протяжении жизненного цикла проекта. Не раз мне пришлось стать свидетелем того как демонстрации результатов заинтересованным сторонам по окончании итерации на позднем этапе проекта, предусмотренные для демонстрации прогресса выполнения перед переходом к реализации новых требований, превращались в совещания по выявлению новых требований. Иногда проект-менеджеры уходят с такого совещания с большим количеством требований, добавленных в объем незавершенной работы, чем было реализовано в ходе текущей итерации. Это может быть весьма неприятным событием.
Складывается впечатление, что многие проект-менеджеры, которые прошли обучение методам динамичной разработки без связи с унифицированным процессом, не вполне понимают необходимость в ужесточении процедур управления изменениями по мере выполнения проекта. Они одинаково управляют всеми итерациями и не определяют ожидаемые результаты правильно, т.е. вместе с пользователями.
Прошедшие обучение пользователи и аналитики понимают, что устранение неопределенности требований в первой половине проекта - это их долг, потому что изменения требований во второй половине жизненного цикла могут потребовать более жестких процедур управления изменениями.
Мне часто задают вопрос, в какой момент необходимо закрепить требования и формализовать процедуры запросов на изменения. Гибкости RUP больше соответствует ответ "по обстоятельствам". В идеале, в среде, где практикуются принципы сотрудничества, ответом будет "никогда". Для отношений, связанных с работой по договору, нам понадобится более формальный подход. Несмотря на все наши усилия, требования не будут вполне детализированы в конце фазы Уточнения и обязательно будут изменяться в фазе Конструирования. Я рекомендую проект-менеджерам приготовить на всякий случай запас родственных функциональных элементов, которые можно будет использовать, если в стек требований в фазе Конструирования будут добавлены новые требования. Этот подход соответствует способу, которым я проиллюстрировал постепенное усиление строгости управления изменениями на рисунке 1. В двух первых двух итерациях фазы Конструирования мы можем освободить пользователей от более жестких процедур управления изменениями, позволив им добавлять новые задания до тех пор, пока они не исчерпают свой запас элементов, приготовленных на случай непредвиденных обстоятельств.
Итак, мне приходилось видеть проекты, на которые были потрачены буквально миллионы долларов, прежде чем в конце концов становилось ясно, что они все еще далеки от создания решения, которое изначально планировалось. Причина заключается в неэффективном управлении процессом на поздних стадиях жизненного цикла, а также в том, что коллектив не учитывал первоначальное представление о проекте, а концентрировался только на нуждах текущей итерации. Запомните: в отличие от чистой методологии динамичной разработки в RUP каждую итерацию следует считать не такой, как другие. Если нам нужно добиться успеха, то на всем протяжении жизненного цикла необходимо использовать адаптивный стиль управления проектом.
Стратегии, позволяющие сделать процесс RUP в крупных организациях более динамичным
Джошуа Барнс
Более крупные организации, которые используют RUP, как правило сначала концентрируются на своих самых общих типах проектов (это более крупные проекты в смысле продолжительности, уровня использования ресурсов, соответствия бюджету, критичности для бизнеса и т.п.). Такие более крупные типы проектов часто попадают в поле зрения законодательных инициатив, таких как законы Сарбейнса-Оксли или Cobit 4.0. Такая жесткость процесса часто является частью его жизненного цикла независимо от того, создает ли он экономическую ценность или просто поглощает время и средства. На ранних этапах внедрения RUP такие крупные проекты не позволяют оптимизировать процесс и сделать его более динамичным вследствие серьезных ограничений, которые на него налагаются. Поэтому вопрос "Как можно сделать процесс для наших проектов более динамичным" мне часто задают на более поздних стадиях.
Мне известно, что крупные организации имеют такие участки работы как внутренний аудит, внешний аудит и руководство/соблюдение законодательных требований (это лишь часть из них), для которых можно было бы использовать менее масштабные и менее формальные версии процесса. Часто нелегко договориться о создании более динамичной версии "стандартного" процесса, кроме того, при таком соглашении ограничиваются типы работ, при выполнении которых разрешается его использовать. Обычно используется определенное пороговое значение, например, работы, не превышающие "X часов" или "Y долларов бюджета".
Если вы получили согласие на начало работ по созданию динамичной версии стандартного процесса, можно считать, что день прошел не зря. Эти небольшие объемы работ могут стать пилотным вариантом динамичного процесса, который вы решите ввести во всей организации Можно ожидать, что после того как ценность динамичного подхода подтвердится, можно будет включить полученный опыт в более крупные проекты, использующие "стандартный" процесс. Ниже описываются три проблемы, с которыми мне чаще всего приходилось сталкиваться после того, как разрешение на начало работ было получено:
- Неизвестно, с чего начать
- Слишком многочисленная рабочая группа
- Рабочей группе не хватает опыта.
Проблема №1. Неизвестно, с чего начать
Вам не нужно изобретать колесо или давать новое название уже существующему процессу. На рисунке 2 процесс изображен в виде континуума, на одном конце которого находится надежная и традиционная версия RUP, адаптированная для организации, а на другом конце - почти полное отсутствие процесса (процесс используется от случая к случаю)
Рисунок 2. Поиск равновесия между динамичностью и дисциплиной
Начните с существующей адаптированной версии RUP для крупных проектов, поскольку это самая надежная и структурированная версия. Затем рассмотрите менее масштабные версии RUP, например, OpenUP как минимальную версию полного процесса разработки программного обеспечения для небольших коллективов. Ваша цель - устранить ненужные издержки нединамичной версии и оптимизировать процесс для менее многочисленных коллективов и объемов работ. Стремитесь двигаться от правого конца континуума, изображенного на рисунке 2, к левому концу в направлении "чистого agile-процесса". В поисках равновесия между динамичностью и дисциплиной перемещайтесь влево по этому континууму, пока не достигнете точки, в которой риск для проекта превысит допустимый уровень.
Первые шаги, которые делали клиенты под моим руководством, выглядели аналогично стратегии первичной реализации RUP: проанализировать, что будет работать без предварительной адаптации, что потребует настройки, а от чего можно отказаться, потому что оно ничего не добавляет к процессу 3. Проанализируйте существующие роли, задачи и продукты и откажитесь от всего лишнего. Помните, что эти компоненты процесса могут быть снова добавлены в процесс рабочими группами, которым они могут понадобиться. Проанализируйте остальные задачи и продукты, чтобы понять, как должны выглядеть их упрощенные версии. Учтите, что процесс не должен быть трудоемким и длительным, наша цель - получить упрощенную и облегченную схему первоначального процесса и проверить принятые решения на реальных заданиях. Закончив теоретическую часть работы, уточните и пересмотрите свой процесс, исходя из практических результатов.
Проблема №2. Слишком многочисленная рабочая группа
Я часто сталкиваюсь с ситуациями, в которых специально для получения полного согласия по поводу процесса во всей организации формируется рабочая группа, планируются совещания, определяются контрольные точки. Это вряд ли можно назвать динамичным подходом, если не сказать больше. Хотя такой вариант подхода может быть типичным для корпоративной культуры крупных компаний, он далек от оптимального; поэтому рекомендуется по мере возможности избегать этого анти-паттерна. Но что еще хуже, такая рабочая группа часто разрастается до слишком больших размеров, поскольку в ней обязательно должен быть представлен каждый участок работы, который может потенциально потребовать использования новой схемы процесса. Это приводит к образованию раздутой рабочей группы, в которой вряд ли можно прийти к согласию по какому-либо вопросу. Каждый заявляет: "все мы разные", а все, что обсуждается, "у нас работать не будет", если не будут внесены различные изменения.
Подход, который всегда оказывался эффективным у разных клиентов, заключается в том, что в проекте выявляются участки, имеющие большой процент заданий по этой "менее масштабной" категории. У одного из клиентов имелся участок разработки, который был сосредоточен исключительно на внешнем интерфейсе Web-приложения, который часто требовал небольших обновлений через очень короткие промежутки времени. Они очень хотели ввести упрощенный процесс и охотно соглашались участвовать в совместной работе по определению схемы минимального процесса, который можно было бы использовать, не подвергая недопустимому риску свои проекты. Работая с этими клиентами, мы за несколько недель смогли создать упрощенную и более динамичную версию стандартного процесса, которую они потом использовали в качестве пилотного проекта. Этот процесс в первом приближении не был тем, что в конце концов будет использоваться во всей организации, но он стал для нас отправной точкой, предоставив реальные результаты, которые оказались ценными. В этом подходе мы сразу отказались от попыток "построить мир во всем мире", которые, скорее всего, закончились бы непрерывной серией совещаний и переговоров, результатом которых стали бы только сами переговоры.
Проблема № 3. Рабочей группе не хватает недавнего практического опыта
Представители компании, которых обычно назначают на этот участок работ, обычно занимают должности проект-менеджера или руководителя. Эти руководящие работники имеют обширный опыт работы, что само по себе замечательно. Однако в большинстве случаев они никогда не занимались практической разработкой программного обеспечения в течение хоть сколько-нибудь длительного времени. Часто их должностные обязанности заключались в том, чтобы посещать совещания, представляя на них свой функциональный участок работы, и отчитываться о проделанной работе, рисках и проблемах.
В результате на то, что могло бы быть сделано за несколько недель, требуются многие месяцы работы. Поскольку у них нет опыта использования существующего процесса, каждую отдельную небольшую деталь приходится обсуждать до тошноты, прежде чем можно будет прийти к какому-нибудь решению. Конечный результат как правило представляет собой слегка упрощенную версию стандартного процесса с небольшой разницей, которую вряд ли почувствуют рабочие группы, использующие процесс на практике. Мне приходилось видеть, как этот подход стоил компаниям больших денег, хотя давал очень небольшую прибыль использующим его специалистам.
Рабочая группа, которая будет заниматься созданием менее масштабной и более динамичной версии RUP, должна состоять из специалистов, имеющих практический опыт использования стандартной версии RUP, принятой в вашей организации, в реальных проектах. Эти специалисты должны испытывать неудобства из-за того, что процесс, который можно было бы использовать для создания работоспособных приложений высокого качества для заинтересованных сторон, недостаточно оптимизирован. В процессе работы с последним клиентом мы смогли выбрать несколько сотрудников рабочей группы проекта, ранее участвовавших в проектах внедрения первоначального процесса RUP, и использовать их в качестве отраслевых экспертов на рабочем месте. Они рассказали нам, что при реальном применении процесс был переполнен непроизводительными издержками, в которых буквально утопали небольшие участки работ. Некоторые из первоначальных препятствий, которые воздвигали представители компании, занимавшиеся внутренним аудитом и соответствием законодательным нормам, были впоследствии преодолены. Одно дело - абстрактное обсуждение проблем, и совсем другое - работа с людьми, которые испытывают раздражение от проблем, с которыми они сталкиваются изо дня в день; в этом случае создать теоретическое решение может быть действительно трудно.
Мы рассмотрели только три часто возникающие проблемы, с которыми я сталкивался у клиентов, пытающихся сделать более динамичной свою стандартную версию RUP. Более подробно о трудностях, с которыми я сталкивался, работая над решением/предотвращением этих трех (и других) проблем, я расскажу в следующих статьях.
Джулиан Холмс
Многие из динамичных и итеративных методов разработки программного обеспечения требуют от проектной группы совместной работы на всех практических участках. Такая совместная работа особенно важна, если речь идет о практике итеративного планирования и разработки и о ситуациях, в которых динамичная рабочая группа минимизирует объем используемой документации с целью сделать более эффективным общение между своими членами.
Территориально не рассредоточенные рабочие группы, использующие ежедневные совещания по ходу работы и непрерывную интеграцию выполненных заданий, обычно добиваются больших успехов в непрерывной поставке экономической ценности клиентам, чем территориально рассредоточенные рабочие группы; причина такого успеха заключается в более эффективной совместной работе членов таких рабочих групп.
Однако различные бизнес-стратегии и давление обстоятельств могут привести к тому, что организация не сможет собрать своих сотрудников в одном подразделении для всех проектов. В качестве примеров таких "реалий" бизнеса можно привести следующие факторы:
- Ограничения на офисные площади для каждого проекта
- Необходимые специалисты отсутствуют в месте работы над проектом
- Клиенты находятся далеко от места работы над проектом
- Стратегии аутсорсинга, использующие сторонних поставщиков для определенных наборов квалификаций
- Стратегии аутсорсинга, распределяющие роли проекта между ближними и удаленными рабочими подразделениями
- И многие другие...
Каким образом организация, которая реализует потенциал совместной работы в форме динамичных методов, может сохранить эти преимущества в том случае, если коллектив становится рассредоточенным? Этот вопрос особенно уместен потому, что анкетирование по вопросу о внедрении динамичного принципа разработки в 2007 году (2007 Agile Adoption Survey), предпринятое журналом Dr. Dobb's Journal 4 выявило, что некоторые организации, пытавшиеся ввести динамичный подход к разработке в рассредоточенных коллективах, добились некоторого успеха, но показатели успешности были ниже по сравнению с нерассредоточенными коллективами.
Динамичные методы позволяют использовать превосходно структурированные подходы к работе, которая должна выполняться в рамках проекта разработки программного обеспечения. Однако чтобы обеспечить выполнение реальных заданий по разработке программного обеспечения согласованным и обеспечивающим высокое качество образом, почти все они зависят от опыта и эффективности совместной работы в рабочей группе. Как только рабочая группа становится рассредоточенной, согласованное использование подхода к разработке, поставке или даже к взаимодействию деятельностей и промежуточных продуктов становится все большей проблемой для коллектива.
Было установлено, что большинство проблем, с которыми сталкиваются эти коллективы, связаны с трудностями организации совместной работы в рассредоточенных коллективах. Среди основных проблем можно назвать три:
- Как разработать культуру совместной работы в коллективе?
- Как сохранить согласованный подход к разработке и поставке?
- Как управлять разработкой совместно используемых промежуточных продуктов?
Разработка культуры совместной работы в коллективе
Собрав весь коллектив рабочей группы проекта в одном месте, мы, безусловно, стимулируем совместную работу, но для сотрудников рассредоточенной рабочей группы может оказаться совсем непростым делом даже просто почувствовать себя одной командой.
В этом случае может помочь использование инструментов. Само собой разумеющимися являются общение через программы обмена мгновенными сообщениями, аудио- и видеоконференции и виртуальные рабочие места. Однако даже наличие этих инструментов может не представлять особой ценности, пока люди на разных концах провода не почувствуют себя комфортабельно в общении с другими людьми.
Все мы знаем, насколько проще разговаривать с кем-либо по телефону, если ранее мы уже встречались с этим человеком и установили какие-то отношения. То же самое можно сказать и о других только что упомянутых инструментах общения; все это наводит на мысль об использовании не такого очевидного "инструмента общения" - какого-либо средства передвижения, которое позволило бы членам коллектива организовать личную встречу.
Хотя организация путешествий на большие расстояния может слишком дорого обойтись в отношении времени и бюджета, мы можем получить существенные преимущества от установления более эффективного общения, доверия и обмена опытом. Однако ежедневные поездки из удаленного подразделения и обратно вряд ли можно назвать правильным решением, поэтому придется поискать золотую середину.
Поддержание согласованности подхода к разработке и поставке
При наличии рабочей группы с эффективной моделью совместной работы и культурой эффективного общения для выполнения работ по проекту придется преодолеть еще одну проблему. Хотя ценность "отдельных сотрудников и взаимодействий с процессами и инструментами" для динамичных рабочих групп чрезвычайно важна, утвержденный процесс и согласованная инфраструктура языка процесса может действительно помочь обеспечить поддержку отдельных специалистов и взаимодействий в ситуации с рассредоточенной рабочей группой.
RUP представляет собой инфраструктуру процесса языка разработки программного обеспечения, стандартную нотацию унифицированного языка моделирования (Unified Modeling Language, UML) и способ ознакомления всех членов рабочей группы проекта с выбранными для реализации проекта методами. При отсутствии общего языка разработки программного обеспечения локальные варианты использования терминов или описаний деятельностей, промежуточных продуктов или ролей могут привести к значительной путанице в отношении обязанностей и к тому, что сотрудники, работающие в разных территориальных подразделениях, будут ожидать, что работа будет выполнена кем-то другим. Именно по этой причине многие организации решают вложить деньги в обучение своих сотрудников, чтобы предоставить им такой общий язык. Этого можно добиться несколькими способами, и результаты тоже будут разными.
Обычное обучение может познакомить пользователей с основами языка и нотации, но не обязательно научит их эффективно им пользоваться и общаться с его помощью. Дополнительные стандарты и шаблоны, которые надо использовать и которым надо следовать, могут обеспечить согласованность, но вряд ли будут способствовать эффективному взаимодействию.
Гораздо лучше, если в проекте будет участвовать куратор процесса, стимулирующий взаимодействия между всеми сотрудниками при помощи общего языка, который легко смогут понять и интерпретировать все заинтересованные стороны и наблюдатели проекта. Куратор также поможет адаптировать базовый процесс к потребностям проекта и согласовать его с остальной организацией.
Итак, если мы используем какой-либо базовый процесс типа RUP, его необходимо адаптировать к рабочей среде. Это достигается посредством документирования согласованного подхода в документе "Описание процесса разработки RUP". А при помощи инструмента IBM Rational Method Composer можно дать такой адаптации процесса формальное описание и опубликовать его в формате HTML, чтобы все члены рабочей группы могли обращаться к нему в процессе выполнения своей роли.
Управление разработкой совместно используемых промежуточных продуктов
Хотя определение процесса вместе с общим языком и подходом, который он привносит в разработку программного обеспечения, может помочь в распределении деятельностей между членами рассредоточенного коллектива, масштаб и сложность работы, которую необходимо для этого выполнить, все еще могут быть чрезмерными. Особенно это относится к случаям, когда сотрудникам рассредоточенного коллектива приходится совместно использовать и параллельно работать с одними и теми же промежуточными продуктами.
Неспособность коллектива осуществлять пересмотр таких промежуточных продуктов и совместно работать над их разработкой в режиме реального времени может также привести к снижению качества и более медленному выполнению проекта. Рабочая группа должна найти способы обеспечения доступности результатов своей работы для всех членов коллектива в любой момент времени. Некоторых людей может раздражать необходимость открывать доступ к своей работе до окончания разработки, но если рабочей группе приходится совместно работать, обеспечивать качество и следить за быстрым выполнением работы, то это - единственно возможный способ.
Один из самых простых способов добиться этого - создание общего репозитория файлов, в который каждый сотрудник регулярно будет загружать свою работу и предоставлять общий доступ к ней всему коллективу. Безусловно, этот репозиторий необходимо хорошо структурировать и обслуживать, но это приучит специалистов участвовать в совместной работе. Однако заставлять специалиста выполнять отдельные действия по публикации своей работы после того как он потратил время на ее разработку - это уже слишком, поэтому люди, естественно, не захотят согласиться с этим. Рекомендуется применить более разумный подход, связанный с использованием инструментария. Это одна из ситуаций, в которых решения IBM Rational обеспечивают превосходную поддержку территориально рассредоточенных коллективов. Для примера можно привести следующие варианты:
- IBM Rational ClearCase и IBM Rational ClearQuest - репозитории управления конфигурациями и изменениями, которые можно распределить между несколькими подразделениями или организовать доступ к ним через HTTP, чтобы обеспечить каждому сотруднику рабочей группы доступ ко всем промежуточным продуктам и основаниям для их создания и пересмотра.
- IBM Rational Software Modeler и IBM Rational Software Architect - документирование UML-диаграмм в одной модели, полностью интегрированной с ClearCase, для обеспечения возможности параллельной распределенной работы над одним набором моделей.
- IBM Rational RequisitePro - управление требованиями к проекту в общем репозитории с обеспечением трассируемости до моделей и с доступом через IDE Eclipse или HTTP-клиент.
Указанные решения уже известны, но помимо них, в рамках совместного проекта IBM Research и IBM Rational под названием Jazz, разрабатывались новые решения для территориально рассредоточенных коллективов. Первый продукт проекта Jazz, IBM Rational Team Concert, предоставляет механизм управления промежуточными продуктами проекта через решение для управления конфигурациями и изменениями в распределенной среде разработки. Однако в Rational Team Concert, кроме того, описанная функциональность интегрируется с инструментами общения, интегрированными инструментами поддержки процесса и исполнения процесса в соответствии с подходом, документированным в Rational Method Composer.
Динамичный, распределенный, но все-таки RUP
Установив необходимость в процессе и инструментах для поддержки территориально рассредоточенных, но динамичных (использующих agile-принцип) рабочих групп, мы оставляем без ответа важный вопрос: могут ли затраты на приобретение этих решений, потенциальные непроизводительные издержки по проекту при их использовании и риски для совместной работы по проекту, и, следовательно, для успешной поставки, перевесить бизнес-причины, заставляющие отказаться от использования рассредоточенных коллективов?
Часто ответом будет "да", потому что затраты на размещение всей рабочей группы в одном месте и связанные с этим проблемы слишком велики (если ответ "нет", то необходимо серьезно подумать о внесении изменений в схему бизнеса!). Поэтому, большинству организаций определенно поможет описанная выше комбинация процесса и инструментальных решений.
Мысли на прощание
Многие организации по всему миру используют динамичный подход к RUP, и три статьи, которые мы предложили вашему вниманию, помогают понять, как это нужно делать. Хотя многие представители сообщества сторонников динамичного подхода к разработке программного обеспечения ни за что не согласятся с этим, именно RUP сделал популярными многие концепции, которые они считают даром свыше, например, итеративная разработка, поставка работоспособного программного обеспечения по завершении каждой итерации, тестирование на всем протяжении жизненного цикла и многое другое. Кроме того, RUP решает весь спектр проблем разработки, включая не слишком привлекательные, например, те, которые приходится решать при разработке систем в масштабе. RUP при правильном применении представляет собой динамичный подход к разработке, а динамичный подход к разработке при правильном применении представляет собой... RUP?