Стандарты CMM

В середине 1990-х годов правительство США сделало запрос на создание метода оценки — для выбора лучших субподрядчиков в области разработки программного обеспечения (ПО). Проанализировав ситуацию с госзаказами в этой области, эксперты американского «Института программной инженерии» (Software Engineering Institute, SEI) пришли к выводу, что проблема заключалась не столько в отсутствии критериев для выбора провайдера, сколько в неспособности компаний управлять большими проектами: во многих из них разработка ПО выполнялась со значительным опозданием и превышением бюджета…

Для улучшения внутренних процессов в компаниях, занимающихся разработкой ПО, эксперты SEI совместно с Mitre Corporatio№ в 1986 году предложили свой подход — оценку зрелости процессов. Они выпустили краткий обзор процессов разработки ПО (с описанием уровней их зрелости), а также подготовили опросник, предназначенный для выявления тех участков работы, на которых требовались улучшения.

Поскольку большинство IT-компаний восприняло предложенный опросник как готовую модель для оценки качества разработки ПО, эксперты SEI доработали его до целостной модели, назвав «Модель оценки зрелости процессов компаний — разработчиков ПО» (Capability Maturity Model for Software CMM). Первая версия отраслевого стандарта СММ 1.0 была представлена в 1991 году. Американское профессиональное сообщество разработчиков поддержало идею, поэтому теперь CMM (Versio№ 1.1) активно используется во всем мире.

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

Но в то же время излишняя фиксация на контроле процессов, как правило, сопровождается бюрократизацией, что само по себе затрудняет работу, становится дополнительным риском. (По сути, этими акцентами и определяются упомянутые выше две линии методологий — «тяжелая» и «легкая».) Именно поэтому умение правильно выбрать, по какой именно методологии следует вести тот или иной проект, является показателем высочайшей квалификации специалиста.

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