Примечание автора: статья посвящается Брайану Лаойнсу (Brian Lyons), специалисту по OpenUP в проекте EPF, соучредителю, генеральному директору и техническому директору компании Number Six Software, погибшему в дорожно-транспортном происшествии в День труда. Дополнительную информацию можно найти на Web-странице http://www.eclipse.org/epf/general/blyons_tribute.php
Пару лет назад несколько сотрудников нашей компании 1 , в том числе и я, начали думать о создании облегченной версии унифицированного процесса IBM Rational® (Rational Unified Process®, или RUP).®, 2 которая отражала бы подход гибкой разработки в использовании RUP, и в то же время использовала бы все преимущества других процессов гибкой разработки, например, Scrum 3 и XP. 4 Мы начали эту работу в IBM, но скоро поняли, что нам необходимы опыт и знания более обширной группы специалистов.
Работа была объединена с работой по Eclipse в рамках проекта Eclipse Process Framework (EPF) 5 , после чего мы продолжили разработку процесса в группе, состоящей примерно из двадцати специалистов из двенадцати компаний. Одни из нас создавали agile-реализации (реализации с использованием методик гибкой разработки) RUP, другие работали в консультационных советах по методам разработки динамических систем (Dynamic System Development Method, DSDM) 6 или в области технологии Agile Model Driven Development (AMDD); 7 третьи практиковали процесс Scrum 8 . При этом все отмечали, что по большей части совместная работа была очень успешной, за небольшими расхождениями по поводу методов разработки программного обеспечения, которые многими воспринимаются по-разному. Мы решили не разрабатывать новый процесс с нуля, а постарались собрать и обобщить работу множества людей и многие процессы.
В прошлом месяце мы, наконец, выпустили 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 организована по принципу микрошагов (см. рисунок 1). Микрошаги представляют собой небольшие единицы работы, которые формируют постоянное измеряемое приращение выполнения проекта (обычно их продолжительность составляет от нескольких часов до несколько дней). Процесс предполагает интенсивную совместную работу, поскольку разработка системы осуществляется постепенно, заинтересованным, построенным по принципу самоорганизации, коллективом. Микрошаги обеспечивают исключительно короткий цикл обратной связи, который делает возможным принятие адаптивных решений в ходе каждой итерации.
Философия гибкой разработки: OpenUP удовлетворяет принципам Manifesto for Agile Software Development (Манифеста гибкой (agile) разработки программного обеспечения), см. (www.agilemanifesto.org)
Расширяемость: IBM, как я полагаю, может стать примером для многих организаций, планирующих создавать расширения OpenUP. В настоящее время мы работаем над переработкой RUP и планируем включить в этот процесс набор расширений для OpenUP. Это значит, что можно будет начать с облегченного процесса с открытым исходным кодом и по мере необходимости добавлять необходимые материалы, что позволит создавать различные варианты RUP и других процессов.
Рисунок 1. Уровни OpenUP: микрошаги, жизненный цикл итерации и жизненный цикл проекта OpenUP делит проект на итерации: планируемые, ограниченные во времени интервалы, длительность которых обычно измеряется неделями. Итерации ориентируют коллектив на поставку постепенно возрастающей потребительской ценности заинтересованным лицам предсказуемым образом. План итерации определяет, что именно должно быть сдано по окончании итерации, а результатом итерации является версия, работу которой можно продемонстрировать или передать для ознакомления и оценки заинтересованным лицам. Коллективы разработчиков OpenUP строятся по принципу самоорганизации, решая вопросы выполнения задач итераций и передачи результатов. Для этого они сначала определяют, а затем решают хорошо детализированные задачи из списка элементов работ. В OpenUP используется понятие жизненного цикла итерации, определяющее, каким образом использовать микрошаги для поставки стабильных, все более совершенных сборок системы, которая постепенно приближается к цели итерации. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение. Итерации: Все процессы гибкой разработки являются итеративными. Самоорганизация: Самоорганизация - это принцип, выделяющий процесс Scrum из остальных процессов гибкой разработки.
Жизненный цикл итерации: Жизненный цикл итерации взят из процесса Eclipse Way.
итерации в OpenUP поддерживают в коллективе разработчиков нацеленность на поставку постоянно растущей потребительской ценности каждые несколько недель путем сдачи полностью протестированной сборки (промежуточного продукта), которую можно продемонстрировать или передать для ознакомления и оценки заинтересованным лицам. Это создает полезную заинтересованность в создании потребительской ценности продукта для заинтересованных лиц, благодаря чему все, что делается, приближает коллектив к достижению цели. Принятие решений должно осуществляться быстрее, потому что время не расходуется на бесконечные обсуждения. Итеративная разработка нацелена на создание работоспособного кода, что снижает риск аналитического паралича. Частые демонстрации работоспособного кода поддерживают механизмы обратной связи, которые при необходимости позволяют вносить коррективы по ходу работы. Элементы работы: Использование одного принципа расстановки приоритетов, а не составление различным образом приоритизированных списков для разных типов требований, дефектов, запросов на совершенствование и т. п., облегчает жизнь разработчикам.
Динамическая предварительная оценка: Коллективы, практикующие принципы гибкой разработки, чаще выполняют предварительную оценку, чем другие коллективы. Многие коллективы, не практикующие методы гибкой разработки, этого не делают. Работа по методам гибкой разработки подчинена внутренней дисциплине.
Планирование итераций, предварительная оценка и отслеживание хода работ производятся по элементам работы. План итерации создается посредством отбора высокоприоритетных элементов работы. Динамическая предварительная оценка: используется для того, чтобы понять, какой объем элементов работы можно без опасения включить во временной промежуток итерации; при этом элементы работ подвергаются фильтрации, позволяющей гарантировать, что выбранные элементы работ позволят коллективу выполнить задачи, согласованные с заинтересованными лицами. Ход выполнения демонстрируется путем последовательного выполнения множества малых элементов работ. По мере того, как проект проходит через фазы своего жизненный цикл, итерации проходят через свои жизненные циклы с различным направлением концентрации усилий коллектива в зависимости от того, находитесь ли вы на первой или последней неделе итерации (см. рисунок 2 ниже 10 ). Итерация начинается с совещания, посвященного планированию итерации, которое продолжается около нескольких часов. В первые день или два основное внимание, как правило, уделяется дальнейшему планированию и архитектуре, чтобы, среди прочего, оценить зависимости и логический порядок элементов работы и влияние производимой работы на архитектуру. Большая часть времени в процессе итерации отводится на выполнение микрошагов. На выходе каждого микрошага должен генерироваться код для сборки, а также проверенные артефакты. Чтобы еще больше усилить дисциплину, стабильные сборки создаются в конце каждой недели. В этих сборках особое внимание уделяется поддержанию качества и разрешению проблем на ранних стадиях, поэтому успешное завершение итерации не подвергается риску. В последнюю неделю или последние несколько дней окончательной шлифовке и исправлению дефектов уделяют больше внимания, чем в предыдущие недели, даже если при необходимости в код добавляются новые функциональные возможности. Цель - не допустить снижения качества и тем самым гарантировать, что по завершении данной итерации будет создан качественный, пригодный к использованию промежуточный продукт. Итерация завершается оценкой (вместе с заинтересованными лицами) созданного продукта и ретроспективным анализом, позволяющим понять, как улучшить процесс перед следующей итерацией. Рисунок 2. Итерация проходит через жизненный цикл с большим вниманием к планированию и архитектуре на ранних этапах и к исправлению дефектов и стабилизации продукта ближе к окончанию. Члены коллектива работают более эффективно, если они могут влиять на то, что и как они делают, а не просто работать в среде, где им приходится выполнять то, что им говорят. Чтобы мотивировать членов коллектива наилучшим образом выполнять свою работу, предоставьте им возможность самим организовывать свою работу (и соответствующие обязанности), и определять, как лучше их выполнять. Это также поможет организовать совместную работу членов коллектива, чтобы обеспечить использование определенных квалификаций для выполнения соответствующих задач. Самоорганизация затрагивает многие области, в том числе, то, как осуществляется планирование и распределение обязанностей (всем коллективом, а не отдельными его членами), как распределяется работа (члены коллектива сами предлагают свои кандидатуры, а не назначаются руководителем) и как члены коллектива видят свою роль в проекте (во-первых, как члены коллектива, а во-вторых, как роли). Для самоорганизации необходимо, чтобы выполнялись следующие условия: Краткие циклы обратной связи: Одной из задач технологии гибкой разработки является укорочение циклов обратной связи. Мне часто приходилось сталкиваться с тем, что члены коллектива неделями работали над каким-либо заданием, не распределив между собой обязанности, что приводило к неэффективности. В Scrum эта проблема решается при помощи Daily Scrums. OpenUP утверждает, что вы можете практиковать аналогичный подход, либо использовать общие инфраструктуры для управления элементами работы.
Личное участие в проекте OpenUP организуется по принципу микрошагов. Микрошаг представляет собой результат работы (продолжительностью от нескольких часов до нескольких дней) одного человека или нескольких человек, участвующих в совместной деятельности по достижению целей итерации. Концепция микрошагов помогает отдельным членам коллектива разбить свою работу на малые единицы, чтобы каждый мог внести измеряемый вклад в работу коллектива. Микрошаги обеспечивают исключительно короткие циклы обратной связи, которые способствуют принятию адаптивных решений в ходе каждой итерации. Микрошаги должны быть хорошо определены; у вас должна быть возможность отслеживать ежедневный ход выполнения каждого микрошага. Микрошаги определяются и отслеживаются по элементам работы. Набор изменений представляет собой физический результат в виде файлов, измененных в ходе выполнения данного элемента работы. Давайте рассмотрим несколько примеров микрошагов: Создаваемое приложение развивается микрошагами через одновременное выполнение нескольких элементов работы. Путем открытого обсуждения хода выполнения микрошагов на ежедневных совещаниях и при помощи инструментов для совместной работы достигается прозрачность и понимание членами коллектива работы друг друга, что обеспечивает эффективность совместных усилий. Кроме того, демонстрируется непрерывный прогресс выполнения, при этом каждый раз разрабатываемое приложение продвигается на один микрошаг вперед. OpenUP предоставляет набор деятельностей. Каждая деятельность представляет собой набор задач, шагов в рамках этих задач и рекомендаций. Несмотря на то, что микрошаги не являются явно документированной конструкцией в данном процессе, вы найдете описания выполнения наборов связанных микрошагов, которые обычно в проектах находятся внутри деятельности. OpenUP не предоставляет полного описания возможных микрошагов, и каждой организации придется создать свои "рецепты" для часто встречающихся микрошагов. OpenUP предлагает эффективный инструмент обучения и упрощает поиск полезных рекомендаций, показывая, когда вам с наибольшей вероятностью придется выполнять различные задачи. Это осуществляется через визуализацию процесса поставки решения, которая представляет собой организацию задач по времени в контексте жизненного цикла проекта. Например, вероятнее всего вам придется согласовать технические методы на ранних стадиях проекта. Это не означает, что вы не будете принимать технические решения на более поздних стадиях. Процесс напоминает карту: используйте его для понимания общей картины и для справки, но если карта и реальная ситуация не совпадают, доверяйте реальной ситуации. Микрошаги: Может быть, именно с их помощью можно будет усовершенствовать OpenUP в будущем?
Заинтересованные лица: Термин "заинтересованные лица" - это общий термин. Данное понятие объединяет руководителей и других людей, которые распоряжаются деньгами и определяют стратегическое направление. В жизненном цикле для заинтересованных лиц необходимо предусмотреть особые точки принятия решений, в которых они должны выразить свое одобрение/неодобрение хода выполнения проекта.
Жизненный цикл проекта предоставляет заинтересованным лицам механизмы контроля, обеспечения прозрачности и наблюдения, позволяющие управлять финансированием, масштабом проекта, его подверженностью риску, поставляемой потребительской ценностью и другими аспектами процесса. Каждая итерация на выходе имеет промежуточный продукт, который позволяет заинтересованным лицам понять, какая потребительная ценность была создана и насколько хорошо они отслеживают проект. Кроме того, он также позволяет коллективу разработчиков внести в проект изменения для оптимизации конечного результата. В OpenUP итерации организуются как набор фаз. Каждая фаза завершается контрольной точкой, предназначенной для обеспечения контроля путем постановки и ответов на ряд вопросов, которые обычно являются важными для заинтересованных лиц: Если на приведенные выше вопросы в отчете по данной фазе получен ответ "да", то разработка проекта продолжается согласно плану. В случае ответа "нет" сроки данной фазы продлеваются (обычно путем добавления дополнительной итерации) до тех пор, пока не будет получен удовлетворительный ответ или заинтересованные лица не примут решение об отказе от проекта. Одной из задач жизненного цикла проекта является концентрация внимания на двух мотивах заинтересованных лиц: снижении риска и создании потребительской ценности. Фазы OpenUP нацеливают рабочую группу на снижение риска в соответствии с ответами на вопросы в конце каждой фазы с одновременным отслеживанием процесса создания потребительской ценности, как показано на рисунке 3. Рисунок 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 могут:
