Субъективно о CMMI (часть 1)

В этом разделе: Небольшая историческая справка, Основные определения и понятия, Основные представления.

Я не буду особо сильно углубляться в исторические дебри. Это займет много времени и, кроме того, история создания неразрывно связана с другой методологией – CMM. А уж этот вопрос я обязательно подниму, когда мы будем сравнивать CMMI и CMM.

Итак, CMMI является развитием методологии CMM, которая разрабатывалась со второй половины 1980-х годов Software Engineering Institute (SEI) в университете Карнеги- Меллона(Carnegie Mellon University). Насколько мне известно, изначально эта методология разрабатывалась для использования на каких-то военных задачах. А уже потом, практичные американцы адаптировали её для сертификации коммерческих компаний. Возможно этим и объясняется то, что CMMI Development версии 1.1 содержит некоторое количество вещей, которые сложно применимы к реалиям IT-индустрии. Но всему свое время.

Итак, что же такое CMMI. Неплохое описание находится в Wikipedia: 
Capability Maturity Model Integration (CMMI) — методология усовершенствования процессов в организациях. CMMI содержит критерии оценки качества процессов, методики их улучшения, а также предоставляет фрагменты эффективных процессов.

А в оригинале это звучит приблизительно следующим образом: 
Capability Maturity Model Integration (CMMI) models provide guidance to use when developing processes. CMMI models are not processes or process descriptions. The actual processes used in an organization depend on many factors, including application domain(s) and organization structure and size. In particular, the process areas of a CMMI model typically do not map one to one with the processes used in your organization.

При этом CMMI является руководством к действию по улучшению процессов или, что более понятно для разработчиков, спецификацией. С другой стороны адаптация (реализация) этих описаний под свои нужды (tailoring) не всегда правильно воспринимается аудиторами. Как-то, во время одного из аудитов класса А, ведущий аудитор начал нас спрашивать о том как внедрен один процесс, потом другой. И, фактически не получив полного совпадения с тем, что написано в «спеке», начал напрягаться. Все ссылки на «тейлоринг» напрягли его еще больше. Он чуть ли не обвинил нас в волюнтаризме. Вывод, который я сделал на основе этого случая состоит в том, что результат аудита сильно зависит от кандидатуры ведущего аудитора. 

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

Разумеется эффективность этих процессов проверяется эмпирическим путем! А как вы думали?  

Я хочу еще раз подчеркнуть, что модель в первую очередь используется как руководство (или спецификация) для улучшения процессов. Кстати, помимо руководства, в описании CMMI можно «подсмотреть» полноценные реализации некоторых процессов. Т.е. это отличная точка отстчета для начала внедрения новой практики у себя в компании.

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

На текущий момент, CMMI состоит из трех основных компонентов: CMMI Development, CMMI Services и CMMI Acquisition. Наиболее известный, CMMI Development, ориентируется на организации, занимающиеся разработкой продуктов. В дальнейшем, я буду говорить именно о CMMI Development, но для быстроты буду его называть просто CMMI.

CMMI определяет 25 процессных областей (process areas). Для каждой из процессных областей существует ряд целей (goals), которые должны быть достигнуты при внедрении CMMI в данной процессной области. Некоторые цели являются уникальными — они называются специальными (specific). Общие (generic) цели применяются к нескольким процессным областям. Цели достигаются при помощи выполнения практик; так же, как цели, практики делятся на специальные и общие. Итак, много новых определений:

Существуют два представления CMMI: непрерывное (continuous) и ступенчатое (staged).

При внедрении CMMI на непрерывной основе порядок улучшения процессных областей не фиксирован. Качество процессов в каждой процессной области может быть оценено на один из шести (0-5) уровней производительности (capability level). Ступенчатое представление определяет пять (1-5) уровней зрелости (maturity level) организации. Для достижения каждого уровня зрелости (кроме первого) необходимо выполнить требования по внедрению определенных процессных областей и достижению соответствующих целей.

Разумееется большинство крупных IT-компаний выбирают именно ступенчатое представление. Получив уровень повыше, можно аргументированно объяснять клиенту почему эта компания предпочтительнее, чем компания-конкурент. Возможно мысль несколько крамольная, но компании больше заботятся о получении определенного уровня, чем о качественном внедрении и поддержании процессов. Арифметика тут проста: поддержание процессов на проектах требует дополнительных издержек, которые, конечно, стоят денег. Исходя из своего опыта могу сказать, что трудоемкость на проекте, который использует CMMI модель, как минимум увеличивается на 10%-20%. А кто должен за это платить? Ответ однозначен: клиент. И вот тут самый сложный вопрос. Надо как-то продать клиенту увеличение трудоемкости. Существует несколько вариантов:
- прямая продажа (или продажа этих работ в лоб)
- "размазываение" необходимых издержек по другим задачам
- увеличение рейтов
Ну про первый и третий вариант говорить много не надо. Сложности тут очевидны и высказывания клиента типа "вы должны обеспечивать качество за свой счет" или "почему я должен платить за Ваши внутренние процессы" хорошо известны всем менеджерам по продажам. Если же при этом у заказчика есть специалисты, которым приходилось сталкиваться с оценками трудоемкостей по аналогичным задачам, то от них вряд ли удасться скрыть необходимое увеличение "размазав" его по другим задачам.
Поэтому многие компании делают скидку именно за счет этой "расходной статьи", тем самым экономя на качестве. 

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

By AAM

Субъективно о CMMI (начало)
Субъективно о CMMI (часть 2)