Зрелость проектных организаций. Методология CMM

Стандартный производственный процесс организации. Начну опять с цитаты из СММ.

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

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

Ключевые практики в определении производственного процесса организации (ППО) выражаются в терминах, отражающих стабильный и в то же время гибкий подход к определению процесса".

Как видно из этого текста, "лесенка уровней" на самом деле имеет следующий смысл.

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

Для этого на третьем уровне вводятся группы ключевых процессов "Определение производственного процесса организации" и "Координация производственного процесса организации". Вот что говорит СММ о первой из них.

"Определение производственного процесса организации (ППО) включает в себя разработку и поддержку стандартного производственного процесса организации (СППО) и связанных с ним основных средств, таких как описание жизненных циклов ПО, инструкции и критерии для адаптации процессов, база данных ППО и библиотека документации по производственным процессам.

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

Основные средства ППО используются для разработки, внедрения и сопровождения производственных процессов отдельных проектов".

Вот как выглядят в CMM цели этой группы ключевых процессов:

"Цель 1. Разработка и сопровождение стандартного производственного процесса организации.

Цель 2. Сбор, изучение и распространение информации, связанной с использованием СППО в проектах разработки ПО".

Вторая группа ключевых процессов описывается так.

"Координация производственного процесса организации (ППО) включает в себя достижение и поддержку должного уровня понимания производственных процессов организации и проекта, а также координацию работ по оценке, разработке, сопровождению и усовершенствованию этих процессов.

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

У этой группы ключевых процессов три цели:

"Цель 1. Координация мероприятий по разработке и усовершенствованию производственного процесса в рамках всей организации.

Цель 2. Выявление преимуществ и недостатков используемых производственных процессов в сравнении со стандартным процессом.

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

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

Остальные группы ключевых процессов третьего уровня имеют техническую направленность, включая группу "Программа обучения", ориентированную на обучение технических специалистов. Вкратце, третий уровень - это уровень обобщения и осмысления проектного опыта.

СППО наряду с качеством продукта становится основным объектом интереса на четвертом уровне. Группы ключевых процессов на этом уровне называются "Количественное управление процессом" (имеется в виду СППО) и "Управление качеством ПО". Цели первой группы:

"Цель 1. Планирование работ по количественному управлению процессом.

Цель 2. Установление количественного контроля над выполнением производственного процесса проекта.

Цель 3. Количественное выражение продуктивности стандартного производственного процесса организации".

Цели второй группы:

"Цель 1. Планирование работ по управлению качеством ПО.

Цель 2. Определение желаемых количественных показателей качества программного продукта и их приоритетов.

Цель 3. Фактический процесс достижения желаемых показателей качества программных продуктов должен быть количественно определен и управляем".

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

А как же инновации, исследовательская работа, организационное совершенствование и т. п.? Ведь ни в каком отдельном проекте этому не уделяется специального внимания. А вот для этого есть пятый уровень с его тремя группами ключевых процессов: "Предотвращение дефектов" (развитие работ по обеспечению качества), "Управление технологическими изменениями" (оценка и внедрение при необходимости новых технологий), "Управление изменениями процесса" (вся совокупность работ по усовершенствованию СППО в масштабах организации).

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

Смысл уровней CMM - в постепенном повышении результативности и эффективности процессов. Это достигается за счет накопления в СППО опыта индивидуальных проектов и создания механизма адаптации СППО к условиям конкретного проекта. В результате результативность проектных процессов возрастает, поскольку организация проекта не зависит исключительно от индивидуальных способностей руководителя проекта, а становится более-менее формальной процедурой.

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

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

Такова вкратце логика СММ. В отличие от рассмотренных выше процессных стандартов, она демонстрирует абсолютно прагматичный и конкретный подход к построению процессов управления ИТ (точнее, тех из них, которые связаны с разработкой программных систем). Если цель внедрения, например, ГОСТ Р ИСО/МЭК 12207 - построение системы процессов жизненного цикла, основанной на лучших практиках , то цель внедрения СММ - создание механизма совершенствования организации, в основе которого - стремление к построению высокоэффективного и постоянно совершенствующегося производственного процесса.

Этим, однако, СММ не ограничивается. Вот что сказано в (Paulk, и др., 1995):

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

Тем самым закладываются основы для создания теории и практики внешней или сторонней оценки зрелости организаций на базе модели СММ. Фактически речь идет о создании новой услуги - оценки зрелости организаций. Возникает потребность в обучении СММ:

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

Очевидно, в том виде, в котором СММ представлена в доступных широкой аудитории материалах, она не дает исчерпывающих ответов на целый ряд практических вопросов. Например, как оценивать уровень организации, если часть практик, относящихся к этому уровню, присутствует, а часть - нет? Что вообще однозначно свидетельствует о наличии практики: документ, устное заявление исполнителя, материализованный проектный опыт или что-то еще? Ответы на такие вопросы в конечном итоге определяют объем и сложность работ, а значит, и цену услуги. Без точного и однозначного понимания состава и сложности работ исполнителем и заказчиком контракт просто невозможен. Это означает, что дополнительное обучение СММ, а может быть, и доработка модели, действительно необходимы.

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