Нужно ли создавать ЗАДАНИЕ для каждой ошибки в TFS (облаке), чтобы отслеживать время?
Используя TFS Cloud (myproject.visualstudio.com), нет полей Предполагаемое, Заполненное, Остальное, чтобы добавить время к ошибке. Действительно ли нам нужно создавать рабочий элемент TASK, который называется "fix - bugname" для каждой ошибки, просто чтобы записать, сколько времени ушло на исправление каждой ошибки?
Я ценю большие ошибки, это имеет смысл, но некоторые из них - орфографические ошибки или другие мелкие проблемы.
Это тогда удваивает количество рабочих элементов в списках для всех?
какие-либо предложения?
5 ответов
Ну, посмотрев на это, быстрый ответ - да.
Преимущества этого просты. ЗАДАЧА - это "самая маленькая" вещь, которую вы можете сделать в TFS, и она всегда назначается одному человеку.
Учитывая это, создавая задачи для выполнения "работы", вы можете, по крайней мере, увидеть, кто выполнил работу, и отчитаться за нее (не глядя на историю элемента).
Вы также можете "отскочить" от назначенного для фактического БАГА, например, чтобы заставить кого-то еще проверить его, или оставить его назначенным тому, кто "владеет" этой ошибкой, а исправление может быть назначено другим (задачам).
Если вы используете Agile или CMMI шаблон, ошибки не будут отображаться на панели задач.
В идеале вам нужно создавать задачи, чтобы представлять работу, которую вы или члены команды делаете. Например, вам нужно создать задачу разработки для устранения проблем и задачу QA для тестирования.
Также вы должны следить за статусами ошибки параллельно с задачей. то есть, если разработчик работает над исправлением, то ошибка должна быть назначена разработчику, и она должна быть активной, а задача разработки также должна быть активной.
После завершения разработки разработчик может закрыть основную задачу, устранить ошибку и назначить ее для тестирования в QA. Если все идет хорошо, инженер-тестировщик закроет задание на тестирование, и в то же время он / она должны также закрыть ошибку.
Технически да. То, что мы решили сделать (просто для простоты и не надоедать нам с еще большим количеством пользовательских историй в TFS), мы создаем одну пользовательскую историю для каждого спринта и называем ее "BUGS - SPRINT #". В соответствии с этим у нас будут задачи, которые отслеживают работу / время, потраченное на ошибки.
Мы также называем задачи по категориям. Например, если в пользовательском интерфейсе есть ошибка, мы называем ее (пример) пользовательским интерфейсом - стрелки не появляются снова.
Не уверен, что это лучший способ сделать это, но он выполняет отслеживание усилий и поддерживает TFS в чистоте.
Мы используем Visual Studio 2012. Именно так мы справляемся с этой ситуацией. Мы создали пользовательскую историю "Устранение, повторное тестирование ошибок". Разработчики каждой итерации, которые должны исправить ошибки, создают ОДНУ задачу для всех ошибок. Разработчик добавляет комментарии к каждой исправленной ошибке и соответственно обновляет время. QA человек также добавляет одну задачу для итерации для повторного тестирования ошибок. QA человек обновляет свою задачу соответственно для каждой ошибки. Все разработчики и все сотрудники QA создают дочерние задачи для одной и той же пользовательской истории.
Я так понимаю, вы используете шаблон "Microsoft Visual Studio Scrum". Поля в рабочих элементах зависят от используемого вами шаблона.
Для ошибок в шаблоне Scrum мы обычно покрываем усилия в поле "Усилия".