OpenUP - это просто

Comments

Примечание автора: статья посвящается Брайану Лаойнсу (Brian Lyons), специалисту по OpenUP в проекте EPF, соучредителю, генеральному директору и техническому директору компании Number Six Software, погибшему в дорожно-транспортном происшествии в День труда. Дополнительную информацию можно найти на Web-странице http://www.eclipse.org/epf/general/blyons_tribute.php

illustrationПару лет назад несколько сотрудников нашей компании1, в том числе и я, начали думать о создании облегченной версии унифицированного процесса IBM Rational® (Rational Unified Process®, или RUP).®,2 которая отражала бы подход гибкой разработки в использовании RUP, и в то же время использовала бы все преимущества других процессов гибкой разработки, например, Scrum3 и XP.4 Мы начали эту работу в IBM, но скоро поняли, что нам необходимы опыт и знания более обширной группы специалистов.

Работа была объединена с работой по Eclipse в рамках проекта Eclipse Process Framework (EPF)5, после чего мы продолжили разработку процесса в группе, состоящей примерно из двадцати специалистов из двенадцати компаний. Одни из нас создавали agile-реализации (реализации с использованием методик гибкой разработки) RUP, другие работали в консультационных советах по методам разработки динамических систем (Dynamic System Development Method, DSDM)6 или в области технологии Agile Model Driven Development (AMDD);7 третьи практиковали процесс Scrum8. При этом все отмечали, что по большей части совместная работа была очень успешной, за небольшими расхождениями по поводу методов разработки программного обеспечения, которые многими воспринимаются по-разному. Мы решили не разрабатывать новый процесс с нуля, а постарались собрать и обобщить работу множества людей и многие процессы.

В прошлом месяце мы, наконец, выпустили OpenUP 1.0.9 Однако данный релиз OpenUP - это не конечный продукт, а всего лишь первая из будущих версий развивающегося OpenUP. По мере того, как мы будем узнавать о том, что в OpenUP работает и что не работает, технология будет развиваться и дальше, и мы приглашаем вас принять участие в совместной разработке OpenUP через проект EPF.

В этой статье я объясняю основы OpenUP. Я передал оригинальную версию этой статьи в проект EPF, после чего она была дополнена и улучшена многими членами проекта EPF. Я хочу выразить особую благодарность Брайану Лайонсу (Brian Lyons), Нейту Остеру (Nate Oster)и Лиз Кэррол (Liz Carroll) из компании Number Six Software за их помощь в написании этой статьи. Мои личные наблюдения и комментарии приводятся по ходу статьи во врезках, они отражают мою точку зрения на данный обзор OpenUP, причем комментарии предназначены именно для специалистов, которые уже заинтересовались RUP.

Что дает нам OpenUP?

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

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

Figure shows relationship of micro-increments to the iteration and project lifecycles

Figure shows relationship of micro-increments to the iteration and project lifecycles

Рисунок 1. Уровни OpenUP: микрошаги, жизненный цикл итерации и жизненный цикл проекта

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

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

Жизненный цикл итерации:

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

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

По мере того, как проект проходит через фазы своего жизненный цикл, итерации проходят через свои жизненные циклы с различным направлением концентрации усилий коллектива в зависимости от того, находитесь ли вы на первой или последней неделе итерации (см. рисунок 2 ниже10). Итерация начинается с совещания, посвященного планированию итерации, которое продолжается около нескольких часов. В первые день или два основное внимание, как правило, уделяется дальнейшему планированию и архитектуре, чтобы, среди прочего, оценить зависимости и логический порядок элементов работы и влияние производимой работы на архитектуру. Большая часть времени в процессе итерации отводится на выполнение микрошагов. На выходе каждого микрошага должен генерироваться код для сборки, а также проверенные артефакты. Чтобы еще больше усилить дисциплину, стабильные сборки создаются в конце каждой недели. В этих сборках особое внимание уделяется поддержанию качества и разрешению проблем на ранних стадиях, поэтому успешное завершение итерации не подвергается риску. В последнюю неделю или последние несколько дней окончательной шлифовке и исправлению дефектов уделяют больше внимания, чем в предыдущие недели, даже если при необходимости в код добавляются новые функциональные возможности. Цель - не допустить снижения качества и тем самым гарантировать, что по завершении данной итерации будет создан качественный, пригодный к использованию промежуточный продукт. Итерация завершается оценкой (вместе с заинтересованными лицами) созданного продукта и ретроспективным анализом, позволяющим понять, как улучшить процесс перед следующей итерацией.

Figure shows change of emphasis over course of project, from early planning to later stabilization

Figure shows change of emphasis over course of project, from early planning to later stabilization

Рисунок 2. Итерация проходит через жизненный цикл с большим вниманием к планированию и архитектуре на ранних этапах и к исправлению дефектов и стабилизации продукта ближе к окончанию.

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

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

  • "Прозрачность и ответственность являются критически важными понятиями для обеспечения коллективного общения и выявления лучших качеств в членах коллектива. Открытое обсуждение обязанностей членов коллектива в связи с жизненным циклом итерации и личная ответственность, связанная с микрошагами, гарантирует своевременное выявление проблем и обдуманное выделение специалистов для их решения.
  • "Для того, чтобы помочь коллективу наладить самоорганизацию и устранить препятствия для успеха, необходим инструктаж. Предполагается, что инструктором будет руководитель проекта. Для этого ему придется отказаться от директивно-контролирующего стиля управления в пользу тренирующего стиля. Хотя это стало основной рекомендацией в книгах по управлению, выпущенных в последние два десятилетия, но некоторые руководители проектов до сих пор могут испытывать трудности с переходом к этому стилю".

Микрошаги

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

Микрошаги должны быть хорошо определены; у вас должна быть возможность отслеживать ежедневный ход выполнения каждого микрошага. Микрошаги определяются и отслеживаются по элементам работы. Набор изменений представляет собой физический результат в виде файлов, измененных в ходе выполнения данного элемента работы. Давайте рассмотрим несколько примеров микрошагов:

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

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

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

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

Жизненный цикл проекта

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

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

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

  • Начальная фаза. Согласованы ли масштаб и задачи проекта; следует ли продолжить работу над проектом?
  • Фаза уточнения. Согласована ли архитектура исполнения, которая будет использоваться для разработки приложения? Являются ли созданная на данный момент потребительская ценность и риск приемлемыми?
  • Фаза конструирования. Получили ли мы достаточно близкое к завершению приложение; можно ли переключить внимание коллектива на настройку, окончательную отделку и обеспечение гарантии успешного развертывания?
  • Фаза передачи. Готово ли приложение к выпуску?

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

Одной из задач жизненного цикла проекта является концентрация внимания на двух мотивах заинтересованных лиц: снижении риска и создании потребительской ценности. Фазы OpenUP нацеливают рабочую группу на снижение риска в соответствии с ответами на вопросы в конце каждой фазы с одновременным отслеживанием процесса создания потребительской ценности, как показано на рисунке 3.

Figure shows risk reduction and value increase over course of project

Figure shows risk reduction and value increase over course of project

Рисунок 3. Снижение риска (красная кривая) и создание потребительской ценности (зеленая кривая) на протяжении жизненного цикла проекта

Риск - это выражение вероятности возникновения непредвиденных событий в ходе выполнения проекта; риск препятствует созданию потребительской ценности. Размер риска прямо пропорционален неточности предварительной оценки, при этом заинтересованные лица обычно хотят узнать, какую потребительскую ценность сможет поставить проект за оговоренное время, как можно раньше. Во многих случаях риск будет ниже, если потребительская ценность создается путем реализации и тестирования большей части критически важных функций. Тем не менее, возможны ситуации, в которых снижение риска и создание промежуточной потребительской ценности дополняют друг друга. Рассмотрим пример. По окончании фазы уточнения необходимо снизить технические риски, насколько это возможно, и представить на рассмотрение стабильную архитектуру. Члены рабочей группы должны показать, что у них есть выполнимая архитектура с несколькими готовыми к выполнению избранными сценариями и со списком рисков, в котором отражено понижение многих ключевых технических и прочих рисков. Необходимо найти равновесие между снижением рисков и потребительской ценностью исполняемого кода. То, что для одного проекта будет искомым равновесием, для другого проекта может оказаться неприемлемым.

Влияние Eclipse Way, XP и RUP на OpenUP

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

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

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

Посредством добавления подключаемых модулей можно создавать расширения процесса OpenUP, предназначенные для решения различных вопросов разработки, например, сервис-ориентированной архитектуры (service-oriented architecture, SOA), территориальной рассредоточенности, управляемой моделями разработки и встраиваемых систем. В процесс можно добавить справку по конкретным технологиям, например, руководство по Java 2 Enterprise Edition (J2EE), и различные инструменты для разработки. Одни из расширений могут иметь весьма специализированное назначение, например, добавлять к процессу всего лишь справку по конкретному инструменту для решения имеющихся задач, а другие могут быть достаточно сложными и создавать процессы, существенно расширяющие масштаб проектов при помощи новых или модифицированных артефактов, задач или ролей.

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

Расширения OpenUP могут:

  • Использоваться в пределах организации;
  • Предоставляться в качестве открытого исходного кода в составе проекта EPF;
  • Распространяться свободно вне сферы действия открытых лицензий Eclipse (EPL, см. http://www.eclipse.org/legal/epl-v10.html);
  • Распространяться на коммерческой основе.

Примечания

1 Предшественник OpenUP, Basic Unified Process (Базовый унифицированный процесс), первоначально был разработан Брюсом Маклсааком (Bruce MacIsaac), Рикардо Балдуино (Ricardo Balduino) и Пером Кроллом (Per Kroll).

2http://www.ibm.com/software/awdtools/rup/

3http://www.scrumalliance.org/

4 Бек К. (Beck, K.), Андрес С. (Andres, C). Extreme Programming Explained: Embrace Change (Экстремальное программирование), 2-е издание, издательство Addison Wesley, 2005 г..

5http://www.eclipse.org/epf/

6 Консорциум DSDM, спецификация DSDM. См. http://www.dsdm.org/products/

7 Амблер С. (Ambler, S.W.) The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.(Object Primer, 3 издание: гибкая управляемая моделями разработка при помощи UML 2). Издательство Addison Wesley, 2006 г..

8 Описание Eclipse Way можно найти, помимо других источников, на Web-сайте JAZZ Project: http://www.jazz.net

9http://www.eclipse.org/epf/downloads/openup/openup_downloads.php

10 См. также http://Jazz.net для доступа к Eclipse Way.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Rational
ArticleID=299257
ArticleTitle=OpenUP - это просто
publish-date=04032008