Практика

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

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

Другие практики XP приносят свои ограничения. Далеко не всегда можно обеспечить постоянное присутствие представителя заказчика в проектной команде (например, если потенциальные пользователи системы делятся на несколько классов с частично конкурирующими требованиями).

Поскольку XP практически не делает попыток предотвратить размывание границ проекта (scope creep), будет не очень хорошей идеей использовать XP в проекте с фиксированной ценой. Фактически проекты XP обладают жестким графиком, но переменными границами, поэтому предпочтительным типом контракта будет повременная оплата (time&materials).

Практика поддержания максимально простой архитектуры может завести в тупик в конце проекта, когда окажется, что для реализации завершающих историй требуется полное перепроектирование системы (оказывается, нам нужно было предусмотреть возможность интеграции с системой SAP R/3, а также перевода на японский язык всего пользовательского интерфейса!). Даже если подобная ситуация не возникнет, нет никакой гарантии, что создаваемая ad hoc архитектура не будет намного более запутанной и сложной, чем было бы продуманное заранее решение.

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

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

XP является достаточно гибкой методологией. Не обязательно внедрять XP во всей компании, вполне разумно ограничиться теми командами и проектами, которые могут получить от этого реальный выигрыш. Например, для разработки ядра продукта можно использовать XP, а проекты по внедрению основывать на процессе RUP. Также не обязательно использовать все классические практики XP (на самом деле, мало кто это делает) – как правило, разумно ограничиться теми из них, которые сочетаются с корпоративной культурой и особенностями проектов.

CMMI

Модель Capability Maturity Model Integration (CMMI) была разработана в течение 1990-х годов в университете Карнеги-Меллона (Carnegie Mellon University.) совместно с Software Engineering Institute (SEI) и другими организациями. Одним из главных спонсоров разработки стало Министерство обороны США. CMMI была создана путем объединения (отсюда слово Integration в названии) трех более ранних специализированных моделей разработки: CMM for Software (SW-CMM), Electronic Industries Alliance Interim Standard (EIA/IS) 731 и Integrated Product Development Capability Maturity Model (IPD-CMM). Последняя версия спецификации CMMI 1.2 была опубликована в августе 2006 года.

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

Необходимо сказать, что CMMI не описывает какой-то конкретный процесс разработки. CMMI-совместимым может быть проект с водопадным, итеративным или другим жизненным циклом. Правильнее думать о CMMI как о наборе элементов процессов, приемов и методик, из которых, как из конструктора, нужно собрать законченный процесс.

Внедрение CMMI в организации может происходить на непрерывной (continuous) или ступенчатой (staged) основе. Содержание модели CMMI в обоих случаях одно и тоже, меняется только ее представление. Непрерывное представление дает возможность производить улучшения в отдельных процессных областях в произвольном порядке. Ступенчатое представление определяет четкую последовательность шагов по внедрению CMMI; каждый шаг соответствует достижению так называемого уровня зрелости (maturity level). Организации необходимо принять решение, до какого уровня зрелости она намерена дойти, а также необходимо ли проходить официальную сертификацию на соответствие этому уровню.

Остановимся подробнее на ступенчатом представлении, поскольку именно оно чаще всего используется на практике.

Структура CMMI (ступенчатое представление)

Основными элементами модели CMMI являются процессные области, общие и специальные задачи, общие и специальные практики.

CMMI определяет 22 процессные области, такие как планирование проекта (Project Planning), управление рисками (Risk Management), разработка требований (Requirements Development) и т.д. В ступенчатом представлении процессные области сгруппированы по пяти уровням зрелости (от 1 до 5). В непрерывном представлении каждая процессная область находится на одном из шести (от 0 до 5) уровней производительности (capability level).

Процессы в каждой процессной области должны достигать ряда целей. Общие цели (generic goals) относятся к нескольким процессным областям. Специальные цели (specific goals) уникальны для своей процессной области.

Для достижения специальных и общих целей служат специальные и общие практики (practices). Практики – это деятельность или задачи, которые должны быть выполнены для достижения соответствующей цели.

Рис. 6.

В качестве примера рассмотрим процессную область Планирование проекта (Project Planning). В нее входит определение проектных артефактов, разбиение работ на отдельные задачи и их оценка, планирование необходимых ресурсов, составление графика проекта, анализ рисков, и т.д. В результате планирования проекта создается план проекта (project plan) – основной документ для организации и контроля проектных работ, управления бюджетом и оценки доходности , управления изменениями и рисками.

Процессная область Планирование проекта должна достигать трех специальных и двух общих целей. В рамках этих целей необходимо:

• Установить оценки (специальная цель): подготовить реалистичные оценки, такие как трудоемкость и стоимость проекта, для дальнейшего планирования.
• Разработать проектный план (специальная цель): создать документ, одобренный заинтересованными сторонами, описывающий жизненный цикл проекта, бюджет, ресурсы, риски, график, стратегию обеспечения качества и т.п.
• Получить обязательства участников проекта (специальная цель): участники проекта, ответственные за его выполнение, должны считать проектный план реалистичным и выполнимым, и подтвердить обязательство выполнить свои задачи в рамках заданного графика, ресурсов и качества.
• Учредить управляемый процесс (общая цель): общее требование к процессам на уровне зрелости 2.
• Учредить определенный (defined) процесс (общая цель): общее требование к процессам на уровне зрелости 3.

Перечислим практики, позволяющие достичь цели «разработать проектный план».

• Установить бюджет и график проекта.
• Идентифицировать риски.
• Спланировать управление данными (определить источники и форматы данных, необходимые процедуры для миграции, репликации и получения данных, требования по безопасности и т.д.).
• Определить необходимые ресурсы.
• Определить требования к профессиональным навыкам сотрудников, запланировать тренинги.
• Запланировать вовлечение всех заинтересованных лиц.
• Создать проектный план.

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

• Уровень 1: начальный (Initial). Процессы в организации формируются спонтанно и хаотично. Отдельные проекты могут завершаться успешно, однако вероятность их успешного завершения, а также соответствие запланированным графику и бюджету малопредсказуемы.
• Уровень 2: управляемый (Managed). Основная задача при внедрении этого уровня – установить для каждого проекта стандартные процессы управления требованиями, планирования, наблюдения и контроля над проектом, управления конфигурациями. Естественно, процессы должны соответствовать требованиям CMMI, а именно достигать всех специальных целей в соответствующих процессных областях, а также общих целей, относящихся к уровню 2. Для каждого проекта периодически проводится анализ его соответствия установленным процедурам и, при необходимости, корректирование процессов. Также периодически измеряются и анализируются метрики (производительности, качества и т.п.)
• Уровень 3: определенный (Defined). Уровень 3 включает в себя все требования уровня 2, а также добавляет множество обязательных процессных областей (разработка требований, интеграция, тестирование, управление рисками, и другие). Однако главное его отличие от уровня 2 заключается не в этом. В то время как уровень 2 требует определить процесс для каждого отдельного проекта, на уровне 3 набор стандартных процессов должен существовать на уровне всей организации. Процессы для отдельных проектов создаются при помощи настройки (tailoring) стандартных процессов организации, при этом изменения должны быть ограничены правилами настройки (tailoring guidelines). Настройка процессов – это также процессная область, определенная в CMMI как Organizational Process Definition.
• Уровень 4: количественно управляемый (Quantitatively Managed). Этот уровень требует количественного измерения метрик производительности и качества используемых процессов. По сравнению с уровнем 3 уровень 4 дает возможность предсказания и сравнения (на основе статистических данных) измеряемых характеристик процессов.
• Уровень 5: оптимизирующий (Optimizing). Уровень 5 – высшая ступень развития организации, использующей CMMI. При помощи метрик с уровня 4 организация постоянно изменяет свои процессы для того, чтобы улучшить производительность и качество создаваемых продуктов.