Несмотря ни на что, в нашей стране IT тоже развивается. На определенном этапе развития отдельной компании остро встает вопрос организации процесса разработки ПО. Руководство начинает задумываться над управлением проектами, контролем качества, управлением конфигурацией и т.п. Начинаются поиски методик, которые позволят создать хороший процесс. Одной из таких методик является CMM (Capability Maturity Model) - модель построения зрелых процессов разработки ПО.

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

Для начала немного о том, что же такое модель зрелости. CMM определяет пять уровней зрелости организации, разрабатывающей программное обеспечение:

1. Начальный
   Успех проекта зависит от личных качеств членов команды, предсказуемость крайне маленькая. На этом уровне находится подавляющее большинство белорусских разработчиков.
2. Повторяемый
   Установлены основные процессы управления проектом и процесс разработки ПО, что позволяет повторять достигнутые ранее успехи.
3. Определенный
   Производственный процесс документирован и стандартизирован.
4. Управляемый
   Собираются и оцениваются подробные количественные показатели процесса и качества ПО.
5. Оптимизирующий
   Процесс постоянно совершенствуется.

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

• Управление конфигурацией ПО
• Обеспечение качества ПО
• Отслеживание хода проекта и контроль над ним
• Планирование проекта
• Управление требованиями

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

Книга "Модель зрелости процессов разработки программного обеспечения" написана шестью авторами, которые являются сотрудниками SEI (Software Engineering Institute) при Carnegie Mellon University.

Впечатление

После прочтения первых глав стало понятно, что книгу писали научные сотрудники. Язык настолько сухой и научный, что иногда невольно задумываешься, умеют ли авторы разговаривать без терминов? Конечно, книга серьезная, рассчитана на людей умных и образованных, но все равно читается с трудом. Хотя одну шутку на всю книгу обнаружить удалось.

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

Чем дальше читаешь, тем больше кажется, что CMM очень плотно подходит к методологии RUP, которая тоже без настройки ужасно громоздкая. К середине книги создается впечатление, что это неспроста.

Кому читать?

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

Расширять кругозор полезно всем участникам проекта, но особенно топ-менеджерам, бизнес-аналитикам и управляющим проектами.

Полезность

Книга полезна только в одном случае: если вы никогда не читали ничего по CMM до сих пор, она даст общее представление и поможет сформировать мнение о CMM. Однако, если же вы уже читали обзорные статьи, то полезность книги весьма сомнительна.

Мне кажется, что только крупные организации могут рискнуть пойти именно тем путем, который описан в книге. Маленьким компаниям надо брать на вооружение практики, но внедрять их совершенно иначе. Например, для управления конфигурацией на первых порах будет достаточно системы управления версиями (CVS или SourceSafe) и системы отслеживания багов. Для управления требованиями - пользовательских сценариев, для обеспечения качества - пары тестировщиков, а для планирования проекта - хорошего управляющего проектом и MSProject. Всего этого будет вполне достаточно, если в компании работает около десятка человек.

Михаил ДУБАКОВ,
wa.artel.by

P.S. Книга для обзора по просьбе Сергея Дмитриева любезно предоставлена компанией Interface (www.interface.ru) и Альянсом разработчиков программного обеспечения "Силиконовая тайга" (www.silicontaiga.ru) при непосредственном содействии Ольги Гурзо и Булата Гайфулина, за что автор и редакция КВ выражают им свою благодарность.