Seminar:VSTS: управление элементами работ (Work Items)

Материал из Wiki Test Lab
Перейти к: навигация, поиск

Назад    Главная
 

Источник

Дальше »


13. VSTS: управление элементами работ (Work Items)

Определение, свойства, жизненный цикл. Реквизиты. Средства использования (на примере элемента работы task). Доступ к элементам работы. Элементы работы при планировании. Элементы работы в дальнейшей разработке. Элементы работы в отчетах.

Определение, свойства, жизненный цикл

Обзор. Вернемся к элементам работ VSTS – ключевым дискретным характеристикам проекта, таким как задача (task), ошибка (bug), риск (risk) и т.д. Эти характеристики выделены в VSTS с целью конкретизировать объекты управления в проекте, сделать это управление сквозным в следующих смыслах:

  • обеспечить доступ к одной и той же информации для разных участников (и, главное, ролей!) в проекте; например, доступ к ошибкам для менеджеров, разработчиков и тестеров;
  • прослеживать связи одних элементов с другими, например, изменений исходного кода и теми ошибками, для исправления которых эти изменения были сделаны.


Благодаря единой среде, включающей в себя средства поддержки различных видов элементов работы, в VSTS гораздо проще строить связи между элементами работы различного вида, отслеживать их изменения, чем при использовании отдельных продуктов поддержания процесса. Например, не нужно ждать момента, пока информация об ошибке или задаче будет перенесена из одной системы в другую. Ведь традиционно программные средства планирования (там, где определяются задачи), управления ошибками (там, где происходит учет ошибок), средства версионного контроля – это разные средства. Кроме того, в силу наличия единого информационного репозитория в VSTS возможны строгие ссылки на такие объекты, определенная сборка или тест, и получение, по соответствующему запросу, подробной информации по разным фильтрам, на разную глубину детализации. Возможно также настроить автоматическую генерацию элементов работы, например, ошибок при неудачной автоматической сборке или при автоматическом прогоне тестов.


13-01.jpg

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


Реквизиты. Каждый элемент работы принадлежит определенному типу. Тип элемента работы определяет набор реквизитов, для каждого из которых можно задать:

  • имя, отображаемое в отчетах и пользовательском интерфейсе TFS;
  • имя для ссылок (Reference Name), используемое для указания ссылок на данный реквизит из других мест шаблона процесса;
  • тип – один из предопределенных типов для реквизитов: date, int, string, bool; типы могут системными, то есть являться ссылками в одно из типовых хранилищ TFS; например, тип build results указывает на информацию о результатах сборки;
  • текстовое описание реквизита, отображаемое во всплывающих подсказках, отчетах и сообщениях;
  • режим использования в отчетах – можно ли использовать этот реквизит в отчетах и как его следует использовать.

Бывают также системные реквизиты, имена, типы и обработка которых "прошита" в TFS. Это, например, такие реквизиты как состояние (state), причины (reasons), связи (links).

Отдельного внимания заслуживают имена для ссылок. Они позволяют идентифицировать данный реквизит не только в пределах одного типа элементов работы, но и в пределах всего TFS-проекта, а также при переносе элементов работы из проекта в проект. Для поддержания уникальности этих имен рекомендуется использовать концепцию пространств имен (namespaces). Кроме того, имена для ссылок служат для организации своего рода пула реквизитов – одинаковое имя для ссылок, использованное в разных типах элементов работы, подразумевает одинаковый смысл соответствующих реквизитов, а также одинаковую их роль с точки зрения формирования отчетов. Существует набор предопределенных имен для ссылок, соответствующих системным реквизитам. Реквизиты с соответствующими именами для ссылок могут подвергаться особой обработке со стороны TFS.


Каждый реквизит может либо не участвовать в отчетах вообще, либо участвовать в следующих режимах:

  • как измерение (Dimension) – в качестве измерения при построении отчетов; этот режим допустим для чисел, дат и строковых полей с предопределенным набором значений;
  • в деталях (Details) – то есть в качестве детальной информации отчета; этот режим допустим для чисел, дат и произвольных строк;
  • как метрика (Measure) – то есть в отчетах используется некоторая статистическая функция, вычисленная для значений данного реквизита.

Жизненный цикл элемента работы определяется двумя системными реквизитами: состоянием и причиной.

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

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

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

Для настройки типов рабочих элементов используется продукт Team Foundation Power Tools1). Он является свободно распространяемым продуктом и содержит, в частности, визуальный редактор, позволяющий просматривать и редактировать жизненный цикл элемента работы в визуальном виде – см. рис. 13.2. На этом рисунке показан граф жизненного цикла для типа рабочего элемента "ошибка". Мы можем видеть три состояния – Active (обнаружена ошибка), Resolved (ошибка исправлена), Closed (ошибка закрыта), – и переходы между этими состояниями. В каждом переходе имеется прямоугольник Transition, в котором содержатся параметры перехода – причина, действия, которые нужно выполнить, список реквизитов, который должен быть изменен при переходе и некоторую другую информацию.


13-02.jpg

Рис. 13.2. Жизненный цикл элемента работы типа "Ошибка".

Еще одной важной составляющей описания жизненного цикла реквизита являются правила, которые описывают различные ограничения на значения реквизитов элемента работы, в том числе:

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

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

Кроме того, можно описать правила, применяемые в разные моменты времени, в том числе:

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

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

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


Средства использования

Пример: элемент работы task. Кратко опишем пример, который будет использован в дальнейшем для объяснения средств использования элементов работы.

Рассмотрим элемент работы типа task (задача). Как правило, в начале проекта некоторый эксперт (как правило, системный архитектор, ведущий разработчик и т.д.) проводит анализ всей необходимой работы по проекту и разбивает её на подзадачи, устанавливая ответственных, сроки и т.д. Эти подзадачи с соответствующими атрибутами и являются элементами работы типа task.

Затем менеджер проекта, с учетом списка всех задач и их взаимосвязей, строит календарный план. На этом этапе менеджеру могут оказаться полезными средства Project и Microsoft Excel – он пользуется ими на основе соответствующих мостов, имеющихся в TFS.

Далее разработчики начинают реализовывать соответствующие задачи. После того, как было внесено последнее изменение и задача выполнена, разработчик переводит элемент работы в состояние Resolved и информация о нем войдет в следующий отчет по автоматической сборке. При обнаружении ошибок реализации тестер создаст новый элемент работы типа Bug и проставит ему связь с исходной задачей. Если же тестер обнаружит, что функциональность реализована не в полном объеме, то он может решить перевести задачу обратно в состояние Active. Если же реализованная функциональность достаточно стабильна, а имеющиеся ошибки не являются критичными, тестер переводит задачу в состояние Closed.

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

Создание элементов работы. Для создания нового элемента работы можно воспользоваться пунктом меню Team, добавляемым в Visual Studio вместе с Team Explorer, как показано на рис. 13.3.




13-03.jpg Рис. 13.3. Создание элемента работы.


После выбора пункта меню Add Work Item отобразился список из существующих в данном проекте типов элементов работы. Далее, после выбора соответствующего пункта меню будет открыто окно редактирования нового элемента работы, как показано на рис. 13.4:



13-04.jpg

Рис. 13.4. Редактирование элемента работы.

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



13-pic01.jpg панели инструментов. После сохранения элемент работы автоматически получит уникальный идентификатор и будет сохранен в системе управления элементами работы. Для добавления связанных элементов работы можно воспользоваться командой контекстного меню Add Related Work Item, как показано на рис. 13.5:



13-05.jpg Рис. 13.5. Добавление связанного элемента работы.

После добавления связанного элемента работы откроется окно редактирования для вновь созданного элемента работы, при этом связь между двумя элементами работы будет добавлена автоматически, как показано на рис. 13.6.



13-06.jpg Рис. 13.6. Список связей.

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

Заметим, что контекстное меню на рис. 13.5 демонстрирует еще одну полезную при создании элементов работы возможность – шаблоны элементов работы. Шаблон определяется набором "предзаполненных" атрибутов элемента работы и может сильно облегчить жизнь участникам проекта, которым приходится создавать много однотипных элементов.


Доступ к элементам работы. Члены команды, работающие c VSTS через Team Explorer, имеют доступ к элементам работы, открыв в текущим проекте вкладку Work Items (см. рис. 13.7). При этом элементы работ доступны не как огромная куча (легко понять, что их может быть очень много в каждом проекте – сотни и даже тысячи), а с помощью специальных фильтров – запросов (queries). Они распределены по папкам Team Queries и My Queries. В первой папке располагаются запросы, видимые и используемые всей командой. Во второй папке располагаются запросы, созданные конкретным пользователям для себя лично. Все это можно увидеть на рис. 13.7.



13-07.jpg Рис. 13.7. Запросы на элементы работы.

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



13-08.jpg Рис. 13.8. Список элементов работы.

Способ отображения списка (набор колонок, сортировка, и т.д.) настраивается индивидуально для каждого пользователя, а форма детальной информации об элементе работы настраивается для проекта в целом для каждого типа элементов работы в отдельности.

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

Выделенные (selected) элементы работы можно экспортировать в пакеты Microsoft Project, Word, Excel, используя соответствующие кнопки панели инструментов


13-pic02.jpg

и


13-pic03.jpg

соответственно. Изменения, произведенные с элементами работ, выполненными в этих пакетах, можно затем загрузить обратно в TFS используя соответствующие библиотеки-расширения офисных приложений. Элементы работы при планировании. Не сложно заметить, что такая важная роль как менеджер проекта, не получила собственного издания Visual Studio. Связано это с тем, что основная платформа Visual Studio плохо приспособлена для задач, которые приходится решать этой роли. Гораздо более удачно для этого подходят офисные приложения – Microsoft Excel и Microsoft Project. Поэтому для более полного вовлечения менеджера в информационное пространство проекта Team System предоставляет специальные мосты.

Рассмотрим пример с пакетом Project. В этом пакете, при наличии на том же компьютере Team Explorer, появляетcя пунrт меню Team. В нем нужно выбрать необходимый проект в VSTS, как показано на рис. 13.9.



13-09.jpg Рис. 13.9. Меню Team в Microsoft Project.

После этого появится возможность использовать другие пункты меню Team, в частности – пункт меню Get Work Items, позволяющий считать необходимые элементы работы с сервера. При выборе этого пункта меню появится диалог, показанный на рис. 13.10. Поиск нужных элементов работы можно осуществлять в соответствии с существующим запросом, по заданным идентификаторам или по названию элемента работы.



13-10.jpg Рис. 13.10. Форма поиска элементов работы.

После того, как нужные элементы выбраны, они будут автоматически импортированы в Project – см. рис. 13.11:



13-11.jpg Рис. 13.11. Элементы работы в Microsoft Project.

После импорта элементов работы менеджер может проводить с ними все действия, которые он привык выполнять в Project. В данном случае он создает полноценный план работ, как показано на рис. 13.12.



13-12.jpg Рис. 13.12. Редактирование элементов работы в Microsoft Project.

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


13-13.jpg

Рис. 13.13. Доступ к реквизитам элемента работы.

После того, как все действия в Project выполнены, для внесения их в VSTS воспользоваться командой Publish, а для получения обновлений – командой Refresh. Кроме того, сам файл с планом можно сохранить на диске или портале SharePoint. При этом информация о связи с сервером TFS так же сохранится.

Элементы работы в дальнейшей разработке. После того, как был построен план и назначены исполнители определенным задачам, ответственные исполнители увидят их в результатах соответствующих запросов (типа My Tasks). И начнут выполнять соответствующую работу. При этом придется вносить некоторые изменения в систему контроля версий, и в этот момент у них появляется возможность указать связанные с данными изменениями элементы работы – ошибки, которые исправляются и задачи, которые выполняются в данном изменении кода и т.д.

Элементы работы в отчетах. Одной из основных задач подсистемы работы с отчетами является отражения реального актуального статуса проекта и анализ его истории. Большинство отчетов в TFS базируются именно на элементах работы и отражают динамику их изменения. В частности, отчет Project Velocity, представленный на рис. 13.14, отражает количество закрытых задач в соответствии с днями (неделями или месяцами) и позволяет судить о том, насколько эффективно двигается проект.

По оси абсцисс на этом рисунке откладывается время, по оси ординат – количество элементов работы (в данном случае – дефектов). Далее мы можем видеть два графика – зеленый (сколько ошибок было закрыто), желтый – сколько было найдено. Серая пунктирная линия обозначает среднюю интенсивность работы в проекте, измеряемую как количество закрытых ошибок. Из рисунка видно, что в проекте были всплески производительности (в начале и в конце), а также спад в середине – в это время разработчик был в отпуске и тестер не тестировал его компоненту.



13-14.jpg Рис. 13.14. Отчет Project Velocity.




Дальше »

Личные инструменты