CMMI (Capability Maturity Model Integration) (Рубрика Management)
Когда я только начинал свою карьеру как инженер на слуху были модели зрелости для процессов разработки софта, а конкретнее CMMI. Сегодня я решил вспомнить историю этой модели и границы применимости, так как в последнее время я вижу большое увлечение разными моделями зрелости, например, KMM или ACMM. Я расскажу про них подробнее в следующий раз, а сегодня давайте поговорим про CMMI.
Изначальную версию CMM (Capability Maturity Model) разработал SEI (Software Engineering Institute) внутри Carnegie Mellon University в конце 1980х годов для Department of Defense. Цель была в том, чтобы улучшить практики разработки софта в этом ведомстве. К 2000 году CMM объединило в себе разные модели зрелости и расширилось на еще одно слово Integration, чтобы выйти в свет в виде модели CMMI и увеличить границы применимости.
Фреймворк строился вокруг концепций возможностей и зрелости
- Возможности относились к способностям организации достигнуть бизнес-цели через хорошо выстроенные процессы
- Зрелость отображала концепцию эволюции процессов во времени от ad-hoc до файнтюна и вылизывания выстроенных процессов:)
Фокус был на определении, имплементации и непрерывном улучшении процессов для обеспечения консистентности и эффективности. Фреймворк включал цели и лучшие практики для помощи в движении к лучшим процессам. В нем были следующие уровни зрелости
- Initial: непредсказуемые и реактивные процессы (условно реакция по факту произошедшего события)
- Managed: процессы планируются и выполняются с учетом политик
- Defined: процессы хорошо описаны и стандартизированы
- Quantitatively Managed: процессы измеримы и контролируются с учетом статистических методов
- Optimizing: фокус на улучшении процессов через инновации
Адепты этого подхода упирали на плюсы фреймворка 1) Increased efficiency and productivity - это достигалось за счет стандартизации и оптимизации, что приводило к выравниванию workflow и лучшему распределению ресурсов 2) Quality improvement - предполагалось выравнивание процессов на требования заказчиков для повышения качества продуктов и удовлетворенности клиентов 3) Competitive advantage - достижение высоких уровней зрелости выделяло компании на рынке, что показывало их приверженность лучшим практикам (||особенно актульно для сервисных компаний, что делают проекты на заказ||) 4) Scalability - фреймворк позволял организациям масштабироваться по мере роста и наработки какой-то специфики
А среди недостатков выделяли 1) Complexity and cost - имплементаци CMMI была комплексной, требовала кучу времени и была дорогой из-за выделения значительных ресурсов, тренировок и документации 2) Rigidity - модель была негибкой, а также предотвращала внедрение новых практик и технология, что появлялись после ее внедрения 3) Bureaucracy - модель требовала значительного количества документов, что повышало уровень бюрократии и снижало гибкость и креативность (||ака без бумажки ты букашка||) 4) Lack of customizability - эта общая модель не всегда хорошо натягивалась на любую организацию (||например, на bigtech компании, что взлетали в начале 2000-х||), что ограничивало такие организации, если они пытались внедрить CMMI
В итоге, я видел внедрения CMMI в начале 2000х в сервисных компаниях (||галерах||), которые работали на рынке заказной разработки, но не слышал ни про одну bigtech компанию, принявшую эту модель. Я думаю, что причина в том, что на вопрос "А какую проблему мы решаем" эта модель CMMI не дает никакого ответа внутри продуктовой компании.
Я думаю, что надо фокусироваться на конкретных практиках, что решают конкретные проблемы, например,
- Процесс написания RFC и фиксация арх решений в ADR
- Ведение техрадара в организации
- Как работать с надежностью систем: observability, SLI/SLO/SLA, бюджет ошибок
- и так далее
Но вот в упор не могу понять на...я выбивать уровень 5 CMMI кроме как порадовать своего внутреннего бюрократа.
#Processes #Management #Metrics #Leadership #Software