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

Question

Я прочитал много книг о том, какие методы работают хорошо или нет в разработке программного обеспечения. И я НИКОГДА не слышал о методологиях, таких как ITIL или CMMI, ни в одной веб-трансляции, ни в книге, ни в блогах в области разработки.

Я слышал об этих методологиях в своей школе, и мне кажется, что это бюрократическая практика.

Однако все прочитанные мною книги по разработке говорят о совместной работе или о людях, имеющих дело с документацией. (Да, много гибких книг)

Итак, мой вопрос: имеют ли такие методологии, как ITIL или CMMI, какое-то влияние или связь с развитием или повседневной жизнью разработчика? И есть ли у вас отличные книги или блоги, в которых рассказывается о некоторых хороших идеях в этих методологиях, которые я могу использовать в команде разработчиков?

Answer 1

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

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

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

Сосредоточение внимания на отслеживании времени (штамповка часов), отслеживании дефектов (квоты на ошибки), строках кода (множество способов & «игры»! », если вы так склонны) и выполнении процесса повторяемый (заставляющий разработчика чувствовать себя винтиком без свободы для нововведений) отключает многих разработчиков. < - обратите внимание на изогнутые контраргументы в скобках.

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

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

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

Answer 2

Гибкое усыновление имеет тенденцию быть восходящим: технические специалисты сталкиваются с ним и рекомендуют его руководству.

ITIL / CMMI имеет тенденцию быть нисходящим: руководство натыкается на него и доводит его до технических специалистов.

Это не делает одно хорошим, а другое плохим; в основном это влияет на язык, используемый для описания каждого подхода. И есть множество исключений - люди с опытом работы в окопах, которые хорошо умеют применять CMMI, и менеджеры, которые работают гибко.

Google для " гибкая CMMI " и вы получите много хитов. Я предпочитаю не рекомендовать один конкретный, потому что это постоянные дебаты (то есть некоторые из этих людей просто неправы).

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

Ошибка и излишки начинаются, когда начинается магическое мышление: & Если мы просто опишем (на бумаге) Идеальный процесс и точно запишем его, люди последуют за ним, и мы получим идеальное программное обеспечение. & Quot; Это не работает таким образом.