Home

Автор: 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 определил строгий порядок аттестации процессов для определения того, насколько хорошо организация удовлетворяет целям каждого уровня. Аттестацию должен проводить авторизованный ведущий аттестатор.

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

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

Первоначально 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 с точки зрения специалиста по процессам в мире коробочного ПО:

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

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

Кроме беспокойств, высказанных ранее, наиболее мощным аргументом против 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 серьезно игнорирует динамики инновации.

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

• Thriving on Chaos,
• Reengineering the Corporation,
• Fifth Discipline

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

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

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

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

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

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

В этом, я уверен, суть проблемы, и главная причина, почему 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