Приложение Д
Модель зрелости возможностей создания ПО (CMMI)

В 1986 году Билл Кертис и Марк Полк из Института программной инженерии (Software Engineering Institute, SEI) при Университете Карнеги – Меллона начали всесторонний обзор зрелости процессов разработки программного обеспечения, чтобы впоследствии улучшать их, и в 1991 году впервые опубликовали CMM, которая, постоянно дорабатываясь, в 2009 году была переименована в CMMI.

CMMI состоит из пяти уровней с номерами от одного до пяти. Первый уровень означает, что организация не имеет определенного, повторяемого или улучшаемого подхода к созданию программного обеспечения. Фактически разработчики самостоятельно прокладывают свой путь к решению. На пятом уровне организация имеет определенный, повторяемый и улучшаемый набор методов для разработки программного обеспечения. Организация первого уровня считается незрелой, организация пятого уровня – зрелой. На каждом уровне методы, которые следует использовать, определяются как ключевые процессные области (КПО). Если организация считает, что полностью реализовала КПО на определенном уровне, она может привлечь оценщика. Если организация соответствует требованиям, ее сертифицируют. Сертификация – большое дело, потому что некоторые компании и правительственные агентства не нанимают фирмы, не сертифицированные как минимум на уровне CMMI 3.

Я уже рассказывал о MegaFund в третьей, пятой и девятой главах. Компания потратила три года и более $40 млн на совершенствование своих подходов к разработке программного обеспечения, пока не была сертифицирована на уровне CMM 3. На этом уровне MegaFund не только обладала стандартизированным подходом к управлению совершенно любым проектом разработки программного обеспечения, но также могла формально определять эти методы. В девятой главе мы рассмотрели, как компания MegaFund масштабировала проект, чтобы быстрее реализовать для клиентов возможность управлять счетами с помощью телефона и через интернет.

К сожалению для MegaFund, компания не определила практики, позволяющие в важном проекте c жесткими сроками автоматизировать нечеткие требования к передовым и непроверенным технологиям, как это описано в восьмой главе. Когда MegaFund начала использовать скрам в этом проекте, он буксовал уже более девяти месяцев, а участники команды безуспешно пытались преодолеть процессуальные и бюрократические препоны, которые CMM третьего уровня наложил на деятельность в неопределенных и непредвиденных обстоятельствах. Я получил неблагоприятное впечатление от CMM в этом проекте и других компаниях. Однако меня все чаще спрашивали, что я думал о CMM и как эта модель связана со скрамом. Поняв, что мне нужны дополнительные информация и знания, я организовал встречу с Марком Полком в Институте программной инженерии осенью 2002 года.

О скраме Марк только слышал, зато был знаком с экстремальным программированием – еще одним аджайловым процессом, подобным скраму, но сконцентрированным больше на инженерии ПО, чем на управлении. В течение первого дня Марк учил меня CMM, а я учил его скраму. Признаюсь, я был очень удивлен и впечатлен CMM. Марк отметил, что это всего лишь фреймворк, описывающий зрелость компании по разработке программного обеспечения. Каким образом добиваться соответствия критериям уровней зрелости – выбор самой организации. Оценщики CMM должны были определить, адекватен ли способ удовлетворения критериев. И тут меня озарило: до 2001 года почти каждая компания использовала предопределенные процессы разработки ПО, поэтому естественно, что фреймворк CMM содержал жесткие предписывающие методы. У них были те же слабые стороны, что и у всех предопределенных подходов, – они работают только в ситуациях, предусмотренных их создателями. Поскольку разработка программного обеспечения является очень комплексным процессом, нашлось очень немного реальных проектов, к которым эти подходы были бы применимы.

Затем Марк перешел к ключевым процессным областям (КПО) разных уровней. Мы оценили, к каким уровням и областям относится скрам. Марк был приятно удивлен: несмотря на то что скрам основан не на предопределенном, а на эмпирическом процессе, использующая его организация будет удовлетворять всем КПО второго уровня и многим КПО третьего уровня, за исключением тех, которые касались стандартизации подходов. Эти КПО были удовлетворены в 2003 году, когда фреймворк скрам, программа обучения Certified Scrum Program и процедура запуска скрам-проекта Project Quickstart были предложены в виде продуктов. На рис. 1 показаны степени от нулевой до второй, в которых скрам соответствует различным КПО второго и третьего уровней. Двойная галочка означает полное соответствие, а одна галочка – в большей части соответствие.

Для демонстрации того, как практики скрама реализуют одну из КПО, давайте взглянем на КПО второго уровня «Управление требованиями». Определение этой КПО: «Цель управления требованиями – добиться единого понимания требований клиента и проектом разработки программного обеспечения и самим клиентом». Скрам удовлетворяет этой КПО с помощью механизма, называемого бэклогом продукта, – открытого, прозрачного и доступного для всех списка поддерживаемых клиентами функциональных и нефункциональных требований, которые используются для управления разработкой спринт за спринтом. Эмергентный характер бэклога продукта позволяет сфокусироваться на элементах с наивысшим порядком. Это позволяет максимизировать вероятность того, что время и силы, инвестированные в детализацию требований, принесут ценность. Менее приоритетные элементы бэклога продукта могут навсегда остаться нереализованными и поэтому игнорируются до тех пор, пока не достигнут вершины списка бэклога продукта.

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

Такой эмпирический подход к трассировке пользовательских требований полностью соответствует критериям КПО, он не создает дополнительную нагрузку на процесс разработки или детальность документации. Он также обеспечивает полную гибкость в управлении и отслеживании изменений требований в любое время на протяжении всего проекта. Остальным процессным областям второго и третьего уровней скрам удовлетворяет аналогичным образом: эмпирически, с минимальной документацией и минимальными дополнительными усилиями.

Переводчик Дмитрий Блинов, консультант по аджайл-трансформациям, скрам-мастер, тренер по личной эффективности и коммуникациям, сертифицированный персональный коуч, фасилитатор. PSM, CLP, KMP, PSPO. Сайт .

Научный редактор Илья Павличенко, скрам-мастер, коуч ACC. Первый в России сертифицированный скрам-тренер от и первый в мире русскоязычный LeSS-тренер. Сайт .