Приверженцы «скорого» (agile) подхода к разработке ПО считают, что CMM/CMMI устарел и ведет к усложнению, излишним трудозатратам и вообще это просто старый, плохой метод. Напротив, agile-методы обладают массой преимуществ и должны использоваться всегда. Однако мой опыт работы в индустрии разработки ПО с такими утверждениями не согласуется. В одной крупной компании со зрелым процессом, основанным на CMM/CMMI, которая первой в России была сертифицирована на уровень 5 модели СММ, в некоторых разработках декларировалось использование методик и подхода agile, однако это было не всегда логично и приносило немало проблем — особенно при существовавших жестких плановых датах. В другой компании в начале проекта изначально речь шла в основном об agile-методиках, но через некоторое время стало понятно, что необходимы и другие подходы (например, элементы CMM/CMMI), чтобы справиться с проблемами, возникшими в ходе расширения проекта.

Про CMMI

С аббревиатурой CMM (Capability Maturity Model) часто ассоциируют понятие «водопадной» (waterfall) модели разработки проекта, предполагающей жесткое деление всей длительности проекта (определенной заранее на основе предварительных оценок) на фазы: написание требований, дизайн, кодирование, тестирование. При этом не предполагается изменение требований на более поздних фазах, а если это все же происходит, то может привести к коррекции сроков всего проекта. Видимо, эта ассоциация и является причиной критики CMMI (Capability Maturity Model Integration), так же как и необходимость создания подробной технической документации, что считается одной из отличительных особенностей CMMI, унаследованной от СММ. Однако это не совсем так.

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

Основной целью СММ было придание процессу разработки программ организованности — переход от хаоса к упорядоченным процессам (уровни 2 и 3) и к оптимизации этих процессов (уровень 5). Отсюда и необходимость в документации, требованиях, планах, описаниях тестов и т.д. А это, в свою очередь, работало и на повышение качества финальных продуктов.

Для большинства организаций достаточно иметь третий уровень зрелости, означающий лишь наличие набора определенных и описанных стандартных процедур, обеспечивающих повторяемость выполнения проектов с заданным (оговоренным) качеством результатов. Уровни 4 и 5 — управляемый и оптимизируемый — нацелены на управление уже не проектами, а процессами управления проектов и организации в целом и их постоянное улучшение. Так как появление СММ было тесно связано с правительственными (в том числе военными) заказами, то логично предположить, что проектируемые системы были большими и высокое качество было одним из основных требований. Это также определяло желание иметь подробную техническую документацию. «Водопадная» модель в таких проектах, наверняка с большим сроком выполнения, была вполне применима и оправданна.

Модель CMMI, появившаяся в 2002 году (версия 1.1) как развитие и улучшение СММ, описывает дополнительные процессные области и является более гибкой моделью, допускающей большее разнообразие подходов к управлению проектами. Моделей процесса разработки, кроме «водопадной», стало рассматриваться гораздо больше, а, например, спиральная и итерационная модели уже довольно близки к фазам agile-проектов. Но по-прежнему главной идеей CMMI остается предсказуемость и высокое качество выполнения проектов.

Так как CMM/CMMI предполагают строгое и формальное планирование, отслеживание проекта и полное документирование — иными словами, большие накладные расходы, — то эти модели вряд ли применимы к разработкам небольших систем в рамках маленьких проектов с небольшим количеством сотрудников, а также проектов с быстро меняющимися требованиями или с короткими циклами разработки. Но для длительных проектов, нацеленных на разработку больших многокомпонентных систем, выполняемых большим количеством сотрудников и, возможно, физически размещенных в разных местах, применение модели CMM/CMMI вполне оправданно.

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

Однако всt это не столь важно для несложных систем, разрабатываемых несколькими инженерами в одном помещении. «Водопадная» модель вряд ли применима, если продукт делается за три-четыре месяца. Для маленьких проектов, компаний-«стартапов», проектов в условиях быстро изменяющихся требований вполне подойдет применение agile-методик.

Про Agile

В agile-методах выполнение работ осуществляется малыми итерациями с минимальным планированием, что помогает минимизировать риски и быстрее адаптироваться к изменениям. Agile также предполагает большую ответственность разработчиков и минимизацию проектной документации. Важнейшей характеристикой является постоянная работоспособность продукта и частые промежуточные релизы. Широко известен также принцип «test first», то есть вначале разрабатываются тесты для продукта, которые и являются требованиями к его функциональности.

От Agile к CMMI

В Санкт-Петербургском Центре разработок компании ЕМС процессы разработки ПО находятся на этапе становления, что дает отличную возможность показать преимущества и недостатки обоих подходов и продемонстрировать эволюцию от agile к подходу, ориентированному на CMMI.

Для разработки нового продукта на базе двух уже существующих в EMC был создан новый отдел, вначале сотрудников работало немного и все они были локализованы в двух офисах разных штатов США. Работа велась с использованием методологии Scrum:

  • ежедневные короткие митинги в малых группах, затем совещание лидеров рабочих групп (Scrum Of Scrums);
  • трехмесячные итерации, заканчивающиеся базовыми релизами (base release);
  • итерация разделена на три отрезка по месяцу (sprint), для каждого отрезка выполняется планирование работы исходя из имеющегося списка задач (backlog);
  • частые, если не ежедневные, сохранения разработанного кода в общий репозиторий (trunk), еженощное построение продукта и выполнение модульных тестов (unit test).

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

Примерно в это время было создано инженерное подразделение в Петербурге — наиболее удаленное географически, находящееся в другом часовом поясе и иной языковой группе. Оторванное от основного коллектива, подразделение испытывало трудности из-за отсутствия документации с подробным описанием дизайна системы, элементов архитектуры и требований к отдельным возможностям. Из-за увеличения параллельно разрабатываемой функциональности стали случаться «поломки» репозитория после добавлений кода. Была образована группа тестирования, которой необходима была четкая информация о содержащейся в релизах функциональности и предъявляемых к ней требованиях. Таким образом, стала ясна необходимость в следующих действиях по улучшению производительности работы:

  • создание и регулярное обновление системной спецификации, описывающей архитектуру системы, зависимости между компонентами, детализирующей функции системы и их отображение на компоненты;
  • создание рабочих групп для работы над определенными функциями системы и их планов работы в соответствии с системной спецификацией (вместо распределения задач из общего списка в соответствии с Scrum);
  • введение процедур по работе с репозиторием, ограничение или запрет поставок кода в репозиторий в случае его нестабильности, планирование интеграции добавляемых в репозиторий новых частей функциональности системы;
  • создание тестовых планов, общего для продукта и на каждую функцию системы;
  • отказ от квартальных релизов и замена их месячными планами, состоящими из набора определенных частей фунциональности системы;
  • улучшение автоматизированного построения полных сборок системы и их тестирования, а также качества информации о результатах тестирования и состояния репозитория.

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

Комбинирование Agile и CMMI

С точки зрения моделирования процесса разработки существуют модели, совмещающие «водопадную» модель и итеративные подходы, свойственные agile-методам, например спиральная модель, созданная Барри Боэмом (Barry Boehm) еще в 1988 году (рис. 1).

Как известно, CMMI может использовать любую модель процесса разработки, а не только «водопадную» и, например, итеративная модель (рис. 2) не противоречит методологии CMMI.

Совмещение традиционного планирования на длительный период времени (например, на полгода) на высоком уровне управления и ежедневных Scrum-митингов в маленьких группах, работающих над конкретными задачами, обычно всегда происходит в крупных компаниях. Правда, при условии, что топ-менеджмент готов скорректировать длительные планы в зависимости от текущей ситуации. CMMI может придать больше дисциплинированности разработке, ведущейся по agile-методологии. Например, если количество инженеров, работающих с одним репозиторием, увеличилось, и репозиторий стал нестабильным, то помочь исправить ситуацию может более строгая процедура поставки кода в репозиторий. Эта процедура попадает в процессные области CMMI «Управление конфигурацией» и «Интеграция продукта», таким образом, следование рекомендациям, описанным для данных процессных областей, может помочь в agile-проекте. В любом проекте с самого начала существуют управление проектом, планирование и отслеживание — и, если заняться формальным описанием того, как это происходит, то может оказаться, что процессы вполне соответствуют модели CMMI. Так что неприятие CMMI сторонниками agile-методологий может быть лишь свидетельством не очень хорошего понимания этой области.

Добавляем CMMI в Agile

Когда полезно обратить внимание на «арсенал технологий» из другого лагеря? Если вы работаете в проекте, начатом по agile-методике, то можно рассмотреть в качестве примера следующие ситуации:

  • не получается быстро исправить дефект в версии продукта, выпущенной год назад, так как автор кода ушел и никто не понимает, как это должно работать (решение: подумайте о документировании, хотя бы после кодирования, создания дизайна и интерфейсов);
  • проект разрастается, появился филиал в другом городе (решение: чтобы избежать потерь времени на поиск информации новыми членами команды, не пора ли написать спецификации системы и разместить их в общедоступном репозитории?);
  • после окончания тестирования вдруг выяснилось, что одна из функциональных областей не может быть протестирована (решение: возможно, было бы полезно заранее дать тестовой группе полные требования, в том числе и к окружению системы);
  • пока вы улучшали несколько итераций и переделывали продукт, выяснилось, что конкуренты уже выпустили свой, и ваш уже вряд ли купят (решение: надо было заранее запланировать даты выхода на рынок, то есть осуществить долгосрочное планирование).

Добавляем Agile в CMMI

Теперь посмотрим с другой стороны, если ваш проект был ориентирован на «водопадную» модель процесса со строгими правилами:

  • написание дизайна затянулось, и сорваны сроки начала кодирования (решение: помогло бы планирование начала кодирования сразу после принятия основных решений об архитектуре, вместе с уточнением деталей дизайна, в несколько итераций);
  • группа тестирования говорит, что не может начать тестовый цикл, так как разработчики все еще не выпустили финальную версию (решение: тестировщики могли бы начать тестирование уже давно, отлаживая тесты и попутно находя дефекты начиная с самой первой работоспособной версии, а еще лучше, если бы использовался принцип test first, и первые тесты были бы готовы еще до появления первой рабочей версии);
  • разработчики жалуются, что проведение формальных обзоров кода занимает много времени, а дефекты все равно потом находят (решение: сделайте процесс обзора кода более простым, но предоставьте для этого время своим наиболее опытным инженерам);
  • в проекте работает 30 человек, и вы больше не можете отслеживать, что происходит (решение: может быть, Scrum в состоянии помочь — проведение митингов в малых группах и затем Scrum of Scrums с их лидерами).

Сила в комбинации

Комбинирование agile-методов и CMMI происходит во многих проектах, CMMI просто закрепляет формально многие практики, которые и так используются в развитых и зрелых agile-проектах. Это мнение не ново и об этом говорит сам Марк Полк, автор CMM: «На основании моих методов оценки организация, которая следует только agile-методикам, без труда достигнет третьего уровня модели CMM. В этих методиках нет ничего, что вошло бы в конфликт с требованиями третьего уровня» (см. «‘Пятерка’ за разработку», Computerworld Россия, № 42, 2004).

Сегодня все яснее становится тенденция создания новых продуктов не путем создания нового кода, а интеграцией уже готовых компонентов с их более или менее значительной модификацией, что ускоряет вывод продуктов на рынок, но процесс разработки и модели процесса требуются уже иные. «Водопадная» модель перестает работать совсем, так же как и некоторые методы оценки трудоемкости, ведь фаза кодирования сильно уменьшается. Зато на первое место выходят фаза интеграции, исправления ошибок и тестирования. Хорошо, если можно быть уверенным в стопроцентной надежности неоднократно используемых компонентов, но чаще это не так или сделанные модификации требуют полного тестирования переделанного модуля, причем в составе системы целиком. Такой подход к созданию систем может привести к внесению новых, специфических дополнений в CMMI и agile-подходы, которые еще предстоит разработать.

Иван Гуменюк (Gumenyuk_Ivan@emc.com) — начальник отдела Санкт-Петербургского Центра разработок компании ЕМС. Статья написана на основе материалов доклада на конференции Software Engineering Conference (Russia) 2008.

Таблица. Преимущества и недостатки модели CMMI

Рис. 1. Спиральная модель процесса разработки ПО

Рис. 2. Итеративная модель разработки ПО