Общие рекомендации

По мере ознакомления с рабочими продуктами, задачами и ролями в Rational Unified Process (RUP) вы можете задавать себе следующие вопросы:

• Нужно ли мне вот это?
• Как определить, что из этого нужно для проекта?
• Не очевидно ли, что RUP только для больших проектов?

Данный раздел поможет ответить на эти вопросы.

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

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

Далее приводятся рекомендации относительно адаптации процесса. Более подробные сведения приведены в разделе Концепции: Адаптация RUP.

Начните с инфраструктуры

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

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

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

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

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

Следует различать критически необходимые для процесса элементы от пунктов "списка пожеланий", для которых также рассчитывать, стоят ли они трудозатрат.

Оградите разработчиков от процесса

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

Минимизируйте число формальных промежуточных рабочих продуктов

Формат таких рабочих продуктов, т.е. не предназначенных для конечного продукта, не важен. Не имеет значения, как они будут выглядеть, или какие инструменты применяются для их создания, при условии, что они соответствуют своему назначению. Как сказал Dwight D. Eisenhower, "План есть ничто; планирование есть все."

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

Используйте удобные форматы

Рабочий продукт может сопровождаться в любой форме. Например, документ Vision можно хранить в виде Web-страницы, план проекта в в файле Microsoft Project, а список рисков - в виде типа требований Rational RequisitePro. 

Автоматизируйте все, что поддается автоматизации

В некоторых проектах значительная часть времени уходит на заполнение шаблонов формальных документов путем копирования и вставки данных из буфера обмена. Очевидно, эту работу можно автоматизировать. Для этого существуют специальные средства, такие как Rational SoDA. Другим решением является изменение формата отчетов, например, можно предоставлять модель проектирования в Web-формате, создаваемую в Rational Rose Publisher.

В большинстве случаев для рабочих продуктов можно вообще не генерировать специальные документы, т.к. вся нужная информация доступна неявно в среде. Например, вместо того чтобы генерировать часть Плана управления требованиями со списком атрибутов типов требований, можно предоставить адаптированный проект Rational RequisitePro с типами требований и их трассируемостью, а затем пройтись по нему в присутствии заинтересованных сторон. Другой пример: заинтересованным сторонам можно предоставить файлы Microsoft Project, доступные только для чтения, вместо копирования графических данных в отдельный план разработки ПО.

Используйте Web-технологии

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

Используйте интегрированный инструментарий

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

Регулярно пересматривайте процесс

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

Не отказывайтесь от практических приемов при адаптации

В RUP одобряется адаптация процесса. Однако, в рамках адаптации не следует коренным образом менять весь процесс.  Основу RUP составляют практические приемы. Следуйте их принципам при адаптации задач и рабочих продуктов.