Методология OpenUP: введение
OpenUP (Open Unified Process) — это облегчённая версия Unified Process с открытым исходным кодом. Она применяет итеративную и инкрементную разработку в рамках структурированного жизненного цикла из четырёх фаз: Inception, Elaboration, Construction и Transition. Eclipse Foundation описывает OpenUP как минимальный, полный и расширяемый процесс разработки ПО для небольших команд, работающих в одном месте. Он сохраняет внимание RUP к архитектуре и добавляет гибкие практики, например список рабочих элементов и короткие итерации фиксированной длительности.
Главное
- OpenUP разработали в проекте Eclipse Process Framework, которому IBM передала материалы процесса в 2006 году.
- Процесс построен на четырёх принципах: сотрудничество, баланс, фокус и развитие.
- Работа организована на трёх уровнях: микроинкременты, итерации и жизненный цикл проекта.
- По сравнению с RUP OpenUP компактнее и бесплатен, а по сравнению со Scrum добавляет фазы и контрольные точки.
Что такое OpenUP
OpenUP создали в рамках проекта Eclipse Process Framework (EPF), который стартовал в 2005 году. В январе 2006 года IBM передала проекту материалы процесса, а OpenUP 1.0 вышел в составе EPF 1.2. Цель состояла в том, чтобы предложить бесплатный процесс, который сохраняет проверенные идеи Rational Unified Process, но без его объёма.
В опубликованном описании OpenUP процесс назван «облегчённым Unified Process». Он не привязан к конкретным инструментам, требует минимума формальностей, соответствует ценностям Agile Manifesto и может расширяться для других типов проектов. Команды начинают с минимального набора практик и добавляют новые, только когда проект этого требует.
Четыре базовых принципа OpenUP
OpenUP построен на четырёх принципах. Каждому из них соответствует набор практик процесса:
| Принцип | Официальная формулировка | Что это значит на практике |
|---|---|---|
| Сотрудничество (Collaborate) | Сотрудничать, чтобы согласовать интересы и общее понимание | Команда и заинтересованные стороны ежедневно работают вместе и согласуют цели |
| Баланс (Balance) | Балансировать конкурирующие приоритеты, чтобы максимизировать ценность для заинтересованных сторон | Объём, стоимость и сроки взвешивают с учётом ценности для заинтересованных сторон |
| Фокус (Focus) | Сосредоточиться на архитектуре на ранних этапах, чтобы минимизировать риски и организовать разработку | Самые рискованные технические решения проверяют в коде уже в первых итерациях |
| Развитие (Evolve) | Развиваться, чтобы постоянно получать обратную связь и совершенствоваться | Каждая итерация завершается отзывами, которые меняют план следующей |
Три уровня работы
OpenUP организует работу на трёх уровнях, и у каждого своя длительность и результат:
| Уровень | Длительность | Результат |
|---|---|---|
| Микроинкременты | От нескольких часов до нескольких дней | Небольшая измеримая часть работы одного участника |
| Жизненный цикл итерации | Обычно несколько недель | Сборка, которую можно показать или выпустить |
| Жизненный цикл проекта | Весь проект, в четырёх фазах | Выпущенное приложение |
Микроинкременты задают команде ровный темп и очень короткий цикл обратной связи. Каждый уровень мы подробно описываем в нашей серии статей о жизненном цикле итерации, микроинкрементах и жизненном цикле проекта.
Четыре фазы и контрольные точки
Четыре фазы OpenUP взяты из Unified Process. Каждая фаза содержит одну или несколько итераций и завершается контрольной точкой, где заинтересованные стороны решают, продолжать ли проект:
| Фаза | Фокус | Контрольная точка |
|---|---|---|
| Начало (Inception) | Согласование объёма, целей и технического подхода | Цели жизненного цикла (Lifecycle Objectives) |
| Проработка (Elaboration) | Создание и проверка архитектуры, уточнение требований | Архитектура жизненного цикла (Lifecycle Architecture) |
| Построение (Construction) | Разработка решения инкрементами и его тестирование | Начальная рабочая версия (Initial Operational Capability) |
| Внедрение (Transition) | Развёртывание продукта, подготовка пользователей и среды | Выпуск продукта (Product Release) |
Ищете команду для итеративной разработки?
OpenUP, RUP и Scrum: сравнение
OpenUP занимает место между RUP и Scrum. Вот как сравниваются эти три подхода:
| OpenUP | RUP | Scrum | |
|---|---|---|---|
| Происхождение | Eclipse Process Framework, открытый исходный код | Rational Software, затем IBM, коммерческий продукт | Кен Швабер и Джефф Сазерленд, Scrum Guide |
| Жизненный цикл | Четыре фазы с итерациями внутри | Четыре фазы с итерациями внутри | Непрерывная серия спринтов без фаз |
| Длительность итерации | Обычно несколько недель | Определяет проект | Не больше месяца |
| Архитектура | Прорабатывают рано, в фазе Elaboration | Центральная для всего процесса | Не регламентирована |
| Роли и артефакты | Небольшой базовый набор | Большая библиотека, которую адаптируют под проект | Три зоны ответственности и три артефакта |
| Когда подходит | Небольшие команды в одном месте, которым нужна определённая структура | Крупные или регулируемые проекты | Команды, которые постоянно развивают продукт |
OpenUP позаимствовал несколько практик из Scrum. В сравнении, опубликованном в Methods & Tools, Бьорн Густафссон отмечает, что список рабочих элементов OpenUP выполняет роль product backlog, план итерации соответствует sprint backlog, а ежедневный стендап используют так же. Подробнее о Scrum Guide и о том, как XP и Eclipse Way повлияли на OpenUP, читайте в пятой части нашей серии.
Когда выбирать OpenUP
OpenUP хорошо подходит небольшой команде, которая создаёт новую систему с реальными техническими рисками и нуждается в формальных контрольных точках, например чтобы отчитываться перед клиентом или инвестором в конце каждой фазы. Он также полезен как ориентир для компании, которой уже тесно в неформальном Scrum и нужен явный этап архитектуры без перехода на тяжёлый фреймворк.
Для продукта, который уже работает и постоянно развивается, структура фаз мало что добавляет, и Scrum или Kanban обычно проще. Для крупных программ со многими командами и строгими требованиями соответствия больше контроля даёт адаптированный процесс в стиле RUP или масштабируемый фреймворк.
Как мы используем идеи OpenUP в New Line Technologies
В New Line Technologies мы редко применяем OpenUP в полном опубликованном виде, но используем его структуру в новых продуктах. Например, в финтех-проектах мы начинаем с короткого этапа проработки, где команда создаёт и проверяет самые рискованные части архитектуры, например платёжные интеграции и безопасность, прежде чем масштабировать разработку. После этого команда работает регулярными итерациями, и каждая завершается демонстрацией для клиента.
Узнайте больше о наших услугах по разработке программного обеспечения, о том, как выделенная команда разработчиков может усилить ваш проект, и как этот подход связан с инкрементной моделью.
Типичная ошибка и как её избежать
Самая распространённая ошибка с OpenUP: воспринимать четыре фазы как этапы каскадной модели. Команда тратит фазы Inception и Elaboration на документы, а первый рабочий код появляется только в Construction. Тогда фазы добавляют бюрократии, а главный риск так и остаётся непроверенным.
Чтобы этого избежать, сделайте каждую фазу итеративной и требуйте рабочее ПО на каждой контрольной точке. К концу Elaboration у команды должна быть исполняемая архитектура: упрощённая версия системы, которая работает от начала до конца и подтверждает ключевые технические решения.
Частые вопросы
Да, OpenUP следует ценностям Agile Manifesto и использует короткие итерации фиксированной длительности, список рабочих элементов и ежедневные стендапы. При этом он добавляет структурированный жизненный цикл с четырьмя фазами и контрольными точками, поэтому формальнее Scrum.
Оба процесса используют одни и те же четыре фазы и уделяют внимание архитектуре. RUP — большой коммерческий фреймворк процессов с множеством ролей и артефактов, которые команды сокращают под себя. OpenUP имеет открытый исходный код и начинается с минимума, поэтому команды добавляют практики только по необходимости.
Итерации в OpenUP имеют фиксированную длительность и обычно длятся несколько недель. Каждая завершается сборкой, которую можно показать или выпустить. Внутри итерации работу делят на микроинкременты длительностью от нескольких часов до нескольких дней.
Материалы OpenUP теперь хранятся в архиве Eclipse, и немногие команды применяют процесс в полном опубликованном виде. Его идеи по-прежнему в ходу: многие команды сочетают Scrum с ранним этапом архитектуры и контрольными точками, что близко к подходу OpenUP.
Планируете новый продукт и хотите процесс разработки с нужным уровнем структуры? Свяжитесь с нашей командой, и в рамках наших услуг по разработке ПО мы поможем выбрать подход и собрать подходящую команду.
