Software Configuration Management // Метрики и документация

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

    Так вот — о формализации. Намедни провёл опрос с целью выяснить — какие метрики народ использует в своих проектах. Выяснилось страшное. Из тех, кто вообще решил что-то выбрать (т.е. без воздержавшихся) — половина не просто не собирает метрики, но и не собрается. Надо полагать, с документированием процессов всё ещё хуже.

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


    Сбор метрик


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

    При чем здесь 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

    Задавайте вопросы.

    Ну а про SCM в целом — продолжение следует.

    Комментарии 8

      +1
      >> Кто работает, а кто болтом груши околачивает.

      Вот с этим не согласен. Нельзя сравнивать людей по метрикам; практика показывает, что как только метрика ИЗ инструмента оценки проекта превращается в инструмент оценки людей, то начинается цирк. И клоуны.
      Еще неправильнее показывать эту статистику product owner-у или hr-у — те сразу начинают лезть не в свое дело: давайте команду реорганизуем, давайте ему зарплату снизим, давайте его уволим а наймем более эффективного. Нет смысла пояснять, что всем меры неэффективные — снижение зарплаты ударит по производительности еще сильнее, а после замены человека начнут искать следующего самого слабого: не команда, а территория с естественным отбором. Это очень плохо влияет на мотивацию людей -> сроки проекта.

      Сравнивать следует только человека с самим собой на разных промежутках времени; и то, это показывает не причину — (раз «болтом по грушам», значит мудак), а следствие — раз стал работать менее эффективно, значит, что-то мешает.

      >> руководство проекта знает о происходящем
      Тут не очень ясно, кого вы имеете в виду под руководством. Если pm и выше (ближе к заказчику) — то имхо ему достаточно выдавать 3-4 общих интегральных показателя, характеризующих прогресс по продукту + 3-4 специфических для предметной области — размер БД, или скокрострельность на тестах и т.п. На уровне проджект-лида и тех-лида следует, конечно, оперировать более полной собранной информацией; тут и KLOC не будет лишним ни в коем случае.

      С остальным согласен :)
        0
        Спасибо за реакцию :) хоть кому-то интересны эти вещи :)
        По порядку:

        Насчет «болтом груши» — тут ключевые слова "*кто чем насколько сильно* занят". Т.е. не кто сколько сделал, а какова загруженность на текущий момент. Нет смысла назначать задачу на того, у кого этих задач вагон и маленькая тележка.
        Разумеется, мерять коллектив только на том основаниии, сколько кто багов пофиксал — не совсем верно, надо учитыать ещё прорвау факторов. На предыдущем месте работы у нас собиралось довольно много метрик, но премиальные считались всё равно по субъективным факторам. Сделать это было не так сложно потому, что премии считали сначала руковдители групп — и выдавали менеджменту коэффициенты участия члена команды. Этот коэффициент трудового участия (КТУ) уже определял долю конкретного еловека в общем премиальном фонде.

        Поэтому метрики по задачам важны в первую очередь для оперативного управления.

        Далее, насчет руководства. Совершенно согласен — разный уровень менеджмента интересуется разными показателями — и чем выше, тем «интегральнее». А в сумме получается — одному пара метрик, другому 3-4 метрики — так и выходит, что для полноты картины на конечных «сборщиках метрик» ложится задача собрать сдесяток разнообразных метрик.
        Об этом и заметка :)

        0
        Ну а что с продолжением то?
          0
          Был материал по распределенным системам контроля… Однако пока готовил остальные материалы — появились новые мысли.
          В общем, в процессе :)
            0
            Спасибо, будем ждать. Собственно по DVCS и хотелось бы почитать.
              0
              Советую прочитать вот эти статьи
              lib.custis.ru/index.php/%D0%9A%D0%B0%D1%82%D0%B5%D0%B3%D0%BE%D1%80%D0%B8%D1%8F:%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D0%B8_%D0%BE_Subversion

              Прямо с первой — про риски распределенного контроля версий. :)

              Статьи — от камрада belonesox (http://belonesox.habrahabr.ru/). В большинстве статей готов поставить свою подпись — со многим согласен.

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое