Використовуйте TFS для відстеження помилок у виробничій підтримці

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

Однак, схоже, не існує системи відстеження помилок, яка б використовувалася людьми поза розробкою та тестом. Виробнича підтримка отримує звіти про проблеми, виправляє їх на ходу та наразі звітує перед користувачами. Це потрібно змінити, але я не хочу дуже мати систему відстеження помилок і відстеження роботи розробників.

Чи є спосіб, що я можу створити дуже легкий спосіб введення помилок у TFS, подібний до того, що робить FogBugz? Увійти в TFS, щоб заповнити звіт про помилку, здається, набагато важче, і вам потрібно пов’язати його з конкретним додатком. Підтримка може це зробити, але я хочу мати можливість тріадізувати елемент і потенційно змінити асоціацію на щось інше, ніж додаток.

Раніше я використовував FogBugz, і додаючи помилку, ви можете додати багато / мало, як хочете, до предмета, щоб він був принаймні записаний, а пізніше ви зможете повернути його назад, щоб отримати більше інформації, коли ви прийдете до тріади квитка .

Це багато в чому залежить від того, які поля ви хочете, як зазначено в 17 з 26: TFS є дуже настроюваним. Причина , я хотів би зробити це , на відміну від використання що - щось на зразок JIRA є те , що ви отримуєте єдине уявлення про те , що ваші розробники працюють, на відміну від того , щоб агрегатних двох систем.

TFS також має планування ресурсних можливостей, і якщо ви не виявляєте виробничих дефектів у своєму плануванні (а вони займають значну частину вашого часу), ви не дуже плануєте свої потужності. Я б сказав, що це ідеальне рішення для команд, де розробники використовують TFS та підтримують виробництво (наприклад, DevOps).

Це не означає, що ви не можете використовувати інші інструменти для основної роботи з виробничої підтримки / ITIL, вам потрібно просто переконатися, що вони інтегруються вручну або бажано автоматично. Більшість таких інструментів дозволяють розмістити спеціальні гачки, і TFS, безумовно, це робить.

У всякому разі, до головного питання. Я використовую шаблони CMMI TFS (які насправді добре працюють з Agile BTW), і я просто додав одне поле до однієї зі спадних спадів.

Ось такі кроки:

Встановіть електроінструменти TFS

Відкрийте шаблон робочого предмета з сервера

Відредагуйте поле «Дисципліна»

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

• Аналіз
• Досвід користувача
• Освіта користувачів
• Розвиток
• Тест

Що ми тільки збираємось зробити - це додати до цього списку "Виробництво". Спочатку відредагуйте поле «Дисципліна»:

Потім натисніть на вкладку Правила та відредагуйте правило ALLOWEDVALUES:

Потім натисніть «Нове» та додайте до «Виробництво» як одне із значень.

Натискайте кнопку "ОК" кілька разів, поки ви не опинитесь у списку полів.

Збережіть шаблон робочого предмета

Гаразд, зараз ви закінчили. Ви можете створити нові помилки та вказати їх тип як Виробництво. Я також створив би кілька запитів на робочі позиції, де переглядаються виробничі дефекти, і додати їх до закріплених вами елементів. Нарешті, подивіться на існуючі запити помилок та, можливо, змініть їхнє впорядкування, щоб спочатку з’явилися помилки "Виробництво" (якщо це можливо).

Ні, це правильно. Прем'єрний ALM Microsoft не дуже корисний за межами Visual Studio та команд розробників.

Ви можете отримати доступ до елементів роботи за допомогою Провідника Team (який є дуже скороченою версією VS) або отримати доступ до нього через веб-сайт TFS. Немає особливо гарних варіантів, оскільки поля помилок нагадують давні дрейграрі-помилки, які я використовував у минулому.

Немає реального розмежування помилок у TFS - є лише один трекер, який ви фільтруєте, використовуючи поле в самому елементі, тому використовуйте поле категорії, а потім створюйте звіт, який показує лише певний тип категорії. Я думаю, що це ваш єдиний реалістичний варіант із TFS.

Якщо ви хочете відстежувати зовнішні проблеми, я вважаю, що TFS - це поганий вибір, вам краще скористатися чимось на зразок Джира чи Редмін і використовувати це для управління помилками - їхні інтерфейси набагато, набагато приємніші та простіші, ніж TFS. Мені особливо сподобалося те, як можна надіслати електронний лист до Redmine, і це створює нову проблему для вас, що було ідеальною функцією зручності використання для працівників, які не відвідували сайт.

Користувачі, які не розробляються, можуть отримати доступ до системи відстеження робочих елементів TFS за допомогою веб-браузера для переходу на портал Team Project. Щоб знайти URL-адресу, перейдіть у Команда-> Показати портал проектів у Visual Studio. Звідти кожен, хто має дозволи, може переглядати, створювати чи змінювати елементи роботи. Вони також можуть створювати всілякі звіти, щоб переглянути стан речей.

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

Інформація, необхідна для введення помилки, також залежить від налаштування TFS. У нашому випадку нам потрібні заголовок, кроки для відтворення та збірка, в якій він був знайдений. Система відстеження робочих елементів TFS дуже потужна та гнучка. Це може бути настільки складно або просто, як ви хочете, щоб це було - все зводиться до того, як ви його налаштували.

У цьому дописі в блозі Майкрософт описано заплановані вдосконалення системи TFS, які повинні допомогти підтримати нижчі витрати

• Нова форма робочого предмета, яка простіша на очах і включає варіанти обговорення та згадки, схожі на facebook та Twitter.
• Спеціальні поля
• Покращена підтримка Kanban, наприклад, швидке додавання завдань на робочий предмет.
• Також згадується інформаційні панелі та показники.