|
|
|||||||||||||||||||||||||||||
|
Адаптируем процессы TFS под свои потребностиИсточник: cmcons Шамрай Алексадр
ВведениеХоть Microsoft Visual Studio Team Foundation Server (TFS) и поставляется с готовыми шаблонами процессов, но удовлетворить они могут не всех. Для новых и молодых команд в принципе стандартный набор шаблонов процессов TFS может покрыть все потребности процесса разработки, особенно для команд использующих гибкие (Agile) подходы к разработке. Некоторые при внедрении TFS стараются приспособиться под то, что имеется, и в некоторых случаях это проходит. Но приспособиться под стандартные шаблоны TFS не всегда представляется возможным, да и не всегда правильно. Ведь у каждой компании есть свои сложившиеся традиции в разработке, своя культура производства ПО, которые описывают текущие процессы разработки ПО в компании. Применив существующие стандарты к процессам компании можно получить некий гибрид процесса разработки, который будет наиболее подходить для компании. В этой статье мы постараемся объяснить, как можно реализовать такие нестандартные процессы с помощью шаблонов TFS. Что имеем?Как я указывалось выше, с TFS поставляется два встроенных шаблона процессов:
Т.к. оба шаблона процессов направлены на покрытие потребности двух разных методов работы, то и наборы рабочих элементов, которыми можно оперировать в ходе проекта разработки используя эти методы, для этих шаблонов различны (см. Таблица 1). Основными рабочими элементами в Agile-методологии являются сценарии использования или взаимодействия с системой, с помощью которых описываются возможности системы и вокруг которых и стоится разработка. Кроме того, используются задачи для идентификации работы разработчиков и ошибки, которые были обнаружены при тестировании системы. CMMI в свою очередь использует более широкий набор рабочих элементов: отдельно выделенные требования для определения и документирования возможностей системы, запросы на изменение для обработки запросов от заинтересованных лиц, ошибки для идентификации и исправления ошибок в системе; и т.д. Таблица 1. Список рабочих элементов для Agile и CMMI
Кроме того, что между шаблонами Agile и CMMI различный набор рабочих элементов, похожие рабочие элементы имеют различный жизненный цикл. Если, например, взять задачу (см. Рисунок 1), то набор состояний для шаблонов будет следующий:
Рисунок 1. Задача в Agile (слева) и в CMMI (справа) Любая команда, которая хочет использовать один из этих шаблонов, должна ознакомиться с их содержанием, руководствами по процессу, которые поставляются вместе с TFS и после этого решить какие правила по процессу для нее будет приемлемы. Кроме процессного подхода, т.е. использования одного процесса на всю организацию, можно использовать проектно-процессный подход, т.е. в соответствии от типа и важности проекта можно комбинировать процессы, которые будут в нем использоваться. Ведь не обязательно применять тяжелый и формальный процесс на проект, который будет длиться полгода и в котором будут принимать участие пять человек. И в другом случае, если есть длительный проект или проект с высокой степень важности, например система управления кораблем, то понятно, что применение Agile-методологий в нем приветствоваться не будут. Если в организации присутствуют оба типа проектов, то она может для одного проекта использовать Agile-шаблон, а для другого - CMMI. Как все устроено?Вся работа в проекте TFS строиться на основе шаблонов процесса. Шаблоны содержат в себе следующие основные составляющие:
Рисунок 2. Описание задачи на web-портале Кроме этого, шаблоны процессов включают в себя настройки версионного контроля, настройки интеграции с MS Project, группы доступа и т.д. В TFS с шаблонами процессов можно выполнять следующее (см. Рисунок 3):
Рисунок 3. Операции с шаблонами процессов Т.е. все описания рабочих элементов можно загрузить на локальный диск, причем, как вместе с шаблоном процесса, так и отдельно. Описание рабочего элемента представлено в виде специального xml-файла (см. Рисунок 4), которое можно проанализировать, изменить и обратно сохранить на сервер TFS. Описание рабочих элементов содержит:
Рисунок 4. Описание задачи Ниже на рисунке (см. Рисунок 5) изображены варианты, которые TFS поддерживает для редактирования свойств рабочих элементов:
Рисунок 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 организацию процесс. Ссылки по теме
|
|