Типы рабочих элементов TFS: задачи против сценариев или оба варианта?
В настройке TFS по умолчанию есть три типа рабочих элементов: сценарий, задача и ошибка. Это последнее довольно просто, и задача также: это определенная работа для члена команды, чтобы закончить. Но я думаю, что сценарий немного расплывчатый.
Я обычно создаю сценарий для больших и более общих единиц работы: например, "Создать функциональность, чтобы добавить строки сотрудника работодателю". Меньшими, более конкретными рабочими элементами будут задачи, например: "Создать форму детализации", "Создать метод сохранения на сервере" и т. Д.
Когда я проверяю изменения, я связываю набор изменений со сценарием И с конкретной задачей. Это хорошая привычка? Как вы справляетесь с задачами и сценариями? Любые ресурсы для лучших практик?
Я также слышал, что сценарии на самом деле предназначены для случаев использования, это так?
4 ответа
Сценарии могут быть любой пользовательской историей.
Вам нужно только зарегистрироваться на задание. Когда задачи создаются, они должны быть сначала связаны со сценарием, прежде чем назначаться разработчикам.
Таким образом, связь между проверками и сценарием является автоматической (и подлежит регистрации).
Нет смысла в двойной обработке
В гибком шаблоне MSF сценарии также могут рассматриваться как " пользовательская история" - что-то вроде легкого гибкого варианта использования.
Сценарий детализирует общую картину функциональности, которую нужно реализовать, записывая единый путь взаимодействия пользователя с частью системы. Например, в переполнении стека пара сценариев может быть "Задать вопрос" или "Ответить на вопрос". Сценарии и требования к качеству обслуживания можно рассматривать как рабочие элементы верхнего уровня в MSF Agile (т. Е. Рабочие элементы, определяющие систему), причем сценарии представляют собой функциональные требования, а качество обслуживания - нефункциональные требования.
Я имею тенденцию создавать несколько задач из каждого сценария и обычно записываю только свои проверки в отношении задачи. В TFS 2010 появятся должным образом иерархические рабочие элементы, которые упростят процесс отчетности. В настоящее время ассоциации рабочих элементов являются двунаправленными (то есть вы можете сказать, что задача связана со сценарием, но вы не можете сказать, что она является ее дочерней).
Нет ничего плохого в том, чтобы пометить вашу регистрацию в соответствии с задачей и сценарием, просто она создает больше работы для вас при регистрации. Кроме того, сценарий может быть реализован рядом разработчиков, поскольку задача, как правило, не выполняется. на гранулярность деятельности отдельных лиц.
Если вы часто связываете рабочий элемент со сценарием, вам может пригодиться следующий совет ( http://www.woodwardweb.com/vsts/top_tfs_tip_3_r.html). В нем показано, как изменить стандартный шаблон процесса MSF Agile, чтобы исключить возможность регистрации для разрешения сценария, но просто связать регистрацию с этим рабочим элементом. Разрешение при регистрации для долго работающего рабочего элемента, такого как Сценарий, почти всегда не то, чего вы хотите, а стандартное поведение по умолчанию.
Надеюсь, это поможет.
Вы можете думать о сценариях как о представлении точки зрения пользователя, тогда как задачи - о точке зрения разработчика. В соответствии с гибкой документацией MSF сценарий "представляет собой единый путь взаимодействия с пользователем через создаваемую вами систему", а задача "определяет конкретный элемент работы, который должен выполнить член группы".
Задачи могут быть связаны со сценариями. При регистрации вы, как разработчик, решили задачу, а не сценарий, поэтому вам следует связать набор изменений с этой задачей.
Если под "настройкой TFS по умолчанию" подразумевается шаблон проекта "MSF для гибкой разработки программного обеспечения", сценарий определяется следующим образом:
Сценарий - это тип рабочего элемента, записывающий единственный путь взаимодействия пользователя с системой. Когда персона пытается достичь цели, в сценарии записываются конкретные шаги, которые они предпримут, пытаясь достичь этой цели. Некоторые сценарии запишут успешный путь; другие запишут неудачный. При написании сценариев будьте конкретны, так как существует множество возможных путей.
Чтобы получить немного больше информации об этом, внимательно посмотрите на папку "Документы / Руководство по процессу" в проекте в Team Explorer - она достаточно хорошо объясняет рекомендуемый процесс.