Модель CMMI. Cmm что это

Модель CMMI / Хабр

Всем здравствуйте! Наконец-то я на Хабре. Постараюсь незамедлительно начать приносить пользу если не всему сообществу, то хотя бы некоторой его части:)

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

Что такое CMMI?

Википедия даёт следующее определение:Capability Maturity Model Integration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Откуда появилась эта модель?

Собственно, сначала появилась просто CMM, а CMMI явилась результатом последовательного развития первоначальной модели, поглотившей при этом ряд других. В середине 1980-х годов перед министерством обороны США встала проблема повышения качества разрабатываемого по их заказу ПО. Согласитесь, вам и самим было бы спокойнее жить, зная, что ни одна американская ракета не полетит случайно в сторону вашего дома? Кроме того, поскольку деньги были бюджетные, а бюджет обычно плановый и не резиновый, помимо качества разработки от исполнителя требовалось ещё и выполнение заказа точно в срок и в рамках установленного бюджета.

Проблема была решена следующим образом: созданием модели, на соответствие которой оценивались все потенциальные исполнители заказа министерства обороны. Задача разработки этой модели была возложена на Software Engineering Institute, созданный на базе Carnegie Mellon University, который в свою очередь расположен в славном городе Питтсбурге штата Пенсильвания.

Для создания этой модели был проведён анализ ключевых активностей, выполняемых при разработке ПО, и связанных с ними рисков. Анализировались как best practices – практики, которые позволили успешно избежать или смягчить тот или иной риск, так и worst practices – типичные ошибки, совершение которых приводит к проблемам в качестве, срыву сроков и превышению бюджетов. Для каждой ключевой активности (или цели) модель предлагает ряд практик, которые позволяют снять или существенно уменьшить соответствующие проектные риски. И все активности были сгруппированы в т.н. процессные области. В 1987 году появился прообраз будущей модели – на самом деле анкета, которая содержала всего 85 процессных и 16 технологических вопросов, ответы на которые и определяли оцениваемую компанию к одному из пяти уровней зрелости.

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

Кстати, уровни зрелости…

Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI.

Процессы первого уровня зрелости характеризуются хаотичностью, реактивностью, непредсказуемостью. Несмотря на это, очень часто организации, находящиеся на данном этапе развития, производят довольно качественные продукты. При этом, как правило, превышается бюджет и время разработки данных продуктов. Качественные продукты данных организаций производятся не за счет устойчивых и отлаженных процессов, а благодаря титаническим усилиям отдельных личностей. В случае ухода таких людей очень тяжело повторить успешные проекты. На данном этапе очень тяжело предсказать производительность процессов, протекающих в организации. На уровне 1 производственный процесс (а вместе с ним и все процессы) представляется аморфной сущностью, практически черным ящиком, представление о процессах очень ограниченное, чрезмерно много усилий тратится на выяснение статуса развития проекта и текущего хода работ. В принципе, для небольших компаний, разрабатывающих собственные проекты или небольшие проекты по заказу – это приемлемо. Но для них и не нужна никакая модель CMMI. Эта модель показывает себя во всей красе при разработке действительно больших проектов. И поэтому мы идём дальше по лестнице уровней зрелости.

Уровень зрелости 2 – управляемый уровень. На данном этапе основные процессы описаны, их, возможно, использовать неоднократно. Другими словами, проекты, выполняемые организацией, отвечают требованиям. Процессы управляемы, они планируются, выполняются, измеряются и контролируются. Однако процессы все же имеют некоторую долю реактивности в своей сущности. На уровне 2 контролируются требования заказчиков и промежуточные продукты, а также установлены основные практики управления проектом. Эти средства позволяют управлять проектом, однако дают фрагментарное представление о нем. Фактически, производственный процесс можно представить последовательностью черных ящиков и реальное видение проекта присутствует лишь на промежуточных этапах.

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

Уровень зрелости 4 – количественно-управляемый уровень. На данном этапе достигнуты все цели предыдущих уровней. Выбраны субпрактики, которые при использовании статистических методов и других количественных техник позволяют контролировать качество выполнения процессов. Самое главное отличие этого этапа от предыдущего заключается в предсказуемости эффективности процессов и возможности ею (эффективностью) управлять. На уровне 4 определенные процессы количественно контролируются с помощью соответствующих средств и техник.

Уровень зрелости 5 – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.

…и процессные области.

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

А вот и список процессных областей с краткой расшифровкой названия каждой:

Менеджмент требований (Requirements Management) Управление требованиями предъявляемым к продуктам проекта или компонентам продукта, с целью выявления несоответствия между требованиями и планами проекта.
Планирование проекта (Project Planning) Разработка и поддержание планов определяющих развитие проекта.
Мониторинг и контроль проекта (Project Monitoring and Control) Обеспечение понимания стадии разработки проекта с целью принятия корректирующих действий в случае серьезного отклонения от плана.
Менеджмент договоров с поставщиками (Supplier Agreement Management Управление приобретением товаров и услуг от внешних поставщиков, с которыми заключены договоры.
Измерение и анализ (Measurement and Analysis) Разработка и поддержание возможности измерения, используемой для поддержки нужд информационного менеджмента.
Оценка (гарантирование) качества товаров и процессов (Process and Product Quality Assurance) Обеспечение поддержки и управления в соответствии с целями процессов и связанными с ними продуктами работы.

Конфигурационный менеджмент (Configuration Management) Установка и поддержание целостности продуктов работы (work products) в результате использования идентификации конфигураций, конфигурационного контроля и конфигурационного аудита.
Разработка требований (Requirements Development) Сбор и анализ требований потребителей к продуктам и компонентам продуктов.
Техническое решение (Technical Solution) Разработка, дизайн и внедрение решений по соответствующим требованиям. Решения, дизайн и внедрения выражены продуктами, компонентами продуктов и связанными с данными продуктами процессами.
Интеграция продукта (Product Integration) Сборка (монтирование) продукта из его составляющих, проверка качества интеграции, ее функциональности и выпуск продукта.
Верификация (Verification) Гарантирование того, что выбранные продукты работы отвечают предъявляемым требованиям.
Валидация (Validation) Демонстрация того, что продукт и его компоненты соответствуют его предполагаемому использованию в предполагаемой среде.

Фокусирование на процессах организации (Organization Process Focus) Установление и поддержание понимания процессов организации и процессных активов, идентификация, планирование и внедрение улучшений связанных с данными областями.
Описание процессов организации (Organization Process Definition) Установление и поддержание возможного к использованию массива процессов организации.
Организационный тренинг (Organizational Training) Повышение знаний и способностей людей для выполнения ими своих ролей эффективно и рационально.
Менеджмент интеграции проектов (Integrated Project Management) Установка и управление проектом и вовлечение всех заинтересованных лиц в интегрированный и определенный процесс. Данная область также затрагивает общее видение проекта командой разработчиков.
Менеджмент рисков (Risk Management) Определение потенциальных проблем до их появления. В связи с этим процессы по снижению рисков могут планироваться и осуществляться на любом этапе разработки продукта или процесса.
Интегрированные команды (разработчиков) (Integrated Teaming) Формирование и поддержание интегрированных команд для разработки продуктов работы (work products).

Интегрированное управление поставщиками (Integrated Supplier Management) Мониторинг новых продуктов, оценка источников продуктов, которые могут удовлетворить требованиям к проекту и использование данной информации для выбора поставщиков.
Анализ решений и разрешение(Decision Analysis and Resolution Разработка решений на основе структурированного подхода, который позволяет оценить альтернативные решения на основе установленных критериев.
Организационная среда для интеграции (Organizational Environment for Integration) Предоставление инфраструктуры для интегрированной разработки продуктов и процессов и управление людьми (персоналом) в целях интеграции
Производительный организационный процесс (Organizational Process Performance) Установление и поддержание количественного понимания производительности набора стандартизированных процессов организации и обеспечение информацией о производительности процессов и моделей для количественного управления проектами организации.
Количественный менеджмент проекта (Quantitative Project Management) Количественно управлять определенным процессом в целях достижения установленного в рамках проекта качества и целей производительности.

Организационные инновации и внедрение(Organizational Innovation and Deployment) Выбор и внедрение инноваций и улучшений, которые измеряемо, улучшают организационные процессы и технологии.
Анализ причин и разрешение (Causal Analysis and Resolution) Идентификация причин дефектов и других проблем и принятие действий предотвращающих их появление в будущем

И зачем эта модель нам?

Использование модели CMMI позволяет организации оценить эффективность процессов, установить приоритетные направления их усовершенствования, а также внедрить данные усовершенствования.

Внедрение СММ/CMMI позволяет улучшить структуру и качество процессов (основные проблемы в программных разработках — это проблемы управления, а не технические проблемы), обеспечить стабильно высокое качество разработок и освоить процессы, которые могут служить основой для повышения конкурентной способности и дальнейшего развития и расширения компании.

В основе CMM/CMMI лежит понятие процесса. Принятие этой концепции помогает избежать естественной для многих организаций тенденции винить в неудачах людей. Увольнение сотрудников — не решение проблемы. За последние десятилетия произошли революционные изменения в технологии, однако проблемы успешного выполнения проекта остались. В этом аспекте технология также не решение проблемы. Ценность процесса в том, что он помогает уловить и использовать наивысшие достижения в будущих проектах. Именно на этой предпосылке и базируется CMMI.

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

Итог?

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

habr.com

Основные понятия и значения CMMI

Область процесса

Назначение

CAR – Анализ и разрешение причин	Изучите основную причину проблем исключительного процесса (варьирование специальных причин, Эдвардса Деминга), а также предложить изменения процесса реализации для предотвращения повторения. Внимание направлено на необычное поведение стабильных процессов, рассмотренных в количественном отношении. Ежедневные сюрпризы, скорее всего, будут считаться частью управления рисками (RSKM), а не значениями CAR.
CM – Управление конфигурацией	Будучи не просто системой управления версиями, эта область процесса охватывает все задачи администрирования, связанные с системными средами, конфигурациями компонентов, платформами, ПО промежуточного слоя, приложениями и документацией. Способность успешно выполнить построение и развертывание работающего кода подпадает под эту область процесса.
DAR – Анализ и разрешение решений	Для всех ключевых решений в проекте или разработке продукта укажите, что рассмотрен набор альтернатив или вариантов и для определения пригодности различных вариантов использовались контекстные элементы. Запишите решение и причины выбора.
IPM - Интегрированное управление проектами	Этот второй уровень управления проектом внутри модели CMMI подразумевает, что организация может управлять несколькими потенциально зависимыми проектами одновременно. Часто это достигается с помощью использования программы или офиса управления портфелем.
MA – Измерения и анализ	Сбор данных о процессе, проекте и характеристиках продукта. Получение показателей и индикаторов в виде отчетов на основе данных.
OPD - Определение организационных процессов	Организация должна иметь одно или несколько определений процессов, которые определяются в пределах контекста. Контекст опишет профиль риска. Каждый проект можно оценить по его рискам и определению процесса, выбранного из организационного каталога, а затем соответствующим образом подогнать его.
OPF – Фокус организационных процессов	Организация должна верить, что определение процесса определяет способность и влияет на нее, и что улучшение способности достигается в первую очередь за счет усовершенствованного процесса. Таким образом, организация активно управляет определениями и мониторами своих процессов (используя область процессов PPQA), чтобы гарантировать соблюдение этих определений.
OPM — управление организационными процессами	Эта область процесса инкапсулирует понятие статистического понимания, насколько хорошо процесс работает относительно его ожидаемых возможностей. Если наблюдаемые результаты не соответствуют спрогнозированным базовой моделью процесса при внесенном изменении в определение процесса, можно проанализировать изменения в процессе, предназначенные для улучшения возможностей, и рассмотреть базовую модель процесса. Организация управляет своей производительностью посредством своих процессов для удовлетворения своих бизнес-потребностей.
OPP – Производительность организационных процессов	Эта область процесса инкапсулирует понятие сравнения производительности, обычно называемого «контрольное тестирование». OPP создает модели процесса на основе базовых данных, чтобы включить сравнение. Это дает организации возможность ответить на вопросы такие как "Какую из наших трех команд продуктов нам нужно выбрать для [этого конкретного проекта]?"
Organizational Training	Индивидуальная возможность в определенных случаях важна для производительности процесса и возможностей системы. Хорошо функционирующая система с высокой производительностью будет иметь высокую способность к обучению для уменьшения изменчивости на уровне локальной практики.
Интеграция продуктов	Возможность интеграции нескольких компонентов для формирования целостного продукта и управление необходимыми для этого элементами.
Мониторинг и контроль проектов	Соберите данные о выполняющихся проектах, сравните их с планами, проекциями и моделями и выполните необходимые действия на основе этих данных.
Планирование проектов	Планирование проекты на основе оценок, имитаций и анализа требований.
Контроль качества процессов и продуктов	Главным образом функция аудита соответствия процессу. Предназначено для демонстрации того, что система работает как запланировано. Помогает избежать потенциальных ошибок управления, заключающихся в изменении процесса для устранения проблемы, когда фактически текущий процесс не выполняется, как предусмотрено.
Количественное управление проектами	Это третий и самый высокий уровень управления проектом внутри модели CMMI. Это означает, что статистически достоверные количественные методы используются для планирования, мониторинга и управления проектами.
Разработка требований	Существует определенный, воспроизводимый процесс истребования, обсуждения, анализа и документирования требований.
Управление требованиями	Требования отслеживаются на протяжении всего жизненного цикла проекта, и в идеале существует полная прослеживаемость между поставленной конфигурацией и изначальным запросом-требованием.

msdn.microsoft.com

Незрелость СММ (The Immaturity of CMM)

Автор: James Bach

Перевод: С.Гольдберг (републикация www.bcc.ru)

Известно, что SEI (Software Engineering Institute in Carnegie Mellon University) основан Министерством Обороны США, чтобы управляться с десятками миллионов долларов ежегодно. Обитатели SEI — знатоки официальных военных процессов, и имеют ресурсы для оповещения мира о своей деятельности. Еще известно, что CMM (Capability Maturity Model) — это широкий и более глубокий набор утверждений, составляющих хорошую практику разработки ПО. Резонно спросить, откуда эти утверждения пришли и действительно ли они полны и корректны.

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

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

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

Краткое описание CMM

CMM была задумана Watts-ом Humphrey, который отталкивался от более ранней работы Phil-а Crosby. Активное развитие модели началось SEI с 1986 года.

CMM состоит из группы ключевых практик — «key practices» — ни новых, ни уникальных, разделенных на 5 уровней, которые организация должна пройти, чтобы стать «зрелой». SEI определил строгий порядок аттестации процессов для определения того, насколько хорошо организация удовлетворяет целям каждого уровня. Аттестацию должен проводить авторизованный ведущий аттестатор.

Уровни зрелости таковы:

№LevelУровеньОписание

1.	Initial	Начальный	Chaotic, ad hoc, heroic (хаотичный, специфический, героический)
2.	Repeatable	Повторяемый	Project management, process discipline (есть управление проектом и дисциплина процесса)
3.	Defined	Определенный	Institutionalized (учрежденный)
4.	Managed	Управляемый	Quantified (дискретный)
5.	Optimizing	Оптимизируемый	Process improvement (есть улучшения процесса)

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

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

Коммерческие компании — Borland, Claris, Apple, Symantec, MS, Lotus... — очень редко (или никогда) работают с требуемыми документами так формально, как это описано в CMM. Это требование достижения уровня 2, и значит, все эти компании должны упасть до уровня 1 модели...

Критика CMM

Здесь не будет полной критики CMM, но вот два заслуживающих внимания критика: Capers Jones & Gerald Weinberg.

В книге Assessment & Control of Software Risks Jones предлагает свою модель — SPR (Software Productivity Research), — которая была разработана независимо от CMM и приблизительно в тоже время. Jones посвятил главу критике CMM. SPR учитывает многие факторы, которые CMM игнорирует. Например, таким, как вклад в продуктивность индивидуальных инженеров.

В двухтомной монографии Quality Software Management Weinberg описал сильную концепцию зрелости, применимую к процессам создания ПО и основанную на парадигме шаблонов поведения. Эти модели Weinberg-а основаны на взаимодействии между людьми, а не между формальными конструкциями. Его подход основан на эволюции «руководства по решению проблем», а не на консервативных процессах.

Главные проблемы, связанные с CMM

Далее перечислены не все, но самые крупные проблемы CMM с точки зрения специалиста по процессам в мире коробочного ПО:

CMM не имеет формальной теоретической базы. Она основана на опыте «очень знающих специалистов». Однако, такая теория д.б., т.к. эксперты знают, что они делают. В соответствии с этим принципом, любая другая модель, основанная на опыте других знающих людей, имеет такую же достоверность.
CMM имеет только неясную эмпирическую поддержку. Значит, эмпирическая поддержка CMM может также истолковываться и как поддержка других моделей. Модель основана на опыте больших правительственных подрядчиков и собственном опыте Watts-а Hemphrey в мире мэйнфреймов. Она не учитывает успех коробочных компаний. Уровни 1, 4 и 5 не представлены с хорошей информативностью: первый, потому что он просто не презентабелен, а другие два — т.к. есть всего несколько организаций, достигших этих уровней. Представитель SEI Mark Paulk цитировал многочисленные отчеты в поддержку CMM и рассказывал мне, что стадия формального подтверждения разрабатывается. Это замечательно, но те анекдотические отчеты, которые я видел, (они касались успеха использования CMM) могли быть использованы и как доказательство успеха группы работающих людей для достижения чего угодно. Другими словами, без сравнения с альтернативными моделями процессов под контролируемыми условиями, эмпирический вариант никогда не будет закрыт. Напротив, остается вариант реальных контрпримеров в форме действующих организаций уровня 1. Есть и курьезные утечки информации об ошибках CMM, что можно объяснить нежеланием части компаний останавливаться на своих ошибках или SEI — регистрировать их.
CMM чтит процесс, но игнорирует людей. Это ясно для того, кто знаком с работой Weinberg-а, для которого проблемы взаимодействия людей определяют инженерию. По контрасту, и Hemphrey, и CMM, упоминают людей походя, порицая их как ненадежный элемент, и допуская, что определенные процессы могут чем-то помочь, чтобы сделать индивидуальное превосходство менее значимым. Идея, что процесс может помочь заурядности, является опорой CMM, когда люди второстепенны по отношению к процессам. Но где же оправдание этого? Чтобы сделать превосходство менее важным, проблема решения задач должна быть каким-то образом внедрена в сам процесс. Я никогда не видел такого процесса, но если он существует, то д.б. очень сложным. Представьте процесс определения воспроизводимой хорошей игры в шахматы. Таковой существует, но полезен только для компьютеров. Процесс, полезный для людей, никогда не был задокументирован и не постулировался, как последовательность точных шагов. Разве проблемы разработки программ, по меньшей мере, не столь же сложны, как проблемы шахмат?
CMM почитает институализацию процессов ради них самих. Т.к. CMM принципиально концентрируется на способности организации к изменению, такое предубеждение непонятно. Но, способность организации к изменению — это просто выражение способности проектной команды действовать. Даже если необходимые процессы не утверждены формально, они м.б. очень хороши на практике (неформально) благодаря умению членов коллектива. Институализация ничего не гарантирует. Усилия по интституализации часто ведут к раздвоению между сверхупрощенным публичным процессом и богатым частным процессом, который должен практиковаться тайно. Даже если интситуализация полезна, то почему бы не утвердить систему для идентификации и поддержки ключевых сотрудников организации, оставив ради них процессы в стороне.
CMM содержит очень мало информации о динамиках процесса. Это делает сбивающей с толку дискуссию о соотношении между практиками и уровнями со сторонниками CMM, т.к. имеются скрытые допущения. Например, почему совсем нет тренинга на 1-м уровне? Тренинг особенно важен на 1 уровне, где он м.б. в форме наставничества, или как тренинг любых умений в инженерии ПО. Ответ состоит в том, что на 1 уровне нет ничего (он просто определен, как не уровень 2). Скрытое допущение состоит в том, что не имеет значения, кто вы, с какими проблемами вы столкнулись, и что вы уже делаете. Просто идем прямо на уровень 2. Иными словами, CMM не адаптируется к условиям клиенто-ориентированных организаций. Поэтому тренинги и иные неформальные практики уровня 1 (как бы эффективны они ни были) м.б. случайно раздавлены слепым и статичным CMM. Другой пример, почему уровень 5 защищен от дефектов? Мы используем в Borland похороны (post mortems) проекта для анализа и улучшения наших процессов — разве это не форма предотвращения дефектов? Я могу привести много подобных примеров, читая CMM. Хотя я не анализировал документ по Key Practices и приложение к Managing Software Process (Humphry). Главное, большинство ключевых практик (а м.б. и все) могут весьма пригодиться на уровне 1 в зависимости от конкретных изменений в конкретной организации. Вместо актуального моделирования этих динамик процессов (чем занят Weinberg), CMM просто наслаивает их.
CMM потворствует смещению целей с реальной миссии улучшения процессов на искусственную миссию достижения более высокого уровня зрелости. Я называю это «уровнем зависти», и этот путь обычно ослепляет организацию на пути наиболее эффективного использования ее ресурсов. SEI осознает эту проблему и предпринимает некоторые шаги для ее корректировки. Но проблема гнездится в самой структуре модели, а по сему очень трудно изгнать нечистую силу.

На глиняных ногах: Фундаментальное непонимание CMM организаций уровня 1

Мир технологий процветает лучше всего тогда, когда индивидуальности остаются разными, творческими и непокорными — Don Valentine, Silicon Valley Venture Capitalist

Кроме беспокойств, высказанных ранее, наиболее мощным аргументом против CMM, как эффективного предписания для процессов создания ПО, является существование многих успешных компаний, которые по CMM вообще не должны существовать. Это особенно ясно, если взглянуть на зады (театральный задник) Силиконовой Долины. Tom Peter’s Thriving on Chaos причисляют к манифестам Силиконовой Долины. Он помещает инновации, действующие нелинейно и революционно, в центр своего видения этого мира. В Долине инновации имеют наивысший приоритет. И эта выгодная позиция новатора является как раз тем, что CMM утеряла в наибольшей степени. Личный опыт в Apple и Borland, и контакты со многими другими здесь только подтвердили этот вывод.

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

По существу, в CMM вообще нет инноваций, а появляются они только на уровне 5. Это шокирует, т.к. многие инновационные фирмы в компьютерной индустрии работают на уровне 1 в соответствие с моделью. Например, General Magic — пионер в персональной цифровой технологии коммуникаций. Сюда же можно отнести и Microsoft и, конечно, Borland. В терминологии CMM нет разницы между этими фирмами и компаниями, рухнувшими на старте, или сталелитейными компаниями. В противоположность этому такие компании, как IBM, которая по всем подсчетам сотворила настоящую путаницу в Federal Aviation Administration’s Advanced Automation Project, стоит высоко в терминах зрелости (по словам члена правительственной команды аудита).

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

Такие динамики задокументированы в хорошо известных книгах по инновационному бизнесу:

Там, где новаторы советуют компаниям быть гибкими, CMM советует быть предсказуемыми.

Там, где новаторы предлагают снизить власть в организации, CMM выдвигает ее наверх.

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

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

Героизм, наиболее общо практикуемый успешными компаниями уровня 1, является чем-то большим, чем мистикой. Наш героизм означает взятие инициатив по решению амбициозных проблем. Это не означает, что надо зажечь людей, а потом выбросить их, как трактует SEI. Героизм — это определенный и изучаемый набор поведений, который усиливает и делает почетной способность творить (как элемент United Technologies Microelectronics Center). Он и средство общения, и способ взаимного признания. Он означает селективное развертывание процессов, но не в соответствии с мандатом на управление, а в соответствии с умениями команды.

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

"Есть очевидные причины, почему компании сопротивляются поддержке персонального мастерства. Это «soft», основанный частично на неквантируемых концепциях — таких, как интуиция и персональное видение. Никто никогда не способен измерить с помощью 3-х измерений, в какой степени персональное мастерство влияет на продуктивность и на практический результат. В материалистической культуре, как наша, трудно даже обсуждать некоторые предпосылки индивидуального мастерства. «Почему люди нуждаются в беседе об этой чепухе», - может спросить кто-то. «Разве это не очевидно? Разве мы уже не знаем это?»"

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

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

Альтернатива CMM

Если не модель зрелости, то какой каркас может служить нам истинным путеводителем в процессе улучшений?

Альтернативный каркас можно найти в родовой форме в книге Thriving on Chaos, которая содержит 45 предписаний. Или в Fifth Discipline, где представлены — как это ни странно — именно 5 дисциплин. Предписания из Thriving on Chaos внедрены в организационный инструмент, названный The Excellent Audit. Теперь доступна и книга The Fifth Discipline Fieldbook, где дано дополнительное направление для создания обучающихся организаций.

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

Если же касаться специфики программной инженерии, то замечу, что я работал над процессной моделью в Borland, которая состояла из семиразмерного каркаса для анализа проблем и идентификации необходимых процессов. Этими измерениями были: бизнес факторы, факторы маркетинга, проектные комплектующие узлы, 4 первичных процесса (обязательство, планирование, осуществление, сходимость), команды, инфраструктура процесса, и контрольные точки.

Каркас был связан с множеством масштабируемых «процессных циклов». Циклы процесса — это повторяемые шаг за шагом рецепты для осуществления определенных общих заданий.

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

Ключом в этой модели является то, что циклы процесса являются зависимыми от эвристик каркаса. Главное здесь — помочь вынести решение, а не предписания для устанавливающих формализмов. Структура каркаса в виде двухразмерной сетки помогает в процессе подгонки и при поиске ответов на вопросы типа «что, если...?»

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

После всего этого ей ничего не остается, как быть незрелой.

Postscript 02/99

За 5 прошедших лет ни CMM, ни мое отношение к ней заметно не изменились. Оборонная индустрия продолжает поддерживать CMM. Некоторые коммерческие IT-организации следуют ей, многие другие — нет. Программные компании, участвующие в великой технологической гонке нашего времени — Интернете — игнорируют эту модель на своих путях. Учение, утверждающее, что CMM имеет большое значение, не рассматривает альтернатив. Оно оставляет в стороне критическую информацию, предлагающую проводить полный анализ того, что происходит в компаниях, которые претендуют на продвижение вверх по уровням CMM, для получения преимуществ.

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

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

За последние несколько лет я прошел обучение в Jerry Weinberg классах по искусству управления и изменения: Problem Solving Leadership и Change Shop. Я стал участником его Software Engineering Management Development Group программы и форума SHAPE. Информация об этом доступна по адресу: http://www.geraldweinberg.com. По моему мнению, работы Jerry продолжают оставаться прекрасной альтернативой парадигме CMM. Менеджеры сначала должны научиться видеть, слышать и понимать человеческие системы прежде, чем они могут надеяться управлять ими. Все дело в том, что программные проекты — это человеческие системы.

Одно последнее замечание. Добавьте к своему списку для чтения работу The Logic of Failure (Dietrich Dorner). Dorner анализирует, как люди овладевают искусством управления сложными системами. Без упоминания развития ПО или зрелости способности (capability maturity), это яркий аргумент против философии CMM (если найдете).

The article was originally published in the September’94 issue of American Programmer