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

Question

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

ID требования | Проект | Правило группы | Бизнес-правило | Введите ... и т. Д.

В нашем столбце бизнес-правил указано что-то вроде следующего:

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

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

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

• Похоже, что мы должны следовать отношениям "родитель / потомок" между Требованием -> Задача на вкладке Реализация. Однако это означает, что у нас есть задача для каждого требования (которое кажется избыточным и слишком гранулированным).
• Нам нравится думать о Задаче как о чем-то менее детализированном (т. Е. «Разработать экран Outbound Console».)
• Мы бы хотели, чтобы разработчик мог просматривать назначенные им Задачи и легко видеть, какие Требования (Функциональные и Нефункциональные) связаны с этими Задачами.
• Трассируемость является высокоприоритетной, однако нам не обязательно, чтобы она была чрезвычайно детальной (вплоть до реальных строк кода). На наш взгляд, это сделало бы развитие чрезвычайно утомительным и контрпродуктивным. Мы хотим разумного баланса в этом отношении.

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

Чтобы добавить немного контекста, мы понимаем, что требования типа «Feature» являются «родителем» более детальных требований, таких как функциональные, нефункциональные, QoS. Мы понимаем, что тип сценария «Требование» аналогичен сценарию использования.

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

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

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

НТН

Answer 2

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

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

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

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

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

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

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

Answer 3

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