Каково влияние ITIL или CMMI на развитие? [закрытый]

ITIL больше ориентирован на инфраструктуру и поддержку, а не на развитие, поэтому обсуждение ITIL, вероятно, более уместно в "IT" - ориентированной версии StackOverflow, которая предположительно находится в разработке. В стороне, я возражаю, называя этот другой сайт" ИТ", поскольку он охватывает инфраструктуру, поддержку и развитие на большинстве предприятий...вероятно, хороший процент пользователей StackOverflow являются разработчиками в ИТ-отделах.

Я работал с CMMI и командный программный процесс (TSP), оба продукта Уоттса Хамфри и Института программной инженерии Карнеги-Меллона. Если вы привержены непрерывному совершенствованию и считаете, что измерение лежит в основе любого непрерывного улучшения, тогда вы найдете Ценность В CMMI.

очень легко сделать CMMI (и TSP) неправильно или таким образом, что отчуждает разработчиков и в конечном итоге заканчивается как оформление витрин или что-то, что хорошо выглядит на куче сертификатов. Посмотрите на поставщики разработок в Индии...они чудесным образом все CMMI уровня 5. Они не говорят вам, что почти всегда был один небольшой проект или команда в их организации, которая упорно работала, чтобы получить сертификацию, но повторяемые практики просто не существует для 95% их организации.

фокус на отслеживать времени (пробивать часов), отслеживать дефекта (квоты ошибки), строки кода (серии путей "игры" если вы так склонны), то, и делать ваш процесс repeatable (делающ a разработчик чувствует себя винтиком без свободы инноваций) отключите многих разработчиков.

факт остается фактом, что 90% разработчиков (немногие из которых читают StackOverflow или любые технические блоги/веб-сайты) стреляют из бедра и остро не осознают, где находятся их возможности для улучшения. Для них процесс строгости и возможность сделать постепенные улучшения качества за счет самосознания эти повторение и измерение облегчают ценные компоненты CMMI.

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

Agile сексуален, и CMMI примерно так же далек от сексуальности, как вы можете получить, вот почему вы не слышите об этом так много.