Адаптируем процессы TFS под свои потребности

Введение

Хоть Microsoft Visual Studio Team Foundation Server (TFS) и поставляется с готовыми шаблонами процессов, но удовлетворить они могут не всех. Для новых и молодых команд в принципе стандартный набор шаблонов процессов TFS может покрыть все потребности процесса разработки, особенно для команд использующих гибкие (Agile) подходы к разработке. Некоторые при внедрении TFS стараются приспособиться под то, что имеется, и в некоторых случаях это проходит. Но приспособиться под стандартные шаблоны TFS не всегда представляется возможным, да и не всегда правильно. Ведь у каждой компании есть свои сложившиеся традиции в разработке, своя культура производства ПО, которые описывают текущие процессы разработки ПО в компании. Применив существующие стандарты к процессам компании можно получить некий гибрид процесса разработки, который будет наиболее подходить для компании. В этой статье мы постараемся объяснить, как можно реализовать такие нестандартные процессы с помощью шаблонов TFS.

Что имеем?

Как я указывалось выше, с TFS поставляется два встроенных шаблона процессов:

• MSF for Agile - шаблон процесса, который помогает организовать работу команду по гибким методологиям. Отличительная особенность этого шаблона в том, что в нем используется небольшое количество рабочих элементов, которого должно быть достаточно для распределения заданий в команде, описания возможностей системы или сценариев использования и отслеживания ошибок, которые предстоит исправить. Кроме того, количество состояний и переходов для этих рабочих элементов сведено к минимуму до той степени, в которой в принципе будет понятно, что происходит с текущей задачей или дефектом. Т.е. шаблон направлен на то, чтоб максимально упростить степень формализации для процесса, упростить жизнь разработчиков в команде для того, чтоб они больше времени уделяли самому процессу проектирования и разработки ПО.
• MSF for CMMI - этот шаблон процесса предназначен для того, чтоб помочь компании организовать у себя процесс разработки соответствующий третьему уровню модели качества процессов разработки CMMI. Этот шаблон более требователен к качеству процесса, чем предыдущий. Т.е. для него первоочередным стоит качество поставляемого продукта, он подходит для компаний, которые стремятся прежде все достичь прозрачности и управляемости процесса разработки, высокой степени документирования требований к продукту и качества вносимых изменений.

Т.к. оба шаблона процессов направлены на покрытие потребности двух разных методов работы, то и наборы рабочих элементов, которыми можно оперировать в ходе проекта разработки используя эти методы, для этих шаблонов различны (см. Таблица 1). Основными рабочими элементами в Agile-методологии являются сценарии использования или взаимодействия с системой, с помощью которых описываются возможности системы и вокруг которых и стоится разработка. Кроме того, используются задачи для идентификации работы разработчиков и ошибки, которые были обнаружены при тестировании системы. CMMI в свою очередь использует более широкий набор рабочих элементов: отдельно выделенные требования для определения и документирования возможностей системы, запросы на изменение для обработки запросов от заинтересованных лиц, ошибки для идентификации и исправления ошибок в системе; и т.д.

Таблица 1. Список рабочих элементов для Agile и CMMI

Кроме того, что между шаблонами Agile и CMMI различный набор рабочих элементов, похожие рабочие элементы имеют различный жизненный цикл. Если, например, взять задачу (см. Рисунок 1), то набор состояний для шаблонов будет следующий:

• Задача в Agile:
  • Активно. При регистрации задача сразу помечается как активная. Из этого состояния есть один вариант перехода - в состояние "Закрыто". Задача может перейти в это состояние по нескольким причинам: если по задаче все работы закончены, если задача откладывается на следующую итерацию или если удаляется как устаревшая.
  • Закрыта. После закрытия задача может быть реактивирована, если работы по ней были не закончены.
• Задача в CMMI
  • Предложено. Каждая новая задача изначально устанавливается в состояние "Предложено", т.е. задача еще предполагается к выполнению и детали по этому заданию еще необходимо согласовать. После этого задача может быть принята в работу, отправлена на уточнение или отменена за ненадобностью проведения предложенных работ.
  • Активно. В этом состоянии задача может быть в том случае, если было принято решение на ее выполнение или изучение деталей ее выполнения и по задаче были инициированы работы. Далее задача может быть переведена обратно в "Предложено", если изучение работ закончено и теперь необходимо принимать решение по ее реализации. Если же работы были выполнены, то задача переводится в следующее состояние для проверки результатов. Кроме этого, задача может быть закрыта в случае, если работы необходимо отменить или отложить.
  • Разрешено. Это состояние означает, что выполненные работы требуют проверки. Если проверка пройдена, то задача закрывается, если нет - возвращается снова в состояние "Активно".
  • Закрыто. Если задача в этом состоянии, то все работы по ней прекращены. Работы могут быть возобновлены в том случае, если задача была закрыто ошибочно или есть необходимость в продолжении отложенных ранее работ.

Рисунок 1. Задача в Agile (слева) и в CMMI (справа)

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

Кроме процессного подхода, т.е. использования одного процесса на всю организацию, можно использовать проектно-процессный подход, т.е. в соответствии от типа и важности проекта можно комбинировать процессы, которые будут в нем использоваться. Ведь не обязательно применять тяжелый и формальный процесс на проект, который будет длиться полгода и в котором будут принимать участие пять человек. И в другом случае, если есть длительный проект или проект с высокой степень важности, например система управления кораблем, то понятно, что применение Agile-методологий в нем приветствоваться не будут. Если в организации присутствуют оба типа проектов, то она может для одного проекта использовать Agile-шаблон, а для другого - CMMI.

Как все устроено?

Вся работа в проекте TFS строиться на основе шаблонов процесса. Шаблоны содержат в себе следующие основные составляющие:

• Руководство по процессу.
  Для любого нового проекта создается свой web-портал, который содержит полное описание процесса (см. Рисунок 2) на основе, которого ведется разработка. Руководство содержит в себе детальное описание ролей, работ, которые эти роли выполняют, а также полное описание рабочих элементов, их полей и состояний.
  
• Рабочие элементы. Для каждого рабочего элемента существует отдельное в специальном виде описание полей и их размещение на форме, состояний и возможные переходы между ними. Все новые рабочие элементы, которые формируются в проекте, создаются на основе этих описаний. Также предусмотрен механизм изменения полей, формы и жизненного цикла рабочих элементов.
  
• Отчеты. Каждый проект должен подвергаться отчетности. Отчетность дает понимание, в каком состоянии находится проект, входит ли он рамки бюджета, сколько работы выполнено и сколько еще предстоит выполнить, сколько дефектов было обнаружено и сколько уже исправлено и т.д. Шаблон процесса содержит в себе инициирующие отчеты, которые будут создаваться для каждого нового проекта.
  
• Шаблоны документов. В ходе проекта создает большое количество документации, по крайней мере, если используется процесс CMMI, и эта документация должна создаваться на основе каких-то общих шаблонов. Шаблоны процессов в TFS позволяют размещать и использовать в проектах не только рабочие элементы для выполнения проектного управления, но использовать проекты как общий источник проектной документации, планов работ, планов тестирования и т.д.
  

Рисунок 2. Описание задачи на web-портале

Кроме этого, шаблоны процессов включают в себя настройки версионного контроля, настройки интеграции с MS Project, группы доступа и т.д. В TFS с шаблонами процессов можно выполнять следующее (см. Рисунок 3):

1. Загрузить. Все шаблоны, которые использует TFS, можно сохранить на локальный диск, просмотреть и отредактировать.
2. Отправить. Новые или отредактированные шаблоны можно загрузить на сервер TFS для дальнейшего использования.
3. Удалить. Если шаблон процесса не актуален и не используется, то его можно удалить.
4. Использовать по умолчанию. Если для большинства новых проектов используется какой-то один шаблон процессов, то его можно сделать выбранным по умолчанию. И при создании нового проекта, он будет всегда первым в списке.

Рисунок 3. Операции с шаблонами процессов

Т.е. все описания рабочих элементов можно загрузить на локальный диск, причем, как вместе с шаблоном процесса, так и отдельно. Описание рабочего элемента представлено в виде специального xml-файла (см. Рисунок 4), которое можно проанализировать, изменить и обратно сохранить на сервер TFS. Описание рабочих элементов содержит:

• Поля - это описание наименования, типа поля, возможные значения для полей, списки значений, методы доступа к полям.
• Форма - описание визуального оформления рабочего элемента, группировка полей на форме, привязка элементов управления графического интерфейса к полям.
• Жизненный цикл - описание состояний и переходов между ними, перечень обязательных полей для состояния, ограничения для переходов.

Рисунок 4. Описание задачи

Ниже на рисунке (см. Рисунок 5) изображены варианты, которые TFS поддерживает для редактирования свойств рабочих элементов:

1. Рабочие элементы можно редактировать непосредственно в описании шаблона процессов. В этом случае все изменения, которые были сделаны, фиксируются только в шаблоне процессов и будут применены только для проектов, которые будут создаваться после применения изменений.
2. Рабочие элементы можно редактировать в функционирующем проекте. В этом случае все изменения будут применены только для одного проекта. Для этого метода применяются специальные утилиты для отдельного экспорта и импорта описаний рабочих элементов, которые поставляются вместе с TFS, - witexport и witimport.

Рисунок 5. Методы редактирования рабочих шаблонов

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

Как адаптировать?

После того, как в организации решили какой шаблон процесс использовать, то скорее всего в ближайшем времени появится желание что-то поменять, адаптировать под свои потребности. Изменения могут быть любыми, кто-то захочет поле добавить, элементы перегруппировать или изменить жизненный цикл рабочего элемента. И после того, как шаблон процесса выгружен на локальный диск, можно приступать к внесению изменений. Но разбираться со структурой xml-файла, пусть даже задокументированного, не всегда хочется. Поэтому рекомендуется в этих случаях использовать набор утилит, которые обеспечивают доступ к более широкому набору функций TFS, - Power Tools. Эти утилиты содержат все, что необходимо для изменения рабочих элементов:

• Редактор полей с возможностью их тонкой настройки.
• Визуальный редактор форм.
• Визуальный редактор жизненного цикла.

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

Попробуем рассмотреть изменение рабочего элемента на небольшом простом примере. Допустим, команда выбрала для своих проектов шаблон процессов CMMI. После длительной и кропотливой работы с использованием этого шаблона команда поняла, что им не хватает отдельного состояния для статуса задачи "Отложено". Т.е. подход к решению этой проблемы в шаблоне, когда задача переводится в "Закрыто" с переходом "Отложено", перестал разработчиков удовлетворять, т.к. в этом случае немного сложнее стоить отчеты по статусам задач в проекте. Кроме этого появилась необходимость добавить поле "Отложить до" содержащее дату, до которой работы будут отложены. Использование этого поля позволит команде организовать почтовую нотификацию, которая будет сигнализировать о том, что отложенные работы уже необходимо начинать при истечении отложенного срока, и позволит лучше организовать управление отложенными задачами.

Первым делом необходимо добавить новое поле к существующему рабочему элементу. Для изменения состава и характеристик полей рабочего элемента используется специальный редактор полей (см. Рисунок 6). Этот редактор позволяет создать новое поле, определить ему необходимый тип (строковый, целочисленный, текстовый, дата и т.д.), поведение полей (реакция на изменение значения в другом поле), определить возможные значения для полей. TFS также позволяет использовать списки для значений полей. Это могут быть постоянные списки, которые не должны меняться в процессе разработки, например, значения типа да/нет или дерево иерархии системы система/подсистема/модуль, значения типов дефектов и т.д. Также могут быть непостоянные значения, которые реализованы на основе специальных глобальных списков. Глобальные списки позволяют организовать изменение значений в списке поле без необходимости изменения самого рабочего элемента, например, это может быть список версий системы, список конфигураций для тестирования и т.д.

Рисунок 6. Создание нового поля

После того как поле добавлено, его необходимо отобразить на форме с помощью редактора форм (см. Рисунок 7). Этот редактор позволяет организовать все поля на форме рабочего элемента в удобном для использования виде. На форме поля можно объединять в группы, если они описывают какие-то общие характеристики, поля и группы полей можно выносить на отдельные вкладки, если полей много. Для каждого поля, которое будет отражено на форме, можно определить наиболее подходящий элемент пользовательского интерфейса, т.е. если это строковое поле, то это будет обычное текстовое поле, если это дата, то это будет поле с возможностью задания даты из календаря и т.д.

Рисунок 7. Редактор форм

И последний шаг - это формирование нового состояния и переходов для него. Утилиты Power Tools предоставляют возможность визуального редактирования жизненного цикла для рабочих элементов (см. Рисунок 8). С помощью такого редактора можно просто и наглядно изменять жизненный цикл рабочего элемента. Он позволяет добавлять, удалять состояния и переходы между ними, изменять их характеристики. Каждое состояние может иметь обязательные поля, например, "Отложить до" для нового состояния "Отложить". Также можно определить только определенный состав участников проекта, которые могут выполнять необходимые переходы, например, закрыть задачу может только менеджер проекта, проверив ее выполнение.

Рисунок 8. Редактор жизненного цикла

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

Рисунок 9. Готовая форма

Итог

Поставляемые шаблоны процессов с TFS для Agile и CMMI позволяют инициировать проекты разработки для любой команды малой или большой. Однако практика показывает, что стандартные решения не всегда могут отвечать всем ожидания компании внедряющей готовые решения. В любой компании есть свои сложившиеся стандарты, свои правила и методы работы. Поэтому TFS предусмотрена возможность редактирования шаблонов процессов, что позволяет адаптировать их под свои потребности. Команда разработки может взять любой готовый шаблон, будь-то Agile, CMMI или шаблон, скачанный из интернета, которых сейчас большое уже количество, и довести его до своих требований. Если же ни один шаблон не устраивает, можно пойти более радикальным путем, т.е. выполнить разработку своего собственного процесса с нуля. В любом случае TFS обеспечивает всем необходимым для того, чтоб помочь организовать в компании качественный и удовлетворяющий использующую TFS организацию процесс.