Кто-нибудь еще верит в модель зрелости программного обеспечения?
Десять лет назад, когда я впервые столкнулся с CMM для программного обеспечения, я, как и многие другие, был поражен тем, насколько точно он описывал хаотическое состояние "разработки первого уровня" во многих компаниях, особенно в том, что касается ссылки на героев. Казалось также, что это дает реалистичное руководство для организации по повышению уровня, улучшающего их процессы.
Но хотя это казалось хорошей моделью и реалистичным руководством для улучшений, я никогда не был свидетелем того, как присоединение к CMM оказало существенное положительное влияние на любую организацию, в которой я работал или с которой. Мне известна одна крупная консалтинговая компания по программному обеспечению, которая претендует на уровень CMM 5 - наивысший уровень - когда я воочию вижу, что их процессы столь же хаотичны, а качество их программных продуктов столь же разнообразно, как и другие компании, не относящиеся к CMM.
Поэтому мне интересно, видел ли кто-нибудь реальную, ощутимую выгоду от приверженности улучшению процессов в соответствии с CMM?
И если вы видели улучшение, думаете ли вы, что улучшение было конкретно связано с CMM, или альтернативный подход (такой как шесть сигм) был бы одинаково или более выгодным?
Кто-нибудь еще верит?
В качестве дополнения, для тех, кто еще не видел это, проверьте эту забавную пародию, потому что это правда
22 ответа
Для типичного магазина программирования CMM уровня 1 стоит попытаться добраться до уровня 2; это означает, что вам нужно подумать о своих процессах и записать их. Естественно, это встретит сопротивление со стороны ковбойских программистов, которые чувствуют себя ограниченными стандартами, документацией и тестовыми примерами.
Усилия по переходу от уровня 2 ("есть процесс") к уровню 3 ("у всех один и тот же процесс") обычно увязают в межведомственной войне, поэтому, вероятно, начинать не стоит.
В основе проблемы лежит эта проблема, аккуратно описанная в самом руководстве CMM...
" ... Правильное и проницательное использование ШМ необходимо для здравого смысла. Интеллект, опыт и знания должны формировать надлежащую интерпретацию ШМ в конкретной среде. Такое толкование должно основываться на бизнес-потребностях и целях организации и проектов. Уверенное, ориентированное на контрольные списки приложение CMM может нанести вред организации, а не помочь ей... "
На странице 14, раздел 1.6, Модель зрелости возможностей, Руководство по совершенствованию процесса разработки программного обеспечения Института разработки программного обеспечения Университета Карнеги-Меллона, ISBN 0-201-54664-7.
Я обнаружил, что это раздутое упражнение по документированию, которое использовалось главным образом как средство для заключения контрактов / сопровождения. Как только у нас был контракт, это было упражнение в том, чтобы обойти этот процесс.
Как разработчик, я ничего не получил от этого, но потерял МЕСЯЦЫ моей профессиональной жизни, вертя с CMMI.
То же самое касается 6 сигм, которые я назвал "Здравый смысл в коробке". Мне не нужно было учиться понимать, в чем заключается проблема с процессом - это, как правило, было совершенно очевидно.
Для меня небольшие команды и гибкие механизмы работают намного лучше. Короткие циклы, много общения. Это может работать не во всех средах, но определенно работает в моей.
Просто мои два цента.
CMM и CMMI предлагают некоторые преимущества, если ваша организация принимает уроки, которые она пытается преподавать в глубине души. Проблема в том, что переход на более высокие уровни очень труден и дорог, и я видел, как организация проходит через это единственное время, потому что их клиенты не позволят им делать ставки по контрактам, пока они не достигнут определенного уровня.
Это приводит к тому, что организация делает все возможное, чтобы "просто получить число", не заботясь об этом, улучшая свой процесс.
Высший конец? Магазины CMM-5 меня не впечатляют.
Нижний конец? Да. Организации CMM-1 пугают меня.
CMM может помочь новой / начинающей команде оценить себя и заняться самоусовершенствованием.
CMMI на самом деле не об улучшении вашего программного обеспечения, а о документировании того, что вы сделали. Вы можете почти оценить уровень CMMI компании по весу документации, которую она производит.
Предыстория: я изучал CMMI в своей программе для выпускников Software Engineering и работал в команде, которая следовала его рекомендациям.
Я проводил много собеседований для небольших команд, занимающихся итеративной разработкой. Лично, если я вижу CMM в резюме, это большой красный флаг, который сигнализирует о заинтересованности в процессе по результатам.
Мой опыт показывает, что CMM настолько расплывчатый, что его очень легко выполнить. Кроме того, когда они приходят, чтобы сертифицировать вас, они смотрят на проект, который выбирает ваша организация. Там, где я раньше работал, это был проект без реального срока, большого количества денег и большого количества времени, чтобы тратить на каждый закоулок процесса. Многие другие проекты продолжались практически без проверки кода / дизайна, иногда без контроля версий программного обеспечения.
Я думаю, что акцент на сертификации CMM вызывает сожаление. Компании знают, как работает система, и делают. Вместо того, чтобы сосредоточиться на реальном улучшении процессов, которое соответствует их практическому результату, они сосредоточены на получении сертификации и работе системы. Честно говоря, я думаю, что большинство организаций предпочитают тратить время на первое, а не тратить так много времени на второе.
На самом деле важно иметь добросовестных людей, которые хотят принимать правильные решения в области развития и знают, что им понадобится помощь в принятии этих решений. Ничто не заменит качественных программистов, которые знают, что программирование - это постоянное групповое занятие, в котором они также могут ошибиться, как и все остальные.
Существуют все формальные методы продажи книг / учебных курсов / сертификации, и ни по какой другой причине. Вот почему существует так много формальных методов. Как только вы поймете это, вы свободны:-)
CMM на самом деле говорит не о качестве программного обеспечения, а скорее о документации и повторяемости процесса. Другими словами, возможно иметь упорядоченный и воспроизводимый процесс разработки, но все равно создавать дрянное программное обеспечение. Пока процесс надлежащим образом задокументирован, можно достичь уровня 5 ШМ.
В конце дня CMM - это еще один инструмент, который можно использовать или использовать не по назначению. Если конечной целью является улучшение качества программного обеспечения, можно использовать CMM для улучшения процесса разработки и повышения качества программного обеспечения. Если целью является достижение определенного уровня CMM, то скорее всего пострадает качество программного обеспечения.
Вашдон все еще верит. Но он также может все еще верить, что конец света наступит после 2000 года.
Это не то, во что я бы лично поверил или хотел бы быть вовлеченным в будущее. Но часто наша причина не в том, почему...
PS Хотя это немного не по теме, я хотел бы отметить, что поддельные сертификаты CMMI очень распространены, а также реальные сертификаты, полученные путем взяточничества.
Модель теряет доверие, во-первых, потому что компании принимают модель, не ища более зрелую модель разработки программного обеспечения, но оценивая ее до уровня CCMI.
И еще одна проблема, которая, как мне кажется, ведет к потере доверия, заключается в том, что как подрядчик вы не можете гарантировать, что проект, который продает ваш поставщик услуг по оценке CMMI, будет разработан с использованием методов моделирования. На этикетке CMMi указано, что компания когда-то разрабатывала проекты, которые оценивались как приверженцы определенного уровня зрелости CMMi.
Проблема не только в CMMi, но и в процессе, разработанном компаниями. CMMi описывает не сам процесс, а только то, что должен делать этот процесс. У вас такая же проблема с PMBOK. На самом деле проблема не только в PMBOK, но, прежде всего, в плохих менеджерах проектов, которые утверждают, что следуют заявлениям PMI.
Легенда гласит, что Министерство обороны США, которое заключило много контрактов, обнаружило, что многие из его проектов столкнулись с перерасходом времени и средств, и даже когда они были доставлены, проекты были не совсем такими, как было заказано.
Поэтому они хотели найти способ быть уверенным, что подрядчик сможет выполнить поставку вовремя, в рамках бюджета и близко к тому, что требовалось. Таким образом, модель зрелости способности родилась.
Тезис заключается в том, что если вещи записаны, то они переживают истощение. Но, говоря, что записать все будет недостаточно, нужно проверить, что они записаны правильно. Среди прочего
Несмотря на все это, им никогда не приходило в голову подумать о стоимости всего этого. Потому что, с точки зрения Министерства обороны, если бы он выдал проект на 1 миллион долларов, чтобы получить что-то через год, и в конечном итоге заплатил 10 миллионов долларов за 10 лет и не получил то, что хотел, и теперь, если вместо этого заплатив 5 миллионов долларов за то же самое, чтобы получить то, что они на самом деле хотели через два года, они все еще экономят 5 миллионов долларов, и не говоря уже о том, что они действительно что-то получают.
Так что, если вы являетесь подрядчиком US DoD или чего-то в этом роде, идите и получите CMM, потому что это будет требованием. Но если вы конкурируете с тысячами магазинов по разработке программного обеспечения на одном уровне, чтобы получить проекты с ограниченным бюджетом, ограниченным временем и так далее... CMM не является хорошим выбором.
Тем не менее, не стесняйтесь читать CMMI Dev pdf (v 1.3 на момент написания статьи). Это делает много хороших моментов. Это очень хорошо разрушает организацию. И если вы видите какие-либо моменты, которые заставляют вас идти 'ага! У меня есть эта проблема ", тогда непременно используйте эту мудрость для решения вашей проблемы. В нашем случае одно небольшое изменение, которое мы сделали, заключалось в том, чтобы мы составили список всех людей, которым разрешено предъявлять нам требования. Если было более одного человека, которому было разрешено предъявлять нам требования, то любое требование, поступающее из одного источника, передавалось другим, и они должны были сказать "хорошо", прежде чем мы добавили его в очередь. Это небольшое изменение имело большое значение в том, сколько мы работали и переработали.
Вкратце рассмотрите области процесса, сравните их с вашими областями боли и примите предложения, данные CMM. То, как вы реализуете это самостоятельно. И вы всегда можете реализовать это так, чтобы это не занимало слишком много времени или не стоило слишком много денег. Но я думаю, что то же самое относится даже к соответствующим стандартам ISO/IEC.
Есть немало хороших идей, которые могут быть легко адаптированы и приняты любой организацией для их же блага, но получение значка - это боль из-за требования ко всем видам избыточной документации.
Проблема в том, что CMMi - это не процесс, а всего лишь руководство для любого процесса, который вы можете выбрать, и который сам по себе приглашает к себе недоделанные идеи.
Другое дело, что миграция - это настоящая боль, когда вы начинаете, но она такая же, как и любая другая проблема прорезывания зубов, я думаю.
Agile - следующий CMM, и оба хрупки. Область процессов и качественного консалтинга является хорошим бизнесом в любой отрасли, и, как и инженеры, всем нужны новые модные слова, чтобы поддерживать поток денег.
CMM, когда он впервые вышел из SEI, был хорошей концепцией, основанной на солидной академической работе, но вскоре он был подхвачен консультантами по процессам и теперь является бесполезной сертификацией, которая используется большинством ИТ-директоров для покрытия своей задницы (никто не был уволен за выбор компании CMM Level 5)
Agile скоро пойдет по этому маршруту, и тогда мы можем быть уверены, что скоро увидим следующую серебряную пулю на горизонте:)
Основная проблема с пониманием ценности CMMi - это понимание самой CMMi.
CMMi - это документированный подход к постоянному совершенствованию производства программного обеспечения.
Понимание непрерывного улучшения с помощью SPC достаточно сложно в производстве, но добавьте нематериальный программный продукт, и сложность будет экспоненциальной.
Я бы порекомендовал любому, или организации, новичку в CMMi: документировать их текущий процесс, а затем посмотреть, какие результаты (затраты / выгоды) можно измерить независимо от процесса. Таким образом, если какой-либо процесс, процедура стандарта была бы изменена, это дало бы "лучший" результат. Предварительным условием для этого упражнения является документированный, стабильный повторяемый процесс, поскольку невозможно измерить выгоду каких-либо изменений в специальной среде, поскольку вы не сравниваете "подобное для подобных".
Сосредоточив внимание на вышеупомянутых концепциях на начальном этапе, организация начнет понимать и осознавать основную ценность CMMi.
Когда я работал над коммерческим программным обеспечением для полетов, мы использовали CMM, и по мере того, как наши процессы улучшали нашу способность точно прогнозировать время выполнения, улучшались. Но это был громоздкий процесс, другие подходы должны работать так же хорошо.
Раньше я. Но теперь я обнаружил, что CMM и CMMI не очень хорошо подходят для гибких подходов.
О, конечно, вы можете сжать вещи, чтобы этот квадратный колышек попал в круглое отверстие, но когда толчок подходит к толчку, вы все еще основываете свой подход на способности предсказать все, что необходимо, и предвидеть все, что встретится, при построении программная система.
И все мы знаем, насколько хорошо этот подход работает в реальной жизни! (-:
веселит,
обкрадывать
Небольшие проекты менее зависят от процесса успеха. Ключевым показателем является отношение героя к наблюдателю. Любой проект с HTBR менее 0,2 имеет серьезные проблемы.
В школе меня учили: CMM - хорошая идея, но без сертификации (любой может сказать, что они 5-го уровня / 4-го уровня) она оказывается маркетинговым инструментом для оффшорных магазинов. Так что, да, идея обоснована, но как вы докажете приверженность?