Разница между элементом журнала продукта и компонентом в типах рабочих элементов Team Foundation
У меня есть вопрос о Microsoft Team Foundation. В Visual Studio, Team Explorer, я могу создать новый рабочий элемент. Типы рабочих элементов здесь диктуются выбранным шаблоном процесса вашей команды; Я не уверен, какой шаблон процесса мы используем. В любом случае, в Team Explorer, когда я хочу создать новый рабочий элемент, мне предоставляется список типов рабочих элементов для выбора, среди которых "Элемент незавершенного производства" и "Функция".
Я заметил разницу между двумя типами, связанными с целевой датой разрешения. Для элемента журнала невыполненных работ это может быть продиктовано датой окончания итерации. Для функции это не так ясно. Элемент также связан с итерацией (и датой окончания итерации), однако компонент также имеет отдельное поле, которое называется "Целевая дата". Текст для наведения мыши на целевую дату - "Целевая дата для завершения функции".
Должен ли я выбрать "Элемент незавершенного производства" или "Функция" в качестве типа рабочего элемента для моих новых рабочих элементов? Какая разница между этими двумя?
7 ответов
Похоже, вы используете шаблон процесса Scrum. На сайте TFS опубликована очень краткая информация об элементах и функциях журнала невыполненных работ и идее создания нового типа рабочего элемента. http://www.visualstudio.com/en-us/news/2013-jun-3-vso.aspx
Разница между ними заключается в том, в какой степени детализации вы хотите работать с вашими рабочими элементами:
- Журнал незавершенного производства товаров состоит из задач и оценивается усилия.
- Функции состоят из элементов журнала незавершенного производства и имеют целевые даты.
Мне не удалось найти каких-либо официальных указаний относительно того, когда следует использовать функции в сравнении с элементами незавершенного производства, но я создал свое собственное руководство, на котором я основываю этот ответ... http://www.nsilverbullet.net/2013/06/ 04 / особенности самопомощь-нам-план-работа-лучше-в-команде-фундаментный сервис-хватка-процесс /
Должны ли вы создать функцию или элемент журнала незавершенного производства?
- Если вы думаете / надеетесь, что новый рабочий элемент, который вы собираетесь создать, поместится в одном спринте, вы должны создать элемент журнала невыполненных работ по продукту, а затем разбить его на задачи для вашего спринта.
- Если вы думаете / знаете, что новый рабочий элемент не уместится в один спринт, вам следует создать компонент и определить все элементы, обеспечивающие ценность, в спринте (элементы журнала незавершенного производства), на которые можно разбить компонент, и использовать их при планирование будущих спринтов.
[Обновление 2014-05-19]
Microsoft опубликовала дополнительную информацию о том, как использовать компоненты и концепцию гибкого портфеля, реализованную в TFS, https://msdn.microsoft.com/en-us/library/dn306083(v=vs.120).aspx
Поскольку TFS применяет стратегию гибкой разработки, я думаю, что мы можем сказать:
Feature = Epic, Backlog item = История
Эпическое содержание похожих историй.
Вот как я это использую. Под инструментами "Работа" -> "Журналы" перечислены "Функции" и "Журналы работы". Я начну с функций, так что на данный момент нет никаких элементов в журнале. Я добавляю функции, выбрав "Компоненты" под заголовком "Журнал ожидания" и добавив имя формы в форму, затем сохранив и закрыв. Слева от каждой новой добавленной функции есть зеленый знак +. Нажмите на знак плюс, и появятся варианты выбора. Выберите "Пункты незавершенного производства". Когда он откроется, введите имя элемента журнала в верхнем поле, как в разделе "Функции". Вы создаете эти элементы журнала, всплывающих окон нет. Заполните другую информацию по мере необходимости, затем сохраните и закройте. После создания элементов Журнала нажмите зеленый + на вновь созданных Журналах. Введите имя рабочего элемента, как вы делали для элементов журнала и функций. При добавлении рабочих элементов включите спринт в поле итерации, и они будут в спринте при его открытии. Ничего из этого нигде не задокументировано, что я мог найти. Я надеюсь, что это достаточно подробно.
У меня были те же сомнения, что и у OP, и мои мысли были согласованы с ответом @josant, что очень разумно для меня.
С другой стороны, я использую книгу Хундхаузена [1] в качестве справочника для принятия TFS+Scrum.
Он сказал такие вещи, как:
Функция - это отдельная единица функциональности, которая обеспечивает ценность для пользователя или бизнеса. PBI может быть достаточно большим, чтобы иметь несколько функций.
а потом:
Функция может быть разбита на несколько сценариев. Сценарий - это описательная часть, которая описывает рабочий процесс или последовательность шагов через функцию, которая осуществляет один путь к достижению ожидаемого результата.
и продолжает развивать эти идеи.
Мне кажется, что Хундхаузен говорит о сценариях использования [2], но все же я чувствую, что его предложение несколько противоречит интуиции, и, похоже, TFS не будет ориентироваться на этот метод анализа. Я обнаружил, что на него ссылаются в литературе по scrum, которую я читал.
Вероятно, это просто вопрос выбора конвенции, с которой вы чувствуете себя более комфортно и придерживаетесь ее.
Особенность - это портфель продуктов.
http://tfs.visualstudio.com/en-us/learn/create-your-backlog.aspx
Как другие говорили здесь:
- Особенности: Верхний уровень
- Журналы: один уровень ниже функций (функция состоит из элементов журнала)
Помните, что вы можете СВЯЗАТЬ рабочие элементы и можете отображать их в виде дерева. Таким образом, вы можете связать элемент невыполненного задания с компонентом, а позже вы можете связать задачу с элементом невыполненного задания. Таким образом, вы получите хороший иерархический древовидный список.
Особенность - это уровень до "элементов невыполненных заказов". Команда определяет работу как инициативы высокого уровня и разбивает их на функции. который далее разбит и определит работу, которая должна быть сделана как "Задержка". ссылка http://msdn.microsoft.com/en-us/library/dn306083.aspx?