Введение
С переходом все большего числа команд разработчиков на использование в своей работе методологии от Agile, инструментарий управления все больше отличается от традиционно используемых инструментов управления проектами. Предполагается, что читатель уже познакомился с принципами быстрых процессов. В этой статье будет подробно рассмотрена процедура создания такого вида управленческого отчета, который можно использовать в рабочем проекте типа agile. Если читатель ищет статью, способную убедить его в эффективности разработки с использованием методологии Agile, он может обратиться к книгам и веб-сайтам, указанным в этой статье.
В ходе создания такого управленческого отчета мы рассмотрим, как базовый сервер команды (TFS) можно использовать для управления agile-проектом, в котором используются средства XP, функции, аналогичные историям, и короткие итерации. TFS обеспечит поддержку информации в базе данных, а мы создадим отчеты, содержащие информацию, предназначенную для заказчика.
Мы постараемся создать 3 отчета: отчет с подробной историей, позволяющий распечатать истории для вывешивания их в оперативном центре, отчет о текущей итерации, описывающий состояние текущей итерации, и отчет об авариях.
Системные требования
1. Базовый сервер команды (TFS);
2. SQL Server 2005;
3. Visual Studio 2005
4. Crystal Reports XI.
Основные элементы Agile-проекта
Чтобы дать читателю представление об Agile, основное внимание в данной статье уделено методологии, аналогичной той, с которой знаком автор статьи. Она основана на учебном курсе, проводимом Робертом Мартином (Robert Martin), который является автором, помимо прочего, таких книг как Agile Principles, Patterns, and Practices in C#.
Предполагается, что читатель данной статьи знаком с концепциями Agile. Мы рассмотрим некоторые принципы Agile-разработки, однако читателю необходимо почитать другие статьи, книги и т.д., чтобы получить реальное представление о разработке ПО с использованием этой методологии.
Существует множество причин для использования гибких методов при разработке ПО. В нашем случае необходимо создать ПО более высокого качества и обеспечивающее лучшую связь с заказчиками. Манифест Agile включает 12 принципов. Первый из них гласит: "Удовлетворение заказчика посредством быстрой и непрерывной поставки ценного ПО", а второй формулируется так: "Приветствуется изменяющиеся требования, даже на поздней стадии разработки ПО". Эти 2 принципа имеют отношение к вопросам, важным для моего текущего рабочего пространства.
В данной статье рассматривается создание проекта, в котором используются истории пользователей в качестве составной части документации с техническими требованиями. Поэтому проект содержит коллекцию историй пользователей, которые определяют свойства этого проекта. Команда разработчиков путем голосования назначает каждой истории количество точек и определяет, сколько точек будет иметь каждая из историй. Эта точечная система является полностью произвольной. После проведения нескольких итераций команда решает, какое число точек соответствует легкой, средней, трудной и т.д. категории историй.
Каждая итерация начинается с совещания по планированию, на котором заказчики выбирают истории. Заказчики ограничены количеством точек, которое, как полагает команда разработчиков, может быть сделано в рамках этой итерации. После того как истории будут отобраны, заказчики создают некую форму тестов приемки ПО, которую команда разработчиков должна реализовать в виде программы. Поскольку один из принципов методологии Agile гласит: "Приветствуются изменяющиеся требования, даже на поздней стадии разработки", в любое время новые истории пользователей могут добавляться в журнал пользовательских историй.
Эта конкретная версия применения методологии Agile очень близка к XP в отношении отслеживания и выбора приоритетов разработчиков. В методологии истинного XP также присутствуют такие элементы, как парное программирование. Я также рекомендую оборудовать рабочие места для максимально возможного количества разработчиков в "оперативной комнате". Организация совместной работы разработчиков в одной комнате без перегородок реально повышает продуктивность их работы во время выполнения проекта. Существует ряд исследований, которые подтверждают это.
Таким образом, в данном типе agile-проекта мы прослеживаем истории пользователей и подсчитываем сумму точек для текущей итерации.
Использование TFS для отслеживания Agile-процесса
Для создания отчетов нам понадобится некоторый способ сбора этих данных. Традиционная agile-технология предполагает использование карточек историй (стандартные каталожные карточки), размещаемых в каком-либо месте оперативной комнаты. Эти карточки и листы электронной таблицы Excel могут помочь организовать процесс отслеживания.
Это действительно работает во многих проектах, но что делать в случаях, когда команда разработчиков рассредоточена (включая заказчиков)? В этом случае многие, включая и меня, предпочитают иметь информацию по историям пользователей, собранную в электронном виде. Если компания уже использует серверы TFS, этот инструмент позволяет собирать такую информацию множеством способов.
Данная статья предлагает на TFS использовать MFS Agile стандарт с включенным в него шаблоном как основу для создания отчетов. Можно настроить собственную версию этого шаблона, чтобы приспособить его к agile-проекту. В данной статье мы не будем рассматривать этот вопрос, но можно прочитать эту веб-статью , если читатель интересуется настройкой своего собственного шаблона.
В шаблоне MSF Agile имеется рабочий компонент, называемый сценарием (Scenario), который можно использовать для сбора историй пользователей. См. рис. 1, на котором приведен пример нового сценария.
Рисунок 1
На этом экране поле Rank (Ранг) можно использовать для задания номера итерации. В это поле можно вводить текст на обычном языке, поэтому никакие ограничения не накладываются. На закладке Details имеется поле с именем "Rough Order of Magnitude (примерный порядок величины)", в которое можно ввести значение суммы точек. Вводимые в это поле значения изменяются в зависимости от используемой системы точек. Чтобы изменить существующие шаблоны или создать свои собственные шаблоны, прочитайте эту статью в сети MSDN. В поле Title вводится заголовок пользователя, а описание может включать дополнительные подробности для сбора более подробной информации или ссылки на документы, которыми может воспользоваться команда разработчиков.
Другое преимущество использования TFS состоит в том, что поскольку каждая история имеет свой уникальный номер, он может помочь в идентификации истории, с которой в данный момент работает команда. С использованием этих различных полей, которые регистрируются в базе данных TFS, TFSWorkItemTracking, можно создавать управленческие отчеты. Помните, что этот инструмент не является хранилищем отчетов, поэтому SQL-операторы, включенные в эту серию, могут изменяться при обновлениях. Нижняя строка функционирует в том случае, если серверы пользователя оснащены средствами регулярного резервного копирования информации, что сводит к минимуму вероятность потери базы данных по проекту, и это является еще одним преимуществом данного метода.
Краткие выводы
В этой первой части серии материалов по созданию agile-проекта мы рассмотрели основы работы agile-процесса. Был также рассмотрен вариант использования стандартных TFS-шаблонов в agile-процессе пользователя, которые помогают создавать отчеты, облегчающие управление проектами.
Во 2-й и 3-ей частях будет рассмотрен процесс создания реальных отчетов в среде Crystal XI. До того же времени продолжайте создавать превосходное ПО, и успехов Вам в программировании.