Каковы недостатки объединения задач и рабочих элементов ошибок и использования только одного из них в TFS 2010?

Question

Я думал, что лучше использовать только рабочий элемент задания и игнорировать рабочий элемент ошибки.Это мое мышление, когда я настраиваю вещи для своей команды.Я пытаюсь понять, почему я не должен этого делать.С моей точки зрения, Задача - это либо новый элемент, либо элемент ошибки.Нет необходимости использовать два разных типа рабочих элементов.Чтобы это произошло в TFS, я начну с рабочего элемента «Ошибка» и создам настраиваемое поле («Тип элемента») для различения двух типов задач: новая / ошибкаИ новые задачи, и ошибки будут иметь одни и те же поля.Кто-нибудь видит какие-либо серьезные недостатки этого подхода?

Answer 1

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

Например, по умолчанию ошибки имеют свойство Triage, проблемы имеют срок выполнения, задачи имеют дисциплину.Состояния ошибки («Активно / Закрыто / Разрешить») отличаются от проблемы («Активно / Закрыто»).

Объединяя их в один тип рабочего элемента, вы теряете возможность индивидуально настраивать каждое из них.1005 *

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

Тип рабочего элемента также является стандартным столбцом во всех запросах.

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

Answer 2

Я бы посоветовал оставить ошибку и удалить задачу, если вы хотите объединить их. По умолчанию, когда вы регистрируете код и Resolve с ошибкой, он устанавливает статус Resolved и назначает его тому, кто его создал - обычно тестеру, но в вашем случае, возможно, PM. Затем этот человек может проверить, что работа выполнена, и закрыть ее. Вы можете настроить оповещения для их рабочих элементов, чтобы они получали электронное письмо и знали, что прогресс достигнут. В качестве альтернативы, если вы используете Задачу, при разрешении при регистрации она просто закрывается. Нет предупреждений, нет дальнейшего тестирования. YMMV, но в некоторых наших проектах мы используем Bug для таких вещей, как «пользователь хотел бы добавить новый отчет», и это хорошо соответствует нашему процессу. (Для других мы сохраняем различие для целей отчетности.)

Answer 3

Все сводится к 3 вещам:

1. Создание / расстановка приоритетов
2. Отчеты / уведомления
3. Завершение рабочего процесса

ОбычноСоздание задачи включает в себя поля, отличные от ошибок.Для ошибки вам нужно знать такие вещи, как окружение, в котором он вас уведомил, серьезность, приоритет и т. Д.

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

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

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

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

---

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

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