Типы рабочих элементов TFS: задачи против сценариев или оба варианта?

Question

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

Обычно я создаю сценарий для более крупных и общих единиц работы: например, «Создать функциональность, чтобы добавить строки сотрудника работодателю». Меньшими, более конкретными рабочими элементами будут задачи, например: «Создать форму детализации», «Создать метод сохранения на сервере» и т. Д.

Когда я проверяю изменения, я связываю набор изменений со сценарием И с конкретной задачей. Это хорошая привычка? Как вы справляетесь с задачами и сценариями? Какие-нибудь ресурсы для лучших практик?

Я также слышал, что сценарии на самом деле предназначены для случаев использования, это так?

Answer 1

Сценарии могут быть любой пользовательской историей.

Вам нужно только зарегистрироваться на задание. Когда задачи создаются, они должны быть сначала связаны со сценарием, а затем назначены разработчикам.

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

Нет смысла двойной обработки

Answer 2

В шаблоне MSF Agile сценарии также можно рассматривать как « User Story » - что-то вроде легкого гибкого варианта использования.

Сценарий детализирует общую картину функциональности, которую необходимо реализовать, записывая единый путь взаимодействия пользователя с частью системы. Например, в переполнении стека пара сценариев может быть «Задать вопрос» или «Ответить на вопрос». Сценарии и требования к качеству обслуживания можно рассматривать как рабочие элементы верхнего уровня в MSF Agile (т. Е. Рабочие элементы, определяющие систему), причем сценарии представляют собой функциональные требования, а качество обслуживания - нефункциональные требования.

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

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

Если вы часто связываете рабочий элемент со сценарием, вам может пригодиться следующий совет (http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html).), в котором показано, как изменить стандартный шаблон процесса MSF Agile, чтобы удалить возможность регистрации для разрешения сценария, но просто связать регистрацию с этим рабочим элементом .Регистрация при регистрации для долго выполняющегося рабочего элемента, такого как сценарий, почти всегда не то, что вам нужно, а поведение по умолчанию. из коробки.

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

Answer 3

Вы можете думать о сценариях как о представлении точки зрения пользователя, тогда как задачи - о точке зрения разработчика. Согласно документации MSF Agile сценарий «представляет собой единый путь взаимодействия с пользователем в создаваемой вами системе», а задача «идентифицирует конкретный элемент работы, который должен выполнить член группы».

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

Answer 4

Если под «настройкой TFS по умолчанию» подразумевается шаблон проекта «MSF для гибкой разработки программного обеспечения», сценарий определяется следующим образом:

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

Чтобы получить немного больше информации об этом, взгляните на папку «Documents / Process Guidance» в проекте в Team Explorer - она ​​довольно хорошо объясняет рекомендуемый процесс