Каково влияние ITIL или CMMI на разработке? [закрытый]
Извлечение из одной из справочных ролей для установки gitlab-ce => https://github.com/geerlingguy/ansible-role-gitlab
- name: Download GitLab repository installation script.
get_url:
url: "{{ gitlab_repository_installation_script_url }}"
dest: /tmp/gitlab_install_repository.sh
validate_certs: "{{ gitlab_download_validate_certs }}"
when: not gitlab_file.stat.exists
- name: Install GitLab repository.
command: bash /tmp/gitlab_install_repository.sh
when: not gitlab_file.stat.exists
Условия здесь, чтобы остановить установку, если это уже сделано. Посмотрите на роль и другие ее задачи и значения по умолчанию для получения дополнительной информации
2 ответа
ITIL более фокусируется на инфраструктуре и стороне поддержки и не разработке, таким образом, обсуждение ITIL является, вероятно, более соответствующим на сфокусированной версии "IT" StackOverflow, который находится, предположительно, в разработке. Как в стороне, я возражаю с вызовом, что другой сайт "IT", сфокусированный как IT, охватывает инфраструктуру, поддержку и разработку на большинстве предприятий..., вероятно, хороший процент пользователей StackOverflow является разработчиками в отделах ИТ.
Я работал с CMMI и Программным процессом команды (TSP), обоими продуктами Watts Humphrey и Института программной инженерии Carnegie Mellon. Если Вы будете посвящать себя непрерывному совершенствованию и будете полагать, что измерение в основе любого непрерывного совершенствования, то Вы найдете значение в CMMI.
Очень легко сделать CMMI (и TSP) неправильно или способом который отчуждает разработчиков и в конечном счете заканчивается как оформление витрины или что-то, что выглядит хорошим на груде сертификаций. Посмотрите на поставщиков разработки в Индии... они - удивительно весь уровень 5 CMMI. То, что они не говорят Вам, это было почти всегда одним маленьким проектом или командой в их организации, которая упорно работала для получения сертификации, но повторяемые методы просто не там для 95% их организации.
Внимание на время, отслеживая (перфорация часов), отслеживание дефекта (квоты ошибки), строки кода (много способов "играть", если Вы так склонны), и создание Вашего повторяемого процесса (то, чтобы заставлять разработчика чувствовать себя подобно шестеренке без свободы ввести новшества) выключает многих разработчиков. <-отмечают утомленные контрдоводы в круглых скобках.
Факт остается, что 90% разработчиков там (немногие из которых читают StackOverflow или любые технические блоги/веб-сайты) стреляют от бедра и очень недостают самосознания того, где их возможности улучшиться находятся. Для них суровость процесса и возможность сделать последовательные усовершенствования по качеству через самосознание, которое упрощают повторение и измерение, являются ценными компонентами CMMI.
Сделанный правильно, Вы извлекаете ту же пользу из Гибких методов как Толпа, где снова фокус находится на повторяемых повторениях, извлекая уроки из каждого повторения, и улучшаясь/сужая в на Вашей цели. Требуется много зрелости и опыта привести команду в принятии или Гибкие методы или CMMI и вытащить полную стоимость из них.
Гибкий сексуально, и CMMI почти настолько совсем не сексуален, как можно добраться, который является, почему Вы не слышите об этом как очень.
Гибкое принятие имеет тенденцию быть восходящим: техники натыкаются на него и рекомендуют его управлению.
ITIL/CMMI имеет тенденцию быть нисходящим: управление натыкается на него и снижает его техникам.
Это не делает одну пользу и другой плохо; главным образом это влияет на язык, используемый для описания каждого подхода. И существует много исключений - люди с опытом в канавках, которые способны применять CMMI и менеджеров кто grok гибкий.
Google для "гибкого CMMI" и Вы получите много хитов. Я предпочитаю не рекомендовать один, в частности, потому что это - продолжающиеся дебаты (т.е. некоторые из этих людей просто неправы).
По моему мнению, понятие процесса является, конечно, полезной идеей иметь при анализе ежедневной работы разработки программного обеспечения. Идея, что существуют некоторые повторяющиеся операции, и что эти операции часто организуются в подобных последовательностях, является хорошей точкой входа для того, чтобы задать вопросам тот вывод улучшению. Можно также получить некоторый пробег путем выяснения, что повторяемо и при каких условиях операции можно назвать управляемыми.
Ошибка и излишки начинаются, когда магическое мышление начинается: "Если мы просто опишем (на бумаге) Идеальный Процесс и зарегистрируем его точно, то люди будут следовать за ним, и мы получим идеальное программное обеспечение". Это не прокладывает себе путь.