Работая в компании Page Technologies, я имел возможность познакомить с методологией RUP (Rational Unified Process) ряд сотрудников, специализирующихся в различных предметных областях, причем это происходило по различным сценариям. В некоторых сценариях у меня была роль руководителя проекта, в других - роль сотрудника отдела сбыта, а иногда я проводил семинары. Всякий раз главная задача заключалась в том, как доходчиво объяснить людям замечательные возможности методологии RUP.
В конце концов, я пришёл к выводу, что RUP полезно сравнивать с буфетом или рестораном. Это довольно точное сравнение.
Правда, эта аналогия полезна лишь тогда, когда вам нужно продать или внедрить RUP в организации. Сравнение RUP с буфетом очень хорошо помогает объяснить такие основные концепции RUP как четыре фазы, итеративная разработка, адаптация RUP к конкретным производственным требованиям и т.д. Оно полезно в следующих случаях:
- Вы руководите проектом и хотите доказать своим подчинённым или руководству, что ваша организация должна внедрить методологию RUP.
- Вы являетесь членом группы, которая хочет, чтобы её организация внедрила RUP.
- Вы хотите изменить мнение организации или отдельных лиц, которые думают, что RUP - это нечто монолитное, не гибкое и не способное конкурировать с такими процессами как XP, RAD (быстрая разработка приложений) и т.д.
- Вы хотите показать ценность RUP организации или отдельным лицам, которые думают, что эта методология лишь добавляет ненужную работу, столь же бесполезную, как например измерение громкости звука при падении документа на стол.
Цель этой статьи - не анализ скорости окупаемости или эмпирических данных с целью доказать полезность внедрения RUP. Цель - провести аналогию, которая поможет читателям понять, как лучше внедрять методологию RUP.
Основная аналогия
Начну с того, что я люблю буфеты. Мне очень понравились местные китайские, индийские, тайские и мексиканские буфеты, которые я посетил вместе со своими коллегами-разработчиками за многие годы работы. Несколько лет назад, во время одного из таких походов в ресторанчик в Миннеаполисе, меня осенило: RUP чем-то напоминает посещение такого буфета. У вас есть требования, вам предлагают соответствующее решение. Требования диктуются потребностью (голодом), а решение (пища) предлагается буфетом. А доставка этого решения в желудок называется процессом. Вероятно, вам доводилось посещать какой-нибудь буфет несколько раз (это итерации) и пользоваться несколькими инструментами и операциями, чтобы есть различные блюда (фазы). Подробнее эта аналогия описана в таблице 1.
Таблица 1. Сходство между RUP и буфетом (рестораном)
|
Что сравнивается |
Буфет |
RUP |
| Потребность | Буфеты служат для утоления голода, основной потребности, которая удовлетворяется пищей. Но есть нужно только для того, чтобы утолить голод. Есть ради еды, не чувствуя голода, считается нехорошо | Решения служат для удовлетворения потребностей предприятий, поэтому создавать решение нужно только после определения этих потребностей (первый шаг в RUP). Трудно представить себе группу разработчиков программного обеспечения, которая работает только для того, чтобы проектировать и писать программы, не имея никакой цели. (Вы такое уже видели? Будем надеяться, что это исключение из правила) |
| Процесс | В буфете есть структура (буфетная стойка) и процесс (накладывание пищи на тарелки), которые позволяют утолить голод | RUP содержит структуру и процесс, которые позволяют удовлетворить потребности предприятия и способствуют разработке. |
| Выбор варианта | В буфете вы берёте то, что вам нравится и позволяет утолить голод. Правда, бывают такие обжоры, которые сметают всё подряд, но их не так уж много. Буфет устроен так, чтобы вы могли выбрать подходящий во всех отношениях вариант, чтобы было вкусно и питательно. От того, насколько вам понравится выбранное блюдо, зависит ваш выбор в следующий раз. | Вы адаптируете RUP к конкретным потребностям предприятия. Правда, бывают такие случаи, когда используются почти все возможности RUP, но это исключения. Методология RUP устроена так, чтобы вы могли выбрать подходящий во всех отношениях вариант, чтобы было красиво и удачно. От того, насколько вам понравятся те или возможности RUP, зависит ваш выбор в будущем. |
| Фазы | В большинстве буфетов США есть четыре вида блюд: аперитив или закуска, салат, главное блюдо, десерт. Все они питательны, но большинство людей предпочитают употреблять их именно в таком порядке. И на это есть основания: салат позволяет убрать вкус предыдущего блюда и полнее ощутить вкус главного блюда, а сладкий десерт гасит аппетит, потому его лучше есть в самом конце трапезы. | RUP делится на четыре фазы: обследование, проработка, построение системы, передача её в эксплуатацию. Разработка должна вестись именно в этом порядке, потому что сначала необходимо понять и записать требования, затем подробно проработать архитектуру системы и т.д. |
| Итерации | Одно из преимуществ буфета - возможность посещать его столько раз, сколько потребуется. Не обязательно пробовать все блюда сразу, за одно посещение буфета, их можно пробовать постепенно, посещая буфет несколько раз. | Одним из преимуществ процесса RUP является его итеративность. Весь процесс от формулирования требований до создания исполняемого файла можно проходить несколько раз. Это ключевое преимущество RUP перед традиционным процессом, напоминающим водопад, когда каждая фаза проходится только один раз. |
| Оценка | После каждого похода в буфет вы оцениваете съеденные блюда. Понравилось ли вам это блюдо? А если вам приходится сидеть на диете, то возникают дополнительные вопросы. Например, блюдо вкусное, но вам оно вредно. В любом случае у вас есть возможность прийти в ресторан ещё раз и выбрать блюда с учётом уже сделанных оценок | В процессе RUP после каждой итерации выполняется её оценка, чтобы понять, что получилось удачно, а что неудачно, что нужно сделать на следующей итерации. К некоторым вопросам придётся вернуться и доработать их, кое-что можно будет использовать в следующих проектах. А то, что оказалось негодным, вы больше не будете применять. |
Цель этого сравнения - показать, что RUP не предлагает нечто по принципу "всё или ничего". Методика RUP не заставляет группу разработчиков использовать всё мыслимые операции, шаблоны и артефакты. Нужно лишь адаптировать процесс, подогнать его под конкретные требования. Так же, как в ресторане всегда приходится пользоваться посудой, без которой нельзя обойтись во время еды, например, тарелками, ложками, ножами и вилками, так и в процессе RUP есть основные аспекты (фазы, итерации и т.д.), которые используются в любом проекте. Но вам нужно решать, что класть на свою тарелку, и как часто ходить в буфет. Так же и в процессе RUP вы должны решить, что именно внедрить в своём проекте, что необходимо для выполнения всех требований. В конце концов только вы со своей группой решаете, как реализовать этот процесс.
Подготовка к применению RUP
Приобретите знания и опыт
Совершенного правила по применению RUP не существует; всякий раз нужно оценивать ситуацию в организации, применять лучшие методы работы, вести разработку итеративно, заинтересовать всех членов группы. Первый шаг к успеху - "познание себя". Если вы попытаетесь внедрить в организации RUP, не имея опыта, вам придется очень трудно. Сначала нужно получить необходимые знания и опыт. Пообщайтесь с группами пользователей RUP, с теми разработчиками, которые уже имеют опыт внедрения и применения RUP. Изучите форумы на странице http://www.rational.com/support/usergroups/index.jsp, в том числе обсуждение процесса Rational Unified Process. Опыт и знания помогут вам значительно эффективнее привить RUP вашей группе разработчиков.
Изучите организацию
Важно понимать, что сотрудники вашей организации могут существенно различаться по уровню опыта; это нужно изучить и учесть. Возможно, окажется, что некоторые сотрудники имеют опыт разработки, другие - в бизнесе, третьи хорошо знают предметную область и т.д. У некоторых уже сложилось мнение о том, каким должен быть процесс разработки, кто-то предвзято относится к RUP. Будьте готовы отвечать на любые вопросы, чтобы вас не застали врасплох те, кто относится к RUP враждебно. Готовясь к собранию, запишите вопросы, которые могут вам задать сотрудники, имеющие опыт работы в тех или иных областях. Затем составьте информативные ответы, которые помогут этим сотрудникам понять, какое нужно принять решение.
Изучите имеющийся опыт внедрения RUP
Выясните, есть ли в вашей организации сотрудники, которые уже имеют опыт применения RUP, особенно отрицательный. Как правило, отрицательное впечатление складывается в случае неверного внедрения RUP, когда эту методологию ошибочно представляют:
- Как монолит.
- Как процесс без итераций.
- Как предложение "всё или ничего", в результате чего группа разработчиков чувствует себя обязанной использовать все шаблоны, потоки операций и т.д. независимо от того, нужны ли они на самом деле.
- Как несущественную часть комплекта инструмента Rational.
- Как нечто готовое, не требующее обучения и опыта.
Предварительно поговорите с группой, отвечающей за успех проекта, чтобы понять, каков их опыт, с какими они сталкивались проблемами. Будьте готовы ответить тем, кто будет возражать против вашей инициативы по внедрению RUP на основе своего отрицательного опыта, полученного в результате неверного применения RUP.
Выявите также и тех, у кого есть удачный опыт по применению RUP. Выясните, что именно в их опыте было удачным (желательно узнать об оценке итераций, как были решены проблемы), запишите эту информацию, а затем воспользуйтесь ею для убеждения лиц, принимающих решения.
Заключение
Некоторые понимают суть RUP сразу, а другим для этого требуется время. Попробуйте объяснить им с помощью аналогии с буфетом. У меня это всегда получалось хорошо, особенно в разговоре с людьми, ещё не знакомыми с процессом RUP. Заинтересуйте своих собеседников этой аналогией, может быть, они сами найдут больше примеров и параллелей. Такое упражнение займёт не более пары минут, увлечёт собеседников и поможет им лучше понять, что вы им предлагаете.