Комментарии 63
Насколько понял CMMI — подобие PMI PMBoK, только для разработки.
Не так. CMMI — это и модель разработки, и модель оценки. PMBoK — это book of knowledge. Т.е. это по сути рассказз о том, что вообще есть в отрасли и как это использовать, но не более того.
CMMI же позволяет дать организации некий «framework» для внедрения правильных практик и далее — оценить, насколько эта организация соответствует тому, что предлагается создателями стандарта.
Ближайшим аналогом CMMI может быть RUP или MSF, только в них нет разделения на уровни и нет сторонней оценки (аттестации).
CMMI же позволяет дать организации некий «framework» для внедрения правильных практик и далее — оценить, насколько эта организация соответствует тому, что предлагается создателями стандарта.
Ближайшим аналогом CMMI может быть RUP или MSF, только в них нет разделения на уровни и нет сторонней оценки (аттестации).
еще есть такая метода как PRINCE2, она очень хорошо с CMMI стыкуется — вот я ее тут описывал xariton.habrahabr.ru/blog/70051/, но не хватает кармы, чтобы опубликовать.
Насколько я понимаю, PMBoK — это тоже набор best practices, рекомендации. И та, и другая методология использует в своей основе процессный подход. А вот области покрытия процессов в организации различаются — некоторые пересекаются, некоторые представлены только в одной из них.
Более похожим на CMMI является другой продукт от Project Management Institute: Organizational Project Management Maturity Model (OPM3) — модель оценки зрелости проектного управления в организации. Это своего рода переложение содержания PMBoK на формат CMMI.
Более похожим на CMMI является другой продукт от Project Management Institute: Organizational Project Management Maturity Model (OPM3) — модель оценки зрелости проектного управления в организации. Это своего рода переложение содержания PMBoK на формат CMMI.
Подобием PMBOK для разработки ПО является SWEBOK — Software Engineering Body of Knowledge
Вы знаете, сколько в России компаний, пятого уровня зрелости? На сколько я в курсе, пару лет назад была только одна Моторолла в Питере, да и только потому, что они привезли с собой все процессы.
Я конечно могу ошибаться, но так понимаю, что причина отсутствия информации на хабре о CMMI в том, что данная концепция претит русскому человеку, программисту или менеджеру. Не наше оно.
Так-что, очень интересно услышать Ваше мнение о текущем состоянии дел с CMMI именно в России. В частности о специфике её восприятия
Я конечно могу ошибаться, но так понимаю, что причина отсутствия информации на хабре о CMMI в том, что данная концепция претит русскому человеку, программисту или менеджеру. Не наше оно.
Так-что, очень интересно услышать Ваше мнение о текущем состоянии дел с CMMI именно в России. В частности о специфике её восприятия
Luxoft к примеру еще.Если я не ошибаюсь в России около десятка компаний данного уровня.А насчет того, что концепция не подходит русскому человеку, готов поспорить, почему то у индусов она приживается, а списывать все на менталитет как то не хорошо.Сами на фирме внедряем процессы по данной системе, самое тяжелое перейти на первый уровень=)
Есть такое мнение, что наш человек слишком творческая личность, чтобы позитивно воспринимать такой подход.
Для компании да, очень хорошо. В идеале, параллельно росту плавно переходим с уровня на уровень. Незаменимых нет, красота.
Именно по этому кстати он очень прижился в Индии. Там программинг, это конвеер. Студент приходит в контору, обучается, работает некоторое время, затем набирает опыт и вероятностью практически со 100% вероятностью уезжает в США или Европу, но, незаменимых нет и система с лёгкостью принимает нового молодого индуса
Для компании да, очень хорошо. В идеале, параллельно росту плавно переходим с уровня на уровень. Незаменимых нет, красота.
Именно по этому кстати он очень прижился в Индии. Там программинг, это конвеер. Студент приходит в контору, обучается, работает некоторое время, затем набирает опыт и вероятностью практически со 100% вероятностью уезжает в США или Европу, но, незаменимых нет и система с лёгкостью принимает нового молодого индуса
Вы очень удачно затронули тему менталитета. Наш человек это личность, которая верит в сказу про Ивана-дурака. В сознании масс, русский программист это такой себе прирожденный гений, который все знает, ничего не изучая, играючи напишет код любой сложности на коленке и обязательно заткнет за пояс любого иностранца, который только и знает, что прикрываться умными терминами.
Программирование это профессия. Такая же, как и тестирование, работа с требованиями, управление проектами и даже строительство. В любой профессии есть знания и есть процессы, без них никуда. Вы слышали и о слишком творческом электрике, который плевал на правила безопасности и монтирует проводку как бог на душу положит?
Отечественному IT рынку пора взрослеть и переходить от модели «Нанял программиста -> ??? -> PROFIT» к грамотному процессному подходу.
Программирование это профессия. Такая же, как и тестирование, работа с требованиями, управление проектами и даже строительство. В любой профессии есть знания и есть процессы, без них никуда. Вы слышали и о слишком творческом электрике, который плевал на правила безопасности и монтирует проводку как бог на душу положит?
Отечественному IT рынку пора взрослеть и переходить от модели «Нанял программиста -> ??? -> PROFIT» к грамотному процессному подходу.
Пора то пора, но это будет ой как не просто. Ломать, менять самосознание людей с верху не легко.
Хотя, вот если в рамках гос-инициативы по электронизации ввести требования, аналогичные штатовским, что к госзаказам в IT допускаются только пятого уровня конторы, то шевеление начнётся нешуточное, уверен :) Может даже и польза будет!
Хотя, вот если в рамках гос-инициативы по электронизации ввести требования, аналогичные штатовским, что к госзаказам в IT допускаются только пятого уровня конторы, то шевеление начнётся нешуточное, уверен :) Может даже и польза будет!
Exigen Services, не пятый уровень, правда.
На первый уровень переходить не надо. Это как в VB — первый элемент массива — по индексу 1. т.е Вы уже там, нулевого уровня нет :)
Гдето неделю назад читали нам лекцию на работе про CMMI.
Насколько я помню там говорилось о 2-3 компаний в России пятого уровня. И около десятка четвертого уровня.
Насколько я помню там говорилось о 2-3 компаний в России пятого уровня. И около десятка четвертого уровня.
Да, это по-русски:) если мы зрелые, то сразу на пятёрку!
На самом деле, зачастую третьего уровня уже достаточно для себя, а четвёртого — для заказчиков. Если заказчик — не министерство обороны США:)
Но даже попытка привести всё к стандарту второго уровня уже может принести свои плоды, она обнажит некоторые недостатки в организации производственных и управленческих процессов, на которые раньше, возможно, не обращалось внимание. А вот заниматься ли исправлением этих недостатков решает руководство. В зависимости от того, насколько эффективными и затратными окажутся предложенные улучшения.
На самом деле, зачастую третьего уровня уже достаточно для себя, а четвёртого — для заказчиков. Если заказчик — не министерство обороны США:)
Но даже попытка привести всё к стандарту второго уровня уже может принести свои плоды, она обнажит некоторые недостатки в организации производственных и управленческих процессов, на которые раньше, возможно, не обращалось внимание. А вот заниматься ли исправлением этих недостатков решает руководство. В зависимости от того, насколько эффективными и затратными окажутся предложенные улучшения.
Еще есть вопрос. Всем ли компаниям нужны эти бумажки о том, что у них пятый уровень зрелости? Какой уровень CMMI у компаний Microsoft, Google, SAP?
В этом прелесть и проблема наших людей, не могут обуздать свое творчество, и вместо того чтобы заниматься делом эффективно и совместно, каждый воротит носом и говорит, что он творческая личность.Если люди в возрасте 30-35 лет которых, хоть как то морально воспитывали при союзе реально могут осознать свои возможности, то большая часть молодежи думает, что она дико гениальна.Как раз отлаженные процессы CMMI позволяют остепенить молодежь и показать ей, что в наше время один далеко не уйдешь, программирование это уже давным-давно коллективная игра, а мы все еще в догонялки играем, обидно.
Насчет конвеера согласен, но никто не запрещает нам адаптировать процессы CMMI под наши реалии, это больше рекомендации, чем готовое решение.
Хочу заметить, что в сравнении с той же моделью ISO 9001,CMMI на порядок больше дает информации о компании как о разработчике,80% небольших и успешных компаний находятся на первом уровне, условно говоря, но справляются со своей работой благодаря большой самоотдаче и местами самопожертвованию, что тоже характерно для нашего менталитета=)
Насчет конвеера согласен, но никто не запрещает нам адаптировать процессы CMMI под наши реалии, это больше рекомендации, чем готовое решение.
Хочу заметить, что в сравнении с той же моделью ISO 9001,CMMI на порядок больше дает информации о компании как о разработчике,80% небольших и успешных компаний находятся на первом уровне, условно говоря, но справляются со своей работой благодаря большой самоотдаче и местами самопожертвованию, что тоже характерно для нашего менталитета=)
Хорошая обзорная статья.
Сам я работал в организации, имевшей CMM level 3 (т.е. 3 уровень по предыдущей модели — CMM). Скажу, что существование Процесса (так для краткости называли порядок работы, соответствующий принципам CMMI) для больших компаний — это очень и очень неплохо.
Кстати, дополнение — 1-му уровню CMM/CMMI в принципе соответствует любая компания, успешно закончившая хотя бы 1 проект :)
Т.е. 1 уровень — это хаос, но хаос успешный. А вот дальнешие уровни этот хаос постепенно успокаивают и «кристаллизуют».
Кстати, насколько я слышал, министерство обороны Штатов в качестве подрядчиков не работает с компаниями, не имеющими высокий уровень по CMM/CMMI.
Сам я работал в организации, имевшей CMM level 3 (т.е. 3 уровень по предыдущей модели — CMM). Скажу, что существование Процесса (так для краткости называли порядок работы, соответствующий принципам CMMI) для больших компаний — это очень и очень неплохо.
Кстати, дополнение — 1-му уровню CMM/CMMI в принципе соответствует любая компания, успешно закончившая хотя бы 1 проект :)
Т.е. 1 уровень — это хаос, но хаос успешный. А вот дальнешие уровни этот хаос постепенно успокаивают и «кристаллизуют».
Кстати, насколько я слышал, министерство обороны Штатов в качестве подрядчиков не работает с компаниями, не имеющими высокий уровень по CMM/CMMI.
Кстати, переноси топик в «Управление проектами» — там ему самое место.
НЛО прилетело и опубликовало эту надпись здесь
Обязательно пишите про механику внедрения по возможности. Лично мне будет интересно.
И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.
И еще хотелось бы узнать как же конкретно CMMI относится к конфигурационному менеджменту? Предъявляются ли какие-то требования к процессам конфигурационного менеджмента или он просто «должен быть»? Насколько я знаю, в CMMI не предъявляется жетских требований к необходимости использования, к примеру, контроля версий. Если так, то как тогда как CMMI предлагает осуществлять конфигурационный менеджмент? Ведь контроль версий — это его основной процесс. С другой стороны я понимаю что CMMI не должен опускаться до таких деталей, но, тем не менее, всё равно интересно насколько детализированы/абстрактны описания высоких уровней зрелости.
Я участвовал в написании процессныйх документов именно для CM KPA.
По сути стандарт говорит — надо иметь такие-то и такие-то практики (например, контроль версий), и иметь документы, которые эти практики описывают для участников проектов и всех stakeholders (например, документация по использованию VCS, политики ветвления, выпуская релизов, тренинги).
Но вот конкретику — какую именно систему контроля врсию использовать, или какие готовые документы по политикам ветвления и интеграции прдложить — этого CMMI не дает. Это отдается на откуп самой организации.
По сути стандарт говорит — надо иметь такие-то и такие-то практики (например, контроль версий), и иметь документы, которые эти практики описывают для участников проектов и всех stakeholders (например, документация по использованию VCS, политики ветвления, выпуская релизов, тренинги).
Но вот конкретику — какую именно систему контроля врсию использовать, или какие готовые документы по политикам ветвления и интеграции прдложить — этого CMMI не дает. Это отдается на откуп самой организации.
То есть, проще говоря, нужно иметь CMP (Configuration Management Plan). Этого достаточно? Всё перечисленное можно втиснуть в рамки этого документа. Но мне всё таки интересно, есть ли требования CMMI к тому, что конкретно должно быть обязательно включено в CMP. Ведь сами по себе практики конфигурационного менеджмента вроде как опциональны. Кроме контроля версий стандарт требует наличие каких-то практик? Если да, то каких? Насколько глубоко описываются требования к использованию контроля версий и вообще специфицируется ли то, что же конкретно такое контроль версий?
SCMP — это итог всей работы по установлению СМ-процесса. Вообще любые документы — это лишь форма для сохранения знаний.
Насчет практик — СММ предписывает, помимо контроля версий, вообще контроль за изменениями, куда входит и отслеживание запросов на изменения. Также внимание в стандарте уделяется определению бэйзлайнов и выпуску релизов. А вообще полный перечень есть в CM KPA — там есть подробности.
Насчет практик — СММ предписывает, помимо контроля версий, вообще контроль за изменениями, куда входит и отслеживание запросов на изменения. Также внимание в стандарте уделяется определению бэйзлайнов и выпуску релизов. А вообще полный перечень есть в CM KPA — там есть подробности.
НЛО прилетело и опубликовало эту надпись здесь
Читал. Не понравилось. Автор пытается совместить ужа с ежом.
К CMMI, как части системы менеджмента качества, тема социальной ответственности и стратегия развития рынка (проблема, как не «исчерпать рынок клиентов») не имеют никакого отношения. Всё это части менеджмента стратегического. CMMI там уже не место.
К тому же автор подменяет понятия: в социальную ответственность компании не может входить помощь своим конкурентам. Социальная ответственность — это повышение качества жизни общества.
Я вообще не вижу противоречия в том, что молодые компании компании не могут получить крупные заказы. Может ли выпускник претендовать на должность директора? Так и на рынке разработки ПО: только опытным компаниям доверяют разрабатывать крупные проекты.
К CMMI, как части системы менеджмента качества, тема социальной ответственности и стратегия развития рынка (проблема, как не «исчерпать рынок клиентов») не имеют никакого отношения. Всё это части менеджмента стратегического. CMMI там уже не место.
К тому же автор подменяет понятия: в социальную ответственность компании не может входить помощь своим конкурентам. Социальная ответственность — это повышение качества жизни общества.
Я вообще не вижу противоречия в том, что молодые компании компании не могут получить крупные заказы. Может ли выпускник претендовать на должность директора? Так и на рынке разработки ПО: только опытным компаниям доверяют разрабатывать крупные проекты.
НЛО прилетело и опубликовало эту надпись здесь
На мой взгляд, сертификация по модели CMMI требуется только для повышения спроса. Сомневаюсь, что командам разработчиков Google, Facebook или MSN требуется дополнительный спрос.
А вот внедрить что-либо из этой модели они могут, но об этом вы вряд ли узнаете. Вы много знаете о процессе разработки в компании Google или других крупных компаниях? Обычно такая информация является коммерческой тайной.
Зачем же противопоставлять стабильность и инициативность/изобретательность? Стабильность означает гарантию выполнения взятых обязательств, а изобретательность позволяет выполнить эти обязательства с меньшими затратами.
К тому же CMMI не накладывает ограничений на инициативы и изобретения. Более того, 5 уровень требует регулярного внедрения инноваций!
А вот внедрить что-либо из этой модели они могут, но об этом вы вряд ли узнаете. Вы много знаете о процессе разработки в компании Google или других крупных компаниях? Обычно такая информация является коммерческой тайной.
Зачем же противопоставлять стабильность и инициативность/изобретательность? Стабильность означает гарантию выполнения взятых обязательств, а изобретательность позволяет выполнить эти обязательства с меньшими затратами.
К тому же CMMI не накладывает ограничений на инициативы и изобретения. Более того, 5 уровень требует регулярного внедрения инноваций!
НЛО прилетело и опубликовало эту надпись здесь
Различайте индустрию услуг и индустрию продуктов. CMMI жизненно необходим как способ опосредованно оценить возможное качество услуги для ЗАКАЗНОГО ПО.
Гугл и Facebook — это продуктовые компании. С точки зрения потребителя, абсолютно всё равно, как оно там внутри.
Гугл и Facebook — это продуктовые компании. С точки зрения потребителя, абсолютно всё равно, как оно там внутри.
НЛО прилетело и опубликовало эту надпись здесь
Хотите вкратце? Да запросто:)
CMMI — это сборник рекомендаций ЧТО можно улучшить на всех этапах разработки ПО (от планирования до внедрения и сопровождения), а также в сопутствующих областях, таких как управление соглашениями с поставщиками, управление конфигурациями, контроль качества и т.п.
Местами есть рекомендации и КАК можно улучшить, но в целом — это остаётся на усмотрение самой организации.
Если вы придерживаетесь этих рекомендаций, то вы можете попытаться получить знак отличия от других, получить дополнительное конкурентное преимущество — сертификат на соответствие одному из уровней зрелости.
Для многих заказчиков — это самый простой способ отделить надёжных разработчиков от ненадёжных и отсеять часть из них на первом этапе, не вникая в суть работы этих компании и даже не изучая их портфолио.
И раз эта система зарекомендовала себя на западе — значит, она работает?:)
Таким образом, у вас есть два пути использования этой модели:
1) выбрать только лучшие рекомендации, которые дают прирост производительности, уровня качества, сокращение издержек соразмерные расходам на внедрение этих новаций.
2) подчиниться всем рекомендациям как требованиям, даже тем из них, которые не являются для вас очевидно выгодными; и получить сертификат на соответствие модели.
Оба варианта приносят пользу: первый позволяет сократить производственные издержки, второй повысить спрос на продукцию.
CMMI — это сборник рекомендаций ЧТО можно улучшить на всех этапах разработки ПО (от планирования до внедрения и сопровождения), а также в сопутствующих областях, таких как управление соглашениями с поставщиками, управление конфигурациями, контроль качества и т.п.
Местами есть рекомендации и КАК можно улучшить, но в целом — это остаётся на усмотрение самой организации.
Если вы придерживаетесь этих рекомендаций, то вы можете попытаться получить знак отличия от других, получить дополнительное конкурентное преимущество — сертификат на соответствие одному из уровней зрелости.
Для многих заказчиков — это самый простой способ отделить надёжных разработчиков от ненадёжных и отсеять часть из них на первом этапе, не вникая в суть работы этих компании и даже не изучая их портфолио.
И раз эта система зарекомендовала себя на западе — значит, она работает?:)
Таким образом, у вас есть два пути использования этой модели:
1) выбрать только лучшие рекомендации, которые дают прирост производительности, уровня качества, сокращение издержек соразмерные расходам на внедрение этих новаций.
2) подчиниться всем рекомендациям как требованиям, даже тем из них, которые не являются для вас очевидно выгодными; и получить сертификат на соответствие модели.
Оба варианта приносят пользу: первый позволяет сократить производственные издержки, второй повысить спрос на продукцию.
НЛО прилетело и опубликовало эту надпись здесь
Всё-таки это обзорная статья, и я постарался погрузить читателя на максимальную глубину понимания предмета в столь коротком объёме текста.
Официальный документ — 573 страницы текста, и даже этого недостаточно для полного понимания, поскольку регулярно издаются книги и представляются доклады на конференциях, комментирующие и дополняющие содержание модели.
План был простенький:
0. Введение. Актуальность.
1. Определение.
2. История вопроса. Как и для чего создавалась этот модель.
3. Два основных понятия, без которых невозможно понимание всей концепции модели:
а) уровни зрелости
б) процессные области
4. Как работает модель и какую пользу приносит. Фактически, просто рекламный обзор.
5. Заключение.
Всё и так очень сжато.
Можете дать какие-то рекомендации на будущее? Добавить содержание в начало, краткое изложение в конец?
Не нарушит ли это внешнюю стройность текста и не перегрузит ли его ещё больше?
Официальный документ — 573 страницы текста, и даже этого недостаточно для полного понимания, поскольку регулярно издаются книги и представляются доклады на конференциях, комментирующие и дополняющие содержание модели.
План был простенький:
0. Введение. Актуальность.
1. Определение.
2. История вопроса. Как и для чего создавалась этот модель.
3. Два основных понятия, без которых невозможно понимание всей концепции модели:
а) уровни зрелости
б) процессные области
4. Как работает модель и какую пользу приносит. Фактически, просто рекламный обзор.
5. Заключение.
Всё и так очень сжато.
Можете дать какие-то рекомендации на будущее? Добавить содержание в начало, краткое изложение в конец?
Не нарушит ли это внешнюю стройность текста и не перегрузит ли его ещё больше?
А зачем это вообще здесь? Чтобы что?
Я думаю полезно для понимаю, до того как с этим столкнешься. Я в свое время пришел работать в тот же Люксофт, совершенно не зная что такое CMMI 5, ни до, ни во время работы. В результате ушел, посчитав все это непонятной мне фигней. Много лет позже я все таки добрался и ознакомился с этим, и сейчас согласен что в случае Люксофта это нужно. И жалею что в то время не было возможности ознакомится (именно вот так как сейчас на хабре, пассивно. намеренно мне тогда в голову бы не пришло искать, ведь я даже не догадывался об этом). Не факт что это положительно повлияло бы, и что вообще пошел бы работать в Люксофт (или наоборот), но я, по крайней мере, понимал бы что это, и это бы очень помогло.
В общем тут есть достаточно много различных ИТ специалистов, и это нужно иметь ввиду, не зависимо от того используешь это на практике или нет. А сайты типа вашего uml2 и пр. не все ведь ежедневно читают.
В общем тут есть достаточно много различных ИТ специалистов, и это нужно иметь ввиду, не зависимо от того используешь это на практике или нет. А сайты типа вашего uml2 и пр. не все ведь ежедневно читают.
Игорь, расскажите пожалуйста, как именно иначе развернулась бы ваша судьба, как бы строилось ваше поведение в Люксофте, если бы вы прочитали эту статью?
В каких именно местах вашей деятельности данное знание бы вам помогло и как?
В каких именно местах вашей деятельности данное знание бы вам помогло и как?
Про UML2.ru:
Во-первых, этот сайт — не мой;
во-вторых, он посвящён отдельным областям знаний в разработке ПО, в основном 1) разработке требований и 2) разработке моделей программных систем
и к организации производства ПО имеет достаточно малое отношение.
Во-первых, этот сайт — не мой;
во-вторых, он посвящён отдельным областям знаний в разработке ПО, в основном 1) разработке требований и 2) разработке моделей программных систем
и к организации производства ПО имеет достаточно малое отношение.
c uml2 значит ошибся, я почему то считал что он как то с вами связан. Это был лишь пример тематического сайта, аудитория которого слабо пересекается с аудиторией хабра. Я, на самом деле, его не читаю, лишь иногда он мне попадается, но думаю что все таки близок аудитории данной темы. Ну нет так нет, это на вкус, есть и другие сайты.
Как минимум для того, чтобы я смог узнать о сайте uml2:)
На данный момент я пишу диссертацию по изучению, сравнению и возможному объединению различных методологий разработки ПО и пытаюсь внедрить CMMI в одной компании среднего размера (около 50 человек). Именно это определило тот факт, что изучение я начал с модели CMMI, и уже её пытаюсь дополнить другими методологиями.
Я изучил множество источников, в основном англоязычных. На русском обнаружил очень мало материалов (удивительно, но на ваш сайт поисковики мне не указали). Поэтому решил, что информация на эту тему может быть востребована. И естественно рассчитывал на обратную связь как на источник новой полезной информации. И не ошибся:)
На данный момент я пишу диссертацию по изучению, сравнению и возможному объединению различных методологий разработки ПО и пытаюсь внедрить CMMI в одной компании среднего размера (около 50 человек). Именно это определило тот факт, что изучение я начал с модели CMMI, и уже её пытаюсь дополнить другими методологиями.
Я изучил множество источников, в основном англоязычных. На русском обнаружил очень мало материалов (удивительно, но на ваш сайт поисковики мне не указали). Поэтому решил, что информация на эту тему может быть востребована. И естественно рассчитывал на обратную связь как на источник новой полезной информации. И не ошибся:)
На мой взгляд, если вы хотите принести пользу разработчикам ПО здесь, нужно ставить им мозги с различения простых понятий:
* продуктовая и заказная разработка,
* основная деятельность, обеспечивающая и управляющая,
* как в принципе меряется эффективность разработки ПО для разных рынков,
* как влияет на эффективность деятельности размер компании,
* какие типичные школы управления разработкой ПО существуют на практике в России,
* в чём состоят их типовые ошибки,
* чем отличаются организация разработки и управление проектами,
* кто может и должен отвечать за эти области деятельности в компании,
* где что читать
* и т.д.
А CMMI — это не для начинающих и продолжающих явно инструмент.
* продуктовая и заказная разработка,
* основная деятельность, обеспечивающая и управляющая,
* как в принципе меряется эффективность разработки ПО для разных рынков,
* как влияет на эффективность деятельности размер компании,
* какие типичные школы управления разработкой ПО существуют на практике в России,
* в чём состоят их типовые ошибки,
* чем отличаются организация разработки и управление проектами,
* кто может и должен отвечать за эти области деятельности в компании,
* где что читать
* и т.д.
А CMMI — это не для начинающих и продолжающих явно инструмент.
На всякий случай, МОЙ сайт — это system-analysis.ru и если вы имели в виду его, то «поисковики» и не должны были на него указывать, т.к. он посвящён не организации производства ПО, а несколько более узкой, с одной стороны, а с другой перпендикулярной теме.
А вы не могли бы рассказать еще о PSP — такой же модели как CMMI, но для индивидуального разработчика?
Сколько же рабочего времени мы убили в нашей компании на эту муть.
Imho, СММ(i) пригодна когда заказчик хочет видет 'внутренности' процесса разработки, который делает подрядчик.
В остальном же это — мифилогизированный фетиш для больших компаний которым некуда выкинуть деньги.
Нигде не встречал сколько-нибудь убедительных доказательств что CMM и подобные бюрократизмы повышает эффективность разработки и компании в целом.
А накладные расходы на создание и поддержание процесса могут занимать до 30% рабочего времени (по моим очень субъективным оценкам).
Сорри за эту ложку дёгтя.
Сказанное, разумеется, только мое личное imho.
Imho, СММ(i) пригодна когда заказчик хочет видет 'внутренности' процесса разработки, который делает подрядчик.
В остальном же это — мифилогизированный фетиш для больших компаний которым некуда выкинуть деньги.
Нигде не встречал сколько-нибудь убедительных доказательств что CMM и подобные бюрократизмы повышает эффективность разработки и компании в целом.
А накладные расходы на создание и поддержание процесса могут занимать до 30% рабочего времени (по моим очень субъективным оценкам).
Сорри за эту ложку дёгтя.
Сказанное, разумеется, только мое личное imho.
Любая более-менее крупная компания и команда требуют внедрения хотя бы минимального процесса разработки — хоть CMM, хоть XP, хоть RUP… но требует. Крупные команды не могут работать в хаосе, это непродуктивно. А внедрение любой методики требует затрат ресурсов.
Насчет 30% — откуда цифра? Если речь о создании процесса — да, первоначальный вложения относительно велики. Однако поддержание процесса — это всего лишь следование ему и выполнение всех предписанных практик — так же, как и при любой другой методологии.
Насчет 30% — откуда цифра? Если речь о создании процесса — да, первоначальный вложения относительно велики. Однако поддержание процесса — это всего лишь следование ему и выполнение всех предписанных практик — так же, как и при любой другой методологии.
Ну за все крупные компании расписываться не могу, мы в нашей компанни работали с двумя крупными американскими компаниями. Обе весьма успешны. Одна из них требовала от нас введения CMM-а, хотя сама при этом внедряла его весьма небрежно, для галочки.
Во второй компании вообще, как я понял, практически нет 'процесса', ну за исключением абсалютно необходимых вещей типа: контроля версий, баг треккинга и отчетов.
Да и в майкрософте и гугле, насколько я читал, применяется что-то свое. Я так понял там работают небольшими группами, которыми проще управлять.
Мой пойнт в том, что связь между успехом компании и процессом не вполне очевидна.
По поводу 30% — цифра, как я написал, основанна на субъективных наблюдениях. Следование процессу тоже занимает много времени. Например если мы вводим классификацию ошибок, каждый разработчик, или тестеровщик должен сидеть и в отчете аккуратно классифицировать каждый баг. А это может быть настоящим pain in the ass.
Главное при разработке процесса на каждом шаге спрашивать себя, а каковы конечные цели? Если цель — преодоление хаоса, то это один случай, здесь можно обойтись более простыми вещами и CMM, и пр. здесь избыточны.
Если цель дать менеджерам возможность понимания что происходит на всех проектах — это другое. Если нужно чтобы руководство компаннии могло влиять на процесс в целом по компании — это третье.
Т.е. на каждом шаге важна целесообразность — не за чем собирать по компании метрики если руководство не собирается на них смотреть.
А вообще, такой вопрос: вы в своей компании на самом деле собрались внедрять CMMi или это был просто теоретический обзор?
Во второй компании вообще, как я понял, практически нет 'процесса', ну за исключением абсалютно необходимых вещей типа: контроля версий, баг треккинга и отчетов.
Да и в майкрософте и гугле, насколько я читал, применяется что-то свое. Я так понял там работают небольшими группами, которыми проще управлять.
Мой пойнт в том, что связь между успехом компании и процессом не вполне очевидна.
По поводу 30% — цифра, как я написал, основанна на субъективных наблюдениях. Следование процессу тоже занимает много времени. Например если мы вводим классификацию ошибок, каждый разработчик, или тестеровщик должен сидеть и в отчете аккуратно классифицировать каждый баг. А это может быть настоящим pain in the ass.
Главное при разработке процесса на каждом шаге спрашивать себя, а каковы конечные цели? Если цель — преодоление хаоса, то это один случай, здесь можно обойтись более простыми вещами и CMM, и пр. здесь избыточны.
Если цель дать менеджерам возможность понимания что происходит на всех проектах — это другое. Если нужно чтобы руководство компаннии могло влиять на процесс в целом по компании — это третье.
Т.е. на каждом шаге важна целесообразность — не за чем собирать по компании метрики если руководство не собирается на них смотреть.
А вообще, такой вопрос: вы в своей компании на самом деле собрались внедрять CMMi или это был просто теоретический обзор?
Что ж, подпишусь практически под каждым словом — главное целесообразность, процесс ради процесса — это зло.
К слову — в Microsoft используется MSF — он также является самостоятельной методологией со своим процессом, пусть и не таким монструозным.
Насчет моей компании — когда я пришел, уже имелся CMM level 3. Пока работал — было движение в сторону сертификации уже на CMMI, причем на уровень не ниже 4. В общем-то, делалось это и для галочки (чтобы привлекать заказчиков), и для себя — т.к. сертифицироваться на уровень, не имея эффективного работающего процесса — это почти нереально. Однако вскоре дела у основного заказчика пошли неважно и все внимание переключили на собственно работу.
К слову — в Microsoft используется MSF — он также является самостоятельной методологией со своим процессом, пусть и не таким монструозным.
Насчет моей компании — когда я пришел, уже имелся CMM level 3. Пока работал — было движение в сторону сертификации уже на CMMI, причем на уровень не ниже 4. В общем-то, делалось это и для галочки (чтобы привлекать заказчиков), и для себя — т.к. сертифицироваться на уровень, не имея эффективного работающего процесса — это почти нереально. Однако вскоре дела у основного заказчика пошли неважно и все внимание переключили на собственно работу.
Давайте попробуем начать с простого вопроса — что знакомство с данной моделью может дать представителям разных рабочих ролей в компаниях, работающих на разных рынках и имеющих различные масштабы?
Вечер добрый… (сам хотел написать давно что-нибуть о CMMI, да всё времени не хватало :( )
В принципе CMMI модель — довольно не плохая, главный плюс в ней как раз то что ты можешь сам выбирать «как делать» она же тебе говорит только «что должно быть обязательно сделано», так что каждая компания сама может отлично подстроиться под эту модель как её больше удобно.
пару input-ов для изменения автору:
1) было бы лучше собрать все процессные области по группам (так и людям понятнее и читабельнее)
2) не описан процесс сертификации (что 1-2 уровни компании просто могут себе сами присвоить по сути, а начиная с 3го уровня компания должна проходить официальную сертификацию другой компанией имеющей на это право… можно и примерные цены выложить, думаю интересно будет )
3) действительно (как замечено в других комментах) не хватает статистики — какие коммпании с каким уровнем… и т.п.
в принципе статья неплохая (понятно что обзорная), а дальше что-то будет?:)
В принципе CMMI модель — довольно не плохая, главный плюс в ней как раз то что ты можешь сам выбирать «как делать» она же тебе говорит только «что должно быть обязательно сделано», так что каждая компания сама может отлично подстроиться под эту модель как её больше удобно.
пару input-ов для изменения автору:
1) было бы лучше собрать все процессные области по группам (так и людям понятнее и читабельнее)
2) не описан процесс сертификации (что 1-2 уровни компании просто могут себе сами присвоить по сути, а начиная с 3го уровня компания должна проходить официальную сертификацию другой компанией имеющей на это право… можно и примерные цены выложить, думаю интересно будет )
3) действительно (как замечено в других комментах) не хватает статистики — какие коммпании с каким уровнем… и т.п.
в принципе статья неплохая (понятно что обзорная), а дальше что-то будет?:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модель CMMI