Используйте TFS для отслеживания ошибок из поддержки производства


18

Я только что перешел в новую компанию, и они используют TFS 2010 (2012 год через пару месяцев) в качестве своей системы контроля версий и недавно начали использовать ее в качестве системы отслеживания работы для разработчиков.

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

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

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


Стоит отметить, что если вы используете TFS и у всех пользователей есть учетная запись домена Windows, им никогда не придется «входить в TFS». Если вы перейдете на веб-портал TFS вашей команды, они автоматически войдут в систему, используя учетные данные домена для текущего пользователя Windows.
17 из 26

Как вы в итоге решили это? Имейте сегодня ту же проблему, нуждайтесь в системе продажи билетов, имейте предварительную версию TFS2013. То, что я хочу, это UserVoice, но мне придется отказаться от предварительной TFS в VSO, чтобы получить такую ​​интеграцию.
EJA

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

Ответы:


6

Это в значительной степени зависит от того, какие поля вы хотите, как указано в 17 из 26: TFS очень настраиваемый. Причина, по которой я хотел бы сделать это, а не использовать что-то вроде JIRA, заключается в том, что вы получаете единый взгляд на то, над чем работают ваши разработчики, а не на объединение двух систем.

У TFS также есть планирование емкости ресурсов, и если вы не указываете производственные дефекты в своем планировании (а они занимают значительную долю вашего времени), то вы на самом деле не планируете свои мощности. На самом деле я бы сказал, что это идеальное решение для команд, где разработчики используют TFS и поддерживают Production (например, DevOps).

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

Во всяком случае, к основному вопросу. Я использую шаблоны CMMI TFS (которые на самом деле отлично работают с Agile BTW), и я просто добавил одно поле в одно из раскрывающихся списков.

Вот шаги:

Установить электроинструменты TFS

Откройте шаблон рабочего элемента с сервера

Открыть шаблон рабочего элемента с сервера

Открыть шаблон ошибки

Изменить поле дисциплины

Область дисциплины - это «вид» работы, связанный с дефектом. Стандартные значения:

  • Анализ
  • Пользовательский опыт
  • Обучение пользователей
  • развитие
  • Тестовое задание

Что мы только собираемся сделать, это добавить «Производство» в этот список. Сначала отредактируйте поле Discipline:

Редактировать дисциплину

Затем перейдите на вкладку «Правила» и измените правило ALLOWEDVALUES:

введите описание изображения здесь

Затем нажмите «Новый» и добавьте «Производство» в качестве одного из значений.

введите описание изображения здесь

Нажмите «ОК» несколько раз, пока не вернетесь к списку полей.

Сохранить шаблон рабочего элемента

ОК, теперь все готово. Вы можете создавать новые ошибки и указывать их тип как производство. Я также создал бы несколько запросов на рабочие элементы, изучая производственные дефекты, и добавил бы их к закрепленным элементам. Наконец, посмотрите на существующие запросы об ошибках и, возможно, измените их порядок так, чтобы ошибки «Production» появлялись первыми (если это возможно).


Отлично, вы настроили TFS так, чтобы разработчики могли видеть «производственные ошибки» ... как рабочая группа (которая не является частью команды разработчиков и не имеет VS) получает доступ к ним и управляет ими?
gbjbaanb

4
Ну, во-первых, они могут получить доступ к TFS через веб-интерфейс, используя бесплатную лицензию заинтересованных сторон. В нашей организации мы отслеживаем производственные инциденты через систему на основе ITIL, но автоматически интегрируем их с TFS, как мой ответ указан в третьем абзаце.
Шон Хедерман

4

Нет, все верно - главный ALM от Microsoft не очень полезен вне Visual Studio и команд разработчиков.

Вы можете получить доступ к рабочим элементам с помощью Team Explorer (это очень урезанная версия VS) или получить доступ к нему через веб-сайт TFS. Ни один из них не особенно хорош, так как поля ошибок напоминают древние «корпоративные» средства отслеживания ошибок, которые я имел несчастье использовать в прошлом.

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

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


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

@ 17of26 Я знаю - поля, которые вы используете, полностью настраиваемы, но то же самое можно сказать и о Excel, если вы использовали это как средство отслеживания ошибок. Проблема с OP заключалась в том, что шаблон предоставляет вам только эти типы рабочих элементов - и у вас не может быть разных типов (например, запрос функции или внешняя ошибка), вы должны настроить (или скопировать) один из существующих и использовать его - который в свою очередь, это приводит к огромному количеству настроек, которые вы должны выполнить, чтобы вписать их в свои рабочие процессы. Так как у вас есть несколько баг-трекеров?
gbjbaanb

Я думал, что OP не хотел иметь несколько баг-трекеров и просто пытался выяснить, как не-разработчики могли взаимодействовать с отслеживанием рабочих элементов TFS, которое разработчики уже использовали (что для меня - то, как вы хотели бы что-то делать) ,
17 из 26

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

1
Вы можете добавить столько пользовательских типов рабочих элементов, сколько захотите.
Мистер Хинш - Мартин Хиншелвуд,

3

Пользователи, не являющиеся разработчиками, могут получить доступ к системе отслеживания рабочих элементов TFS с помощью веб-браузера для перехода на портал командных проектов. Чтобы найти URL, перейдите в Team-> Show Project Portal в Visual Studio. Оттуда любой, у кого есть разрешения, может просматривать, создавать или изменять рабочие элементы. Они также могут генерировать все виды отчетов, чтобы посмотреть на состояние вещей.

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

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


3

Этот пост в блоге Microsoft описывает запланированные улучшения в TFS, которые должны помочь в снижении накладных расходов:

  • Новая форма рабочего элемента, которая проще для глаз и включает в себя варианты обсуждения и упоминания, аналогичные Facebook и Twitter.
  • Настраиваемые поля
  • Улучшена поддержка Канбана, например, быстрое добавление задач к рабочему элементу.
  • Также упоминаются информационные панели и метрики.
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.