TFS и Scrum - конфигурация наилучшей практики для областей, итераций, итерации отставания, итерации спринта

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

вот мои лучшие усилия, чтобы ответить на ваши вопросы:

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

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

Вопрос 2) предполагая, что вышеуказанная конфигурация команды в порядке, мы затем правильно " сопоставляем "каждую из областей выше каждой команде, т. е. для команды" клиент команда "укажите область" Клиент А " (и все подзоны) как области, которые будут принадлежать этой команде. Как насчет области по умолчанию, можно ли установить корень области "клиент A" по умолчанию для команды?

это действительно правильно и должно привести к созданию всех ваших рабочих элементов, когда эта команда выбрана с этими значениями по умолчанию. Многие организации также создают родительское или основное отставание, где создаются разные элементы, заказываются, а затем разделяются на соответствующее отставание команды, как Грег Бур, Product Owner for the TFS Agile Planning Tools, о котором говорится в его сообщении TFS vNext: настройка проекта, чтобы иметь основной отставание и подгрупп.

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

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |---> Release 2
        |   |---> Release 3
        |
        |---> Product B
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

    |--> Client B (This is also out team boundary - ie. we have another TFS Team for Client B)
        |---> Product C
        |   |---> Release 1
        |   |---> Release 2
        |
        | (ETC)

в то время как все еще не динамический это позволит этот сценарий. Однако я бы все равно сохранил свой $\TeamProject\Client A\ProductA структура управления версиями и не фильтровать это вниз. Это просто разделение процесса планирования, и оно не должно распространяться на другие части вашего решения ALM.

Вопрос 3) кажется, что это сложнее, чтобы получить итерации правильно, особенно когда дело доходит до TFS, показывая отставание. В частности, для настройки итерации TFS Scrum 2 кажется, что я должен выбирать (флажок) только те итерации уровня листа, которые для планирования и последующего развития. Таким образом, расширяя приведенный выше пример, мы можем иметь, что "команда клиента A" будет доступна для начала работы над новым продуктом B в течение следующих 4 недель (предположим, 2 недельные спринты). Будем ли мы тогда выбирать только (флажок) "Sprint 1" и "Sprint 2" из выпуска 1? Правильно ли я понимаю/использую его?

вы, но вы действительно смотрите на 3 спринта, чтобы иметь действительное отставание как часть процесса Scrum. Я бы рекомендовал последовательно нумерация спринтов последовательно, так что в пользовательском интерфейсе вы не будете путаться на Sprint 2, Когда вы также отметьте Sprint 4, если он называется Sprint 1. Также приятно вести учет уровня опыта текущей команды.

-> Team Project (Iteration root)
 |—> Team Boundary (This could be one or more teams)
    |--> Client A (This is also out team boundary - ie. we have a TFS Team for Client A)
        |---> Product A
        |   |---> Release 1
        |   |   |---> Sprint 1
        |   |   |---> Sprint 2
        |   |   |---> Sprint 3
        |   |---> Release 2
        |   |   |---> Sprint 4
        |   |   |---> Sprint 5
        |   |   |---> Sprint 6
        |   |---> Release 3
        |   |   |---> Sprint 7
        |   |   |---> Sprint 8
        |   |   |---> Sprint 9
        |
        | (ETC)

но вы принципиально правы в отношении технического процесса и результата, которого он достигнет.

Вопрос 4) Выбор итерации отставания команды-это может быть проблематично из-за нашей концепции иметь команды на одного клиента, а не команды на продукт, но, возможно, я просто понимаю это неправильно. В настройках областей TFS вы указываете, какие итерации"итерация отставания для команды". Моя проблема в том, что наш PBI (элементы отставания продукта) будет специфичен для продукта и не хочет смешивать их с PBIs из другого продукта. Так что я пока не могу понять, какое влияние будет, если мы выберем область " клиент A "в качестве" итерации отставания для команды "вместо, возможно,"продукта B". Думаю, я ... запутаться здесь - Какой разумный выбор?

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

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

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

Он может. Некоторые организации предпочитают добавлять раскрывающийся список "команда" в свои рабочие элементы (например, шаблон Conchango/EMC) и использовать его в качестве командного обозначения, которое можно настроить в конфигурации Agile Planning Tools по умолчанию. Таким образом, вам не нужно назначение команды в области или итерации, если вы попав против этого. У меня нет рекомендации, в любом случае без дополнительной информации о том, как настроена ваша организация.

Вопрос 5) веб-сайт веб-доступа TFS - для любой данной команды в разделе "Работа / рабочие элементы | общие запросы" есть предопределенные запросы в папке " текущий спринт "(заблокированные задачи; отставание спринта; и т. д.), Но кажется, что эти запросы жестко закодированы против "корневого проекта\выпуска 1\спринта 1" - если они не будут автоматически узнайте, какой текущий спринт задан датами, определенными для итераций? Если нет, то какова наилучшая практика для поддержания этих запросов?

Вариант 1: каждый спринт тратит 2 минуты, необходимые для изменения запросов

Вариант 2: создать инструмент, чтобы сделать это для вас

Вариант 3: иметь дополнительный" текущий " узел итерации в вашем выпуске и переместить текущую активную итерацию ниже этого узла. Затем задайте запросы укажите "под", что "клиент a\Product a \Release 1\Current". Тогда быстрее изменить вложенную итерацию один раз, и все запросы будут работать. Затем вам нужно только изменить текущий, но один раз за выпуск.

знаете ли вы о некоторых качественных TFS 2012 и Scrum 2 конкретных учебных / учебных пособий, которые могут помочь решить эти вопросы, или дать некоторые рекомендации для успешной установки Scrum 2 TFS?

Я бы рекомендовал Профессиональная подготовка разработчиков Scrum от Scrum.org или / и взаимодействие с консультантом ALM.