Инструменты оценки состояния проектов по разработке

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

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

Откуда брать данные?

Автоматизация процессов разработки привычно сводится к трем основным компонентам. Это управление задачами («тасками и багами»), исходным кодом и автоматическая сборка. На основе этих «трех китов» создано немало программных продуктов и схема эта доказала свою состоятельность при создании среды непрерывной интеграции (continuous integration). На рынке существует немало решений, платных и бесплатных, которые помогут вам управлять вашим кодом, задачами и ошибками, и собирать проект. Более того, существуют комплексы, которые интегрируют эти части между собой и позволяют, например, ассоциировать изменения которые вносятся в исходный код с ошибками или задачами, тем самым позволяя на более качественном уровне управлять изменениями в проекте.

Уровень интеграции этих компонент может быть различен, но вот вопрос связанный с измерениями и отчетами как то не фокусируется. Ну действительно, какие могут быть отчеты по базе исходного кода? Чуть лучше ситуация с задачами, многие системы позволят вам отфильтровать «таски и баги» по какому либо статусу. Если же рассматривать всю ситуацию в комплексе, то, оказывается что объединить все три компонента в единый комплекс отчетных данных является нетривиальной задачей.

Инструменты

При проектировании Visual Studio Team System в 2003 году было принято решение о создании полноценной системы аналитики как самого важного компонента комплекса. Основные цели при этом были следующими:

• 1) Автоматически собирать всю возможную информацию
• 2) Максимально снизить запросы к пользователю по ручному вводу информации
• 3) Предоставить инструменты быстрого анализа по запросу (ad-hoc)

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

Обработанные данные в базе OLAP затем могут быть проанализированы с помощью отчетов на базе Reporting Services или Pivot таблиц Excel.

Такой подход позволил на порядок улучшить качество исходных данных, но самое главное позволяет анализировать данные в едином комплексе с самыми различными фильтрами и разрезами. Вместе с Team Foundation Server 2010 уже поставляется несколько готовых отчетов на основе Reporting Services, и эти отчеты описаны в документации к шаблонам процессов Agile и CMMI. Но куда интереснее обстоят дела с отчетами, которые могут быть построены на базе OLAP и перекрестных таблиц Excel.

Excel как швейцарский нож

Работа с аналитическими данными проекта при помощи Excel очень проста. Для этого достаточно присоединиться к внешнему источнику данных куба TFS:

Обычно сервер, на котором находится база данных TFS и является сервером OLAP. Не забудете только получить права на доступ пользователю от лица которого вы соединяетесь с этим сервером.

Далее останется только выбрать режим отображения информации:

И вы сможете формировать вашу первую Pivot таблицу на основе данных TFS.

Аналитический куб TFS содержит 15 таблиц фактов. Это те данные, которые можно выразить в агрегированном виде. Это, например такая информация как количество модифицированных строк кода, количество пройденных юнит тестов, количество строк кода охваченных юнит-тестами (code coverage) и другие. Эта информация может быть отфильтрована в различных измерениях, которых более 60. Например, дата/время, области проекта, итерации, модули, члены команды, категории тестов, проекты, поля рабочих элементов и так далее.

Соединяем все вместе

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

Варианты вывода отчетов

Дополнительной интересной возможностью отчетов Excel является их «самодостаточность». Сформировав необходимый отчет вы можете сохранить его, отослать по почте заинтересованным лицам. А если вам необходимо посмотреть на актуальные данные, достаточно опять открыть файл и обновить данные из источника. Дополнительным интересным сценарием является публикация файла Excel на сайте Sharepoint в библиотеку документов с включенными сервисами Excel. Это позволяет видеть графики и таблицы в HTML виде, и не требовать от пользователя прав доступа к OLAP кубу TFS, и возможности присоединения к нему.

Но аналитические возможности на базе OLAP источника данных могут быть использованы не только с помощью Excel. Так же с помощью стандартных средств SharePoint Portal Server данные из OLAP куба TFS могут быть превращены в KPI и сформированы информационные панели, которые в краткой лаконичной форме «светофоров» помогают моментально оценить текущее состояние проекта. Примерами таких индикаторов могут быть пороговые значения количества ошибок на проекте, количество оставшихся открытых задач на дату, данные о проценте покрытия кода юнит тестами (code coverage).

Так же хотелось бы упомянуть новый инструмент, Live Labs Pivot – очень интересный механизм визуализации данных. Уже есть примеры его использования в качестве инструмента вывода данных из источников данных TFS.

Заключение

Предупрежден – значит, вооружен, гласит пословица. Сложность создания программных систем как никогда зависит от того, можете ли вы адекватно оценить текущую ситуацию на проекте с помощью аналитических инструментов, формальных метрик и отчетов. Если вы знаете что происходит, значит можете сделать адекватные шаги которые предотвратят неудачное развитие событий. Применяя технические средства Team System 2010 оценка текущей ситуации на проекте становится разрешимой задачей и позволяет вовремя сфокусировать команду именно на те вещи, которые влияют на успех всего проекта в целом.