Субъективно о CMMI (начало)

Этим постом я хотел бы открыть цикл статей посвященных CMMI (Capability Maturity Model Integration). Мне, почему-то показалось, что эта тема будет интересна достаточно широкому кругу читателей. Вернее, по роду деятельности мне приходилось сталкиваться с таким интересом к этой тематике как у простых разработчиков и тестировщиков, так и у руководителей проектов и департаментов.

Что, в принципе, не удивительно, учитывая все возрастающее количество компаний в СНГ, которые успешно завершают сертификацию и получают CMMI уровня 3, 4 и даже 5. Но даже сейчас их относительно немного. А, насколько мне известно, компаний, которым бы удалось сертифицировать все свои подразделения полностью - не существует. Разумеется, я говорю о компаниях, ресурсные центры которых расположены на территории стран СНГ.

Поэтому у всех IT-специалистов, которые не успели так или иначе приобщиться к CMMI возникают разного рода противоречивые чувства: одни считают методологию чуть ли ни «манной небесной», другие – очередной бюрократической машиной, с её неизменными аттрибутами: тоннами ненужной документации и большим количеством бесполезный ролей и процессов. А у людей, компании которых уже успели сертифицироваться или собираются это сделать в ближайшее время, частенько возникает отторжение: «Как же так! Работали, работали, а тут значит перестраиваться?! Все менять? Лучшее же враг хорошего?» Это знакомо, самому приходилось через такое проходить.

Как обычно, правда где-то посредине. И собственно, эту середину я и попытаюсь нащупать. С Вашей помощью разумеется.

Я отнюдь не претендую на роль эксперта или гуру в CMMI, но кое какой опыт работы с этой методологией у меня есть. А поскольку до знакомства с CMMI мне приходилось делать проекты и с использованием RUP-подходов, и опираясь на ISO стандарты, и даже Agile доводилось применять – все это в купе с опытом последних 3-х лет активного использования CMMI, влючая участие в трейнингах, сертификации и аудите проектов, образовало в моём восприятии такую гремучую смесь, которую я просто вынужден вынести на широкое обсуждение. Разумеется для того, чтобы выслушать Ваше конструктивное мнение, потому что истина, как известно, рождается в споре.

И именно поэтому формой общения я выбрал блог, поскольку именно блог, на мой взгляд является наиболее удобным способом изложения информации с обратной связью. Кстати, в Украине нет ни одного CMMI сообщества. Возможно из-за кажущейся неподъемности данной тематики, что на мой взгляд является только видимостью.

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

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

Разумеется будут все картинки, диаграммы и необходимые изображения. Определения и ключевые формулировки я буду выделять особым образом, чтобы Вы могли отделить их от моих субъективных комментариев.

By AAM

Субъективно о CMMI (часть 1)