VSTS: поддержка различных моделей процесса

Поддержка шаблонов процесса

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

При создании в VSTS каждого нового проекта, сразу после выбора имени проекта, пользователь выбирает шаблон процесса разработки для этого проекта. Весь последующий процесс создания проекта определяется этим шаблоном. Шаблон может быть отдельно разработан или подправлен существующий.

Шаблон процесса содержит шесть основных разделов, в рамках которых можно осуществлять настройку работы TFS.

1. Классификация (Classification) – описание областей работы, итераций и настройка интеграции с Microsoft Project. Области работы – это способ для категоризации работ в проекте. Примером области работы может быть как направление деятельности (разработка, тестирование, документирование и т.д.), так и работа над определенной частью проекта (серверная часть, клиент, инфраструктура и т.д.).
2. Отслеживание элементов работы (Work Item Tracing) – описание типов элементов работы, включая задание их жизненного цикла, определение набора элементов работы и запросов, создаваемых по умолчанию для нового проекта.
3. Отчеты (Reports) – описание отчетов проекта на специальном XML-языке RDL (Report Definition Language). Имеющиеся в шаблоне отчеты по умолчанию можно использовать "as is", а также исправлять и дополнять. Создание полностью нового вида отчетов является довольно трудоемкой работой.
4. Портал (Portal) – настройка шаблона портала в SharePoint с тестовым описанием процесса разработки, а также набором рабочих документов проекта (планов, дизайн-спецификаций и пр.). На основании этого шаблона будет автоматически формироваться портал для каждого нового проекта.
5. Группы и права доступа (Groups & Permissions) настраиваются для использования системы управления версиями, а также для различных правил жизненного цикла элементов работы.
6. Контроль версий (Source Control) – набор настроек для системы контроля версий, включая набор политик внесения изменения, позволения или запрещения множественного взятия файлов на редактирование и т.д.

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

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

Инструменты настройки. Для управления шаблонами процесса разработки используется утилита Process Template Manager ( рис. 16.1), доступная из меню TFS Settings (эта утилита устанавливается вместе с Team Explorer). Этот менеджер позволяет загружать и выгружать шаблоны, а также определять шаблон, используемый для новых проектов по умолчанию.

увеличить изображение
Рис. 16.1. Менеджер шаблонов

С точки зрения реализации шаблон процесса разработки является набором XML-файлов, которые, пожалуй, никому не захочется редактировать "вручную". К счастью, существует инструменты, позволяющие значительно упростить этот процесс^{1http://msdn.microsoft.com/en-us/vsts2008/aa718802.aspx} . Эти инструменты входят в уже упоминавшийся нами выше пакет Power Tools. Эти инструменты доступны из меню Tools/Process Editor (см. рис. 16.2). Кратко перечислим и охарактеризуем их.

• Редактор типов элементов работы, который позволяет редактировать определения типов элементов работы, включая наборы реквизитов и жизненный цикл. Может быть использован как для редактирования файлов с описанием типов элементов работы, экспортированных с помощью Process Template Manager, так и для редактирования типов, находящихся внутри одного шаблона процесса. Кроме того, этот редактор может быть использован для импорта/экспорта типов элементов работы в/из шаблон процесса, что особенно полезно при распространении сделанных изменений по разным проектам. Более подробно этот редактор уже рассматривался выше.
• Редактор шаблона процесса разработки позволяет редактировать остальные аспекты шаблона процесса разработки. Может быть использован только для редактирования шаблона, выгруженного из TFS в файловую систему.
• Редактор глобальных списков позволяет определить списковые типы для реквизитов элементов работы, а также управлять множеством значений в них. По умолчанию TFS автоматически поддерживает глобальный список сборок, однако пользователь может определить и другие списки^{2Заметим, что помимо настраиваемых глобальных списков в TFS существуют и встроенные системные списки, связанные с различными аспектами деятельности: группы и пользователи, состояния элементов работы и причины перехода, списки итераций и областей работы и т.д.} .
• Просмоторщик реквизитов элементов работы – это небольшая утилита, позволяющая просмотреть все используемые реквизиты всех типов элементов работы.

Рис. 16.2. Инструменты редактирования шаблона процесса

Заметим, что разработка шаблона процесса является очень трудоемкой задачей, требующей от исполнителя как знания принципов работы TFS, так и хорошего знакомства с бизнес-процессами своей компании. Расходы на разработку собственного шаблона будут оправданы только для достаточно больших компаний и в долговременной перспективе. Для небольших компаний и проектов можно рекомендовать другой подход – использования одного из стандартных, существующих шаблонов, наиболее близко подходящих под бизнес процесс, и постепенная настройка необходимых параметров.

Обзор существующих шаблонов

На данный момент существует достаточно широкий выбор свободно распространяемых шаблонов процесса разработки, которые можно было бы использовать в качестве основы^{3http://msdn.microsoft.com/ru-ru/teamsystem/aa718801(en-us).aspx} . Наиболее известными являются следующие шаблоны.

• MSF for Agile Software Development – один из двух шаблонов, входящих в поставку TFS. Описывает достаточно простой вариант методологии MSF, используемый для разработки небольших проектов. Входит в стандартную комплектацию TFS.
• MSF for CMMI – шаблон, используемый для более компаний, подразумевающий большее число типов элементов работы, а также больше формальных процедур разработки. Входит в стандартную комплектацию TFS.
• Conchango SCRUM – шаблон, описывающий широко известную гибкую методологию SCRUM. Не входит в стандартную комплектацию TFS.

MSF for Agile Software Development

В этом шаблоне используются стандартные роли MSF, которые подробно обсуждались выше. В рамках поддержки процесса MSF for Agile соответствующий шаблон объявляет следующие основные типы элементов работы.

• Сценарий (scenario) – функциональное требование к системе в виде некоторого сценария взаимодействия пользователя и системы, описанное на естественном языке как последовательность действий. Сценарий описывает только линейный путь развития событий, а для описания различных ветвлений используются дополнительные сценарии.
• Требование к качеству сервиса (Quality of Service Requirement, QoS) – описание нефункционального требования к системе (то есть требования, которое не может быть выражено в терминах сценария взаимодействия), например, быстродействие и эффективность использования памяти.
• Задача (Task) – задание на выполнение некоторой ограниченной по объему работы в проекте. Для каждой роли задачи могут иметь свою специфику: для разработчика это написание кода, реализующего часть сценария или направленного на достижение определенного качества, а для тестера – написание тестовых сценариев.
• Ошибка (Bug) – элемент работы, использующийся для того, чтобы отслеживать и устранять проблемы и ошибки, обнаруженные в системе.
• Риск (Risk) – некоторый аспект управления проектом, который может оказать влияние на ход проекта (как правило, негативное).

По умолчанию вместе с активацией этого шаблона на портале Share Point разворачиваются следующие документы.

• План разработки в Microsoft Project, настроенный на импорт элементов работы, относящихся к области работы "Разработка". Используется для планирования работы разработчиков.
• План разработки тестов – то же самое, только направленно на планирования работы тестеров.
• Список проблем – список выявленных проблем, которые необходимо отслеживать (элементов работы с проставленным флагом "Is Issue").
• Список (Check List) основных требований к проекту и их текущий статус.
• Cписок неупорядоченных элементов работы, которые нужно приоретизировать и запланировать.

Кроме того, для поддержки процесса используются следующие отчеты.

• Ошибки по приоритету – показывает процентное соотношение в проекте ошибок разной степени серьезности и, таким образом, позволяет оценить степень эффективности тестирования.
• Рейтинг ошибок – показывает соотношение вновь открытых ошибок к закрытым и оставшихся открытых. Позволяет судить о "здоровье" продукта.
• Сборки – позволяет оценивать изменение качества сборок.
• Скорость проекта – отчет, демонстрирующий насколько активно закрываются элементы работы, т.е. насколько быстро команда решает поставленные перед ней задачи.
• Индикаторы качества – объединяет несколько индикаторов, включая количество дефектов, уровень тестового покрытия и т.д.
• Отчет о нагрузочном тестировании – показывает результаты нагрузочного тестирования.
• Регрессия – показывает тесты, которые проходили раньше, но теперь стали падать.
• Реактивация – показывает то, сколько элементов работы заново переходит в активное состояния после исправления.
• Связанные элементы работы – еще один способ просмотра связей элементов работы друг с другом.
• Оставшаяся работа – показывает количество элементов работы, которые закрываются, а которые остаются и появляются с течением времени.
• Незапланированная работа – показывает соотношение сделанного к запланированному и к незапланированному.

Помимо выше перечисленных есть еще несколько отчетов, возвращающих списки элементов работы, однако они редко используются для анализа.

Scrum

Шаблон для работы в методологии Scrum был разработан сообществом разработчиков, в настоящий момент поддерживается компанией Conchagp и доступен здесь http://scrumforteamsystem.com. В этом шаблоне используются стандартные роли Scrum, которые подробно обсуждались выше. Определяются следующие элементы работы.

• Product Backlog Item – высокоуровневое описание определенной функционального или нефункционального требования. Содержит описание, приоритет, установленный Produсt Owner, а также предварительную оценку трудоемкости. Во многом аналогичен сценарию MSF for Agile.
• Sprint – содержит информацию о текущем или запланированном Sprint, включая текущее состояние и объем доступных для спринта ресурсов.
• Sprint Backlog Item – более низкоуровневое описание задачи, сформированное самой командой. Аналогична задаче MSF.
• Bug – ошибка, обнаруженная при тестировании. Ошибки становятся частью Product Backlog и получают приоритеты от Product Owner.
• Sprint Retrospective – описание некоторого элемента (например, проблемы, удачного нововведения), идентифицированного в рамках Sprint Review Meeting и требующего дальнейшего изучения или выполнения некоторых действий.
• Impediment – нечто, реально или потенциально мешающее эффективной работе команды. Во многом аналогично риску из MSF.

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

Среди поставляемых с шаблоном отчетов следует выделить следующие.

• Bugs Count – показывает количество ошибок, отсортированных по состоянию и степени влияния на процесс тестирования.
• Bugs Fixed and Found – соотношение найденных ошибок к закрытым.
• Bug History – показывает количество открытых ошибок в соответствии с их влиянием на процесс тестирования, а также изменение этого количества со временем.
• Bug Priority – показывает распределение ошибок по отношению их влияния на процесс тестирования.
• Bug Resolution Time – показывает насколько быстро исправляются найденные ошибки.
• Development To Test cycle time – демонстрирует, сколько проходит времени между выполнением работы и началом тестирования по этой работе.
• Product Burndown – отчет, демонстрирующий, как быстро снижается количество работы, которую нужно сделать в контексте Product Backlog. Может показывать прогресс по дням или спринтам, а также позволяет увидеть общую тенденцию и предсказать дату завершения работ.
• Product Cumulative Flow – показывает общее состояние Product Backlog в виде соотношения открытых и закрытых элементов, а также их изменения со временем.
• Sprint Burndown и Сumulative Flow – тоже самое, только для Sprint Backlog.

Отдельного упоминания заслуживает система Task Board for Team System, которая позволяет визуализировать представления основного средства управления и мониторинга в Scrum – доски с задачами. Эта система получает информацию о всех элементах Sprint Backlog с сервера и визуализирует их в виде стикеров на доске, позволяя изменять их состояния путем перетаскивания, см. рис. 16.3. Этот продукт можно бесплатно скачать по ссылке http://www.scrumforteamsystem.com/en/TaskBoard/default.aspx.

увеличить изображение
Рис. 16.3. Доска задач