Практика. В каких организациях и на каких проектах лучше всего работает CMMI?

В каких организациях и на каких проектах лучше всего работает CMMI? Для того чтобы понять это, необходимо выделить основные характеристики модели.

CMMI вполне заслуженно считается тяжеловесной методологией, причем требует ощутимых затрат как во время, так и после внедрения. Тяжеловесность процессов нарастает с продвижением по уровням зрелости. Уже первый из интересных в практическом смысле уровней зрелости – уровень 3 – требует значительных усилий по обучению проектной команды, ведению проектной документации, периодическому аудиту процессов.

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

Что получает организация в обмен на усилия и ресурсы, потраченные на внедрение CMMI? Прежде всего, предсказуемость сроков и бюджета выполнения более или менее аналогичных проектов. Точность планирования – это основная цель 3 и 4 уровней зрелости CMMI, эффективность разработки становится ключевым фактором лишь на уровне 5. Благодаря хорошо документированным процессам и промежуточным результатам работ становится возможным быстро подключать к проекту новых сотрудников (возможно, более типичная ситуация – заменять ушедших).

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

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

Очевидно, что не имеет большого смысла использовать CMMI для одного или нескольких отдельных проектов. Внедрение должно происходить во всей организации, департаменте и т.д.

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

Выводы

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

Несомненно, область процессной инженерии еще далека от зрелости и в ближайшем будущем будут созданы новые методологии. Также имеет смысл обратить внимание на методологию Microsoft Solutions Framework (MSF). Это гибкая и достаточно легковесная методология, построенная на итеративной модели разработки. Привлекательной особенностью MSF является большое внимание к созданию эффективной и небюрократизированной проектной команды. Для достижения этой цели MSF предлагает достаточно нетрадиционные подходы к организационной структуре, распределению ответственности и принципам взаимодействия внутри команды.

Интересным примером является OpenUP – семейство открытых (в отличие от проприетарного RUP) процессов, создаваемое в рамках проекта Eclipse Process Framework (EPF). Процесс OpenUP/Basic основан на принципах RUP, максимально упрощенного для гибкой разработки небольших проектов. Одновременно с ним развивается OpenUP/MDD, следующий методологии разработки через моделирование (Model Driven Development).

OpenUP/Basic и OpenUP/MDD реализуются в виде расширений EPF Composer, средства для создания и настройки процессов. Пользователи EPF Composer могут создавать свои процессы, используя в качестве компонентов фрагменты процессов, доступные в расширениях наподобие OpenUP/Basic и OpenUP/MDD.