SCM // 5. Метрики и документация

Сбор метрик

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

При чем здесь CM? При том, что он контролирует изменения. Если учесть, что любой проект — это изменение рабочих продуктов, то через CM проходят все изменения всего проекта. Стало быть, именно средства по управлению конфигурацией ПО могут давать менеджерам видение того, как изменяется проект во времени. Обычно подобное видение выражается в виде чисел.

Какие же числовые показатели (метрики) можно получить из того, что проходит ежедневно через руки CM-инженеров?


В первую очередь, это всё, что касается учета запросов на изменение продукта:

• общее количество открытых/закрытых/находящихся в работе запросов;
• срезы запросов по каждому участнику – чем именно озадачен каждый, и в каком состоянии работа;
• время нахождения запросов в разных состояниях – как среднее, так и по каждому запросу.

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

Далее, всегда интересна общая информация о коде, как то: количество строк кода продукта и компонентов. Обычно они считаются в CLOC, NCLOC. Интересует всё, что касается вносимых изменений:

• размеры дельты (LOC) в каждом релизе;
• размеры дельты по отдельно взятым запросам на изменение (если инструментарий позволяет).

Возможны более экзотические варианты запросов, в зависимости от возможностей инструментария и потребностей проекта:

• цикломатическая сложность;
• занимаемый размер в памяти (RAM, ROM);
• изменения занимаемого объема памяти во времени.

Последняя пара метрик интересуют, как правило, те команды, которые работают с системами, имеющими ограничения по ресурсам. К примеру, мне довелось это видеть в Motorola Mobile Devices Software. Объем памяти всегда критичен для сотовых телефонов, особенно когда речь идет о новых чипсетах и архитектурах. А СМ как раз позволяет собирать эти данные на этапе поготовки резизов.

Кстати, также могут быть интересны отчеты по произведенной работе самих CM-инженеров:

• сколько запросов на интеграцию обработали;
• сколько релизов сделали;
• каково среднее время, затраченное на релиз.

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

Итого: сбор метрик – вещь неотъемлемая от CM в рамках больших проектов. Для мелких проектов сбор метрик упрощается, а то и вообще сводится на нет. Однако, чем больше руководство проекта знает о происходящем на нижнихз уровнях (в коде), тем более эффективно можно построить повседневную работу.

Документирование деятельности CM

Все политики, процедуры и правила, которые устанавливает CM-инженер проекта, должны быть доведены до всех участников проекта. Форма предоставления этой информации не очень важна – главное, чтобы она вообще была предоставлена в срок и была постоянно доступна всем желающим. Как правило, всё, что описывается и формализуется в CM, принято объединять термином «план управления конфигурацией проекта». В англоязычных источниках используется аббревиатура SCMP – Software Configuration Management Plan.

Этот план описывает всё, чем оперирует управление конфигурацией проекта. Сюда входит следующая информация:

• Описание всех элементов конфигурации проекта: какие виды, где лежат, кто использует и кто изменяет.
• Инструменты, используемых на проекте. Описывается назначение и даются ссылки для скачивания и установки.
• Отдельно описывается система отслеживания запросов на изменение: жизненные циклы запросов, группы пользователей, их права, правила использования. Состав групп обычно определяется в самим системах и нет нужды его перечислять в документе.
• Описывается порядок работы с системой контроля версий. Какими инструментами пользоваться, где инструкция по установке клиентской части, какие группы пользователей. Отдельно описывается форматы именования веток и меток, это одна из важнейших частей с точки зрения простого разработчика.
• Определяются хранилища для релизов и других элементов, не подпадающих под действие системы контроля версий, и описывается порядок работы с ними.
• Дается описание процессов стабилизации конфигурации и выпуска базовых релизов – кем инициируется, каковы процедуры применяются, где лежит и кто отвечает за выпуск. Сюда же входит и описание сбора метрик.
• Если в рамках проекта разрабатывается несколько компонентов или продуктовых линеек, то описывается процедуры, специфичные для их CM-деятельности.

SCMP может быть оформлен и как отдельный документ, и как серия публикаций в используемой системе документооборота команды разработчиков – например, в Wiki. Главное – чтобы информация была полной, своевременной и доступной для конечного потребителя.

Вместо заключения

Выше были рассмотрены формальные стороны SCM — метрики и документация. Надеюсь, кому-то это даст повод задуматься и, возможно, сделать какие-то движения в нужную сторону.

Приведенная инфа взята из 1) жизни и личного опыта 2) стандарта SEI CMM/CMMI

Продолжение следует.