Используем ли мы TFS 2010 неправильно?

Наша команда является новой для TFS2010. Исторически мы использовали нашу собственную матрицу бизнес-требований (матрицу трассировки) Excel. Он имеет типичные столбцы, такие как:

Идентификатор требования | Проект | Группа правил | Бизнес-правило | Тип... и т.д.

В столбце "Правило бизнес-правил" читается следующее:

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

Из-за строгости нашей отрасли в отношении документации, аудитов и т.д. мы выбрали MSF для CMMI вместо MSF для Agile в качестве выбора нашего технологического шаблона.

У нас было много дискуссий о том, как лучше всего реализовать "способ, которым мы работаем", в мир TFS 2010. Суть наших проблем сводится к следующему:

Похоже, мы должны следить за отношением "родитель/ребенок" между "Требование → Задача на вкладке" Реализация ". Однако это означает, что у нас есть задача для каждого Требования (что кажется избыточным и чрезмерно зернистым).
Нам нравится думать о задаче как о чем-то менее гранулированном (т.е. "Разработка экрана исходящей консоли".)
Мы хотели бы, чтобы разработчик смог просмотреть назначенные им задачи и легко увидеть, какие требования (функциональные и не функциональные) связаны с этими задачами.
Отслеживание является высокоприоритетным, однако нам не обязательно, чтобы он был чрезвычайно гранулированным (вплоть до фактических строк кода). Как мы видим, это сделало бы развитие чрезвычайно утомительным и контрпродуктивным. Мы хотим разумного баланса в этом отношении.

Является ли наш подход действительно круглой привязкой к квадратной дыре, которая, по-видимому, кажется? Или, мы просто недопонимаем/не хватает чего-то? Мы чувствуем, что у нас есть хорошее понимание различных типов рабочих элементов.

Чтобы добавить немного больше контекста, наше понимание состоит в том, что требования типа "Feature" являются "родительскими" более гранулированными требованиями, такими как Functional, Non-Functional, QoS. Мы понимаем, что тип требований сценария аналогичен используемому случаю.

Итак, мы считаем, что TFS 2010 следует этой иерархии:

Требование (функция)
- Требование (функциональное)
  - Задача

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

Мы полагаем, что мы могли бы пропустить вкладку "Реализация" (и отношения между родителями и дочерними элементами) и просто использовать вкладку "Все ссылки". Это позволяет нам более гибко связывать требования и задачи с помощью других типов ссылок, таких как "Связанные" или "Влияет/зависит от"... но, большой улов там, заключается в том, что он разбивает встроенные отчеты TFS 2010 (особенно в отношении отслеживание хода выполнения/часы).

Любое понимание понимается.

Ответ 1

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

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

Я не уверен, знаете ли вы о некоторых параметрах настройки, которые доступны, поэтому я просто упомянул некоторые из тех, которые я использовал при настройке TFS для моей компании.

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

При необходимости вы можете добавлять переходы, состояния, поля, вкладки и т.д.

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

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

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

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

НТН

Ответ 2

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

Ответ 3

Прежде всего, добро пожаловать в мир TFS.:)

Нет ничего плохого в том, как вы хотите работать. Выбранная иерархия прекрасна, и TFS будет поддерживать любой набор типов рабочих элементов (WIT) и отношений (ссылок), которые вы им требуете. Вкладка "Реализация" и все другие вкладки, которые показывают отношения с другими WIT, являются просто фильтрами для всего списка WIT, с которыми связан ваш тип (т.е. на вкладке "Требование к реализации" отображаются все рабочие элементы, имеющие тип Требование или Задача, и иметь отношение parent/child).

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

Это относительно просто сделать, особенно если вы используете редактор процессов, который является частью Team Foundation Power Tools. Если вы хотите изменить страницы ссылок, все это делается в части макета типа рабочего элемента.

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

Имея это в виду, я всегда предпочитаю, чтобы разработчик работал только над задачами. Более того, задачи всегда должны вытекать из требования (или ошибки, или запроса на изменение, и так далее). Задача, которая не возникает в результате требования, может указывать на то, что работа либо не нужна, либо плохо спланирована.

Надеюсь, это поможет, Ассаф.