Lonewolf on CMMI

CMMI (Capability Maturity Model Integration) - это модель улучшения процесса разработки продуктов и служб. Сегодня я буду говорить о CMMI-DEV - CMMI для разработки ПО. Эта модель имеет 5 уровней (чем выше уровень - тем круче). Любая компания может за несколько десятков тыщ вызвать к себе бравую команду оценщиков и пройти сертификацию на определенный уровень.

Зачем это нужно? Ну, например, вы возглавляете аутсорсинговую компанию "Швайнске" и как раз окучиваете нового клиента. Заклинание "Наш процесс разработки сертифицирован на CMMI Level N" - это хороший способ как минимум привлечь к себе внимание, а как максимум - вполне может повлечь за собой подписание контракта на Q сладких лет.

Вот Люксофт на своем сайте заявляет о том, что имеет CMMI 5 уровня. Врут. На самом деле, пятый уровень имеет только филиал в Москве, и то не весь. У нас, как я считаю, сейчас уровень 2 (но сертификации нет никакой, так что можно мне не верить). А вообще уровни зрелости бывают такими:

Уровень 1. Начальный. Его имеют все компании, которые не прошли сертификацию. Требований на него нет. Процессы в таких организациях хаотичны, а проекты часто не укладываются в сроки или вылазят за рамки бюджета.

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

Уровень 3. Определенный. Процессы понимаются всеми и описываются в терминах стандартов, процедур, инструментов и методов - гораздо более строго, чем на уровне 2. Документы теперь стандартизованы на уровне всей организации, и никак иначе. А главное - на уровне 3 происходит следующее: конкретные личности перестают определять процесс разработки.

Теперь стоп. Дальше пока не рассказываю.

Ведь посмотрите: что происходит в мире разработки ПО последние лет дцать? Мы изо всех сил стараемся снизить влияние человеческого фактора на процесс разработки и на конечный продукт. Началось с программной инженерии, сейчас вот CMMI-DEV и аналогичные модели, имя коим - легион... Уровни 3, 4 и 5 предполагают, что если, например, команду в ответственный момент покинет ключевой разработчик, то ничего страшного не произойдет. Мы попросту заменим его другим человеком близкой по уровню квалификации, и он волшебным образом втыкнет во все сразу - потому что у нас классный процесс, документирование, процедуры и метрики.

Более того, достигнув 3 уровня, можно снижать требования к набираемому персоналу. Даже команда середнячков с правильно поставленными процессами вполне может быть успешной. А вот более низкие уровни не могут себе такого позволить - им важны конкретные личности с золотыми головами. Вот, например, Джоэль пару лет назад хвастался, как он тщательно подбирает людей в свою компанию FogCreek - и теперь вы знаете почему: у FogCreek уровень CMMI ниже нижнего.

Ставлю интересный вопрос: хорошо это или плохо? Нужно ли стремиться к получению 5 уровня? Или можно остановиться на третьем?

По мнению многих, процессы уровней 4 и 5 являются самодостаточными. Легко можно представить себе крупную компанию, сертифицированную на CMMI ML4 или ML5, в которой дни напролет работа просто кипит: пишутся отчеты, проводятся собрания, выпускаются руководящие инструкции, выполняется расчет разнообразных метрик... Только вот разработка программ как-то не очень укладывается в эту картину. Нет времени на разработку, потому как поддерживать хороший процесс - это вам не хухры-мухры, на это время нужно!

Но многие также думают, что стремиться нужно к CMMI ML3, что это хорошо, а я говорю - не очень хорошо. Почему?

1. Потому что вполне можно смириться с тем, что соседняя команда не понимает процессов в моей команде - им это и так ни к чему, у них есть свои.
   
2. Пусть каждая команда имеет свой набор документов - лишь бы им удобно работалось.
   
3. Потому что мне хочется работать с квалифицированными коллегами, а не с безликим персоналом.
   
4. Потому что я предпочту уменьшить текучку, тем самым снизив риск ухода ключевых специалистов.
   
5. И еще потому, что люди - это самое важное, что может быть в разработке софта, что бы там не втирали нам эксперты из Carnegie Mellon Software Engineering Institute. Им надо свой CMMI продавать, а нам надо работать и делать мир лучше.
   

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

Итого: как по мне, так на сертификации можно и сэкономить (если вы не директор аутсорсинга "Швайнске"). Гораздо важнее то, что в действительности происходит внутри вашей организации. И если вы часто опаздываете со сроками, оказываетесь перед необходимостью внесения изменений в последние минуты, ваши расходы растут и вы не можете точно сказать, чем занимается сотрудник вон за тем столом - попробуйте пересмотреть ваши взгляды на процесс разработки. Я смею утверждать:

1. Процесс не ограничивает свободу вашего творчества
   
2. Процесс - не то же самое, что бюрократия
   
3. Внедрение процесса оправдано в равной степени как для больших, так и для маленьких команд.
   
4. Процессы хороши даже для очень маленьких команд.
   
5. Даже если вы одиночка - вам все равно нужен процесс.
   
6. CMMI-DEV уровня 3 не так хорош, как его малюют. Часто имеет смысл остановиться на уровне 2.