Работа нескольких команд в Microsoft Team Foundation Server 2012 и Visual Studio Scrum 2.0

Введение в Team Foundation Server 2012 и Scrum 2.0

Последняя версия шаблона процесса Scrum и решение Team Foundation Server 2012 предоставили пользователям множество новых функций и возможность работать эффективнее. Большая часть задач по взаимодействию и администрированию в рамках командных проектов выполняется в веб-интерфейсе. Командный обозреватель (Team Explorer) практически не используется.

В представлении Product Backlog (Журнал невыполненных работ) команды могут детализировать журнал невыполненных работ, быстро добавляя описания функциональности и изменяя их приоритет простым перетаскиванием вверх или вниз по списку. Функция прогнозирования наглядно демонстрирует успехи команды в спринтах и показывает завершение невыполненных работ, которое происходит в заданном для команды темпе. На должном уровне поддерживается планирование спринтов. Команда просто перетаскивает описания функциональности в новый спринт и добавляет задачи. После этого выводится автоматическое подтверждение, что команда берется за выполнение поставленных задач в соответствии со своими возможностями.

Представление Board (Доска задач) –– это интерактивная виртуальная панель со строками состояний; члены команды могут четко видеть, кто над чем работает и как продвигается выполнение спринта. На доске задач можно выводить задачи каждого участника команды, чтобы упростить проведение совещаний Scrum и управление личной производительностью. Использование доски не вызывает никаких трудностей. Это представление служит для изменения состояний задач, часов и назначений и автоматически сохраняется в фоновом режиме.

Как осуществляется поддержка нескольких команд

Все эти новые функциональные возможности легко реализуются в случае, если в рамках одного проекта работает одна команда. Однако часто бывает так, что невыполненную работу по продукту в рамках одного командного проекта выполняют несколько групп. В качестве примера приведем ситуацию, когда нескольких команд совместно работают над созданием продукта или системы электронной коммерции. Конечно, можно настроить командный проект на основе шаблона Scrum V2.0 для поддержки нескольких групп, однако алгоритм действия представлений Board и Product Backlog требует задания нескольких предположений и нуждается в некоторой доработке.

В VS2012 сценарий работы нескольких команд частично поддерживается за счет сопоставления пути области для каждой команды. Оно выступает в качестве фильтра для этих представлений: таким образом команды могут видеть свои подмножества данных. Однако даже и этот подход связан с некоторыми проблемами.

• Путь области больше недоступен для применения тем или категорий журнала невыполненных работ. И это основное препятствие для тех, кто пытается разобраться в содержимом больших журналов невыполненных работ.
• Фильтрация по пути области является бистабильной и использует один из вариантов.
  • Команда видит весь журнал невыполненной работы по продукту, однако представление Product Backlog для спринта не используется, поскольку невозможно отфильтровать элементы журнала другой команды.
  • Команда не видит весь журнал невыполненной работы по продукту (отображается только часть, ограниченная определенной областью), но для решения задач подходит журнал невыполненных работ по спринту. Кажется, этот вариант и является предпочтительным!
• Отсутствие полного обзора журнала невыполненных работ по продукту снижает эффективность принятия архитектурных решений и возможности совместной работы с другими командами над общим журналом невыполненных работ.
• Функция прогнозирования в представлении Product Backlog остается неэффективной до тех пор, пока не будет применена ко всему журналу, а не только к подмножествам команды, отфильтрованным по пути области.
• Команды не могут вводить требования в свои спринты, пока элементы журнала невыполненных работ не будут перемещены в путь области команды кем-то другим.
• Упомянутые выше проблемы приводят к тому, что элементы командам назначаются заранее, а это означает неоптимальное планирование и использование описаний функциональности.
• Одну из команд следует назначить командой по умолчанию, она наследует установку пути области от конфигурации командного проекта и не отображается в списках навигации как команда с названием.
• Новые элементы журнала невыполненной работы наследуют свой путь области от параметра пути команды по умолчанию, поэтому команды, не являющиеся заданными по умолчанию, не видят эти элементы.
• Даты начала и окончания спринта являются общими для всех команд. Это распространенная практика, однако для команд, работающих в разных странах, зачастую не совпадают праздничные дни и требуется корректировка дат спринта.
• Настраиваемое поле можно использовать как командное, однако для него, помимо высвобождения пути области, существуют те же проблемы, которые рассматривались выше.
• Реализация настраиваемого поля сопряжена с серьезными трудностями: имеются проблемы в процедурах проверки, элементы из журнала невыполненных работ могут исчезнуть, если будут неправильно написаны названия команд в рабочих элементах.

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

Конфигурация нескольких групп – шаблон пути области

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

Установка

В этом примере будут задействованы две команды: Team A и Team B, совместно работающие над одними и теми же незавершенными задачами по продукту в рамках общего командного проекта Scrum03.

Я создал три команды: две команды Scrum и третью команду Über Team; эта «команда команд» является командой по умолчанию (обратите внимание, что название команды выделено жирным шрифтом на снимке экрана ниже).

 

Über Team –– ведущая группа по решению многих упомянутых ранее проблем. Она обеспечивает другим командам прозрачность всего журнала невыполненных работ, чтобы они могли осуществлять действия по детализации невыполненных задач по продукту и совместное планирование. Участники обеих команд также входят в команду Über Team, поэтому могут использовать представление журнала невыполненных работ команды Über Team. В качестве контейнеров безопасности для трех команд использовались группы Windows, поэтому в представлении выше отображается только один участник для каждой команды.

 

Конфигурация пути области для команды Über Team должна быть задана как корневая, с входящими в нее подобластями. Это необходимо для отображения всего журнала невыполненных работ независимо от того, назначены ли элeмeнты конкретной команде.

 

 

 

 

Две команды Scrum получают отфильтрованные представления с помощью своего параметра пути области, поэтому в представлениях Product Backlog и Board отображаются только элементы журнала и задачи, переданные каждой команде. Параметр пути области для каждой команды должен быть настроен с определенным значением пути команды.

 

 

 

Конфигурация пути итерации одинакова для всех команд, поскольку они используют общие циклы выпусков и спринтов.

 

 

 

 

 

 

Принципы работы

На следующем снимке экрана показано представление Product Backlog c точки зрения команды Über Team; в нем отображается вся невыполненная работа по продукту. Обратите внимание: функция прогнозирования включена, что позволяет следить за ходом работы объединенных команд от спринта к спринту.

 

Команды могут совместно выбирать описания функциональности для использования в будущем спринте, а также способ их разделения между командами, своевременно вводить эти описания в собрание, посвященное планированию спринта каждой команды. Им потребуется задать каждое описание функциональности, используемой в следующем спринте, в конкретном пути области, чтобы оно появилось в представлениях Product Backlog и Board. Пока эта задача не будет выполнена, представления будут пустыми! Обратите внимание на перемещение PB06 в новый путь итерации спринта и путь области команды.

Чтобы ввести элемент журнала невыполненных работ в спринт 1, просто перетащите его туда. Этот элемент необходимо отредактировать для выбора команды, которая примет элемент журнала невыполненных работ в планирование спринта.

 

 

Закончив работу в представлении объединенной команды Über Team и выбрав элементы журнала невыполненных работ для планирования, команды могут переключиться в свои представления. Здесь находятся их собственные элементы журнала, к которым они могут добавлять задачи. Переключение между различными представлениями показано на фрагменте снимка экрана справа. Интересующие нас команды я выделил красными рамками. Посмотрите: у команды Über Team на самом деле нет названия, поскольку она является командой по умолчанию и проходит под именем командного проекта Scrum03. В этом примере происходит переключение из представления команды Über Team в представление команды Team A.

 

 

 

 

В представлении Product Backlog мы указали новый спринт, и здесь должны появиться выбранные элементы журнала. Если элементы не отображаются, возможно, указан неверный путь области или выбран неправильный спринт. На снимке экрана ниже обратите внимание на кнопку «+» слева от каждого элемента журнала невыполненных работ; она используется для добавления задач в процессе планирования спринта.

В этом примере мы рассматриваем вкладку Contents (Содержимое), однако имеется также вкладка Capacity (Ресурс работоспособности), где показана доступность каждого участника команды для спринта. Это цифры и гистограммы, отображаемые в разделе Work (Работа) на вкладке Contents (Содержимое) (см. область справа, выделенную красной рамкой). С помощью этой функции можно следить за тем, располагает ли команда достаточным количеством ресурсов для выполнения дополнительных задач в спринте.

 

 

Запланировав элемент журнала невыполненных работ и подтвердив наличие достаточных ресурсов для его выполнения, мы переводим его состояние в Committed (Подтверждено) (см. красную отметку в центре снимка экрана вверху).

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

 

 

 

Конфигурация нескольких команд - шаблон пути итерации

Попробуйте применить этот шаблон, если ваша команда использует путь области в качестве средства применения тем и классификации журнала невыполненных работ по продукту или если команде требуются различные даты спринтов. Этот подход использует дополнительный уровень в пути итерации и позволяет получить целостное представление журнала невыполненных работ по продукту. Команды получают возможность просматривать только собственные элементы на уровне спринта. В этом примере снова присутствует команда Über Team, однако ее роль скромна: она лишь поддерживает комбинированное представление для прогнозирования общего журнала невыполненной работы.

Тем не менее этот подход связан с определенной проблемой — стандартный график шаблона, показывающий оставшийся объем работы, не может обрабатывать дополнительный уровень в пути итерации. Простой способ отображения оставшегося объема работы –– использование функции создания отчетов Excel. Пример приведен в конце статьи. Компания RippleRock работает над альтернативным графиком, который будет реализован с помощью данного подхода. Этот график станет применяться ежедневно, а не от спринта к спринту. Мы надеемся, что вскоре этот отчет будет доступен для установок TFS по запросу…

Установка

Как и в предыдущем примере, у нас есть две команды: Team А и Dilberts, совместно работающие с одним журналом невыполненных работ по продукту в рамках одного командного проекта (ScrumDemo 01). Кроме двух команд Scrum, имеется онлайн-команда (аналогичная команде Über Team в первом примере) –– «команда команд».

Основные отличия этого подхода заключаются в конфигурации пути области и пути итерации, как показано ниже.

 

Путь области можно использовать для классификации журнала невыполненных работ по продукту, как продемонстрировано в примере.

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

Обратите внимание, что выбираемый путь области можно настроить таким образом, что подобласти войдут в состав родительской области и команда получит доступ ко всем дочерним элементам. Эта возможность недоступна для пути итерации.

 

 

 

Путь итерации имеет дополнительный уровень для спринтов команды в каждом стандартном узле спринта.

Команды могут выбирать индивидуальные даты начала и окончания спринта и получать отфильтрованные данные, чтобы заполнять представление Product Backlog и Board.

По умолчанию новые элементы журнала невыполненных работ по продукту создаются в узле, заданном по умолчанию в качестве итерации журнала невыполненных работ для команды (или команды Über Team в наших моделях).

Чтобы ограничить элементы журнала невыполненных работ для выпуска, просто переместите их в узел пути итерации выпуска, в этом примере — Online MVP.

Если посмотреть на конфигурацию пути итерации команды Team А, то можно увидеть, что она настроена только для просмотра своих спринтов.

 

 

Здесь мы видим, что представление «команды команд» настроено для просмотра только родительских спринтов, а не отдельных спринтов команды. Это важно, поскольку позволяет эффективно комбинировать прогнозы команд в общем журнале невыполненных работ из представления журнала «команды команд».

 

 

 

 

 

 

 

Принципы работы

На следующем снимке экрана показано представление Product Backlog с точки зрения объединенной «команды команд»; в нем отображается вся невыполненная работа по продукту. Функция прогнозирования показывает предполагаемое продвижение объединенных команд от спринта к спринту на основе родительских узлов спринта, а не отдельных спринтов команды. 

 

 

В конкретном представлении журнала Product Backlog команды мы видим не только спринты для этой команды, но и все содержимое журнала. На следующем снимке экрана команда перетаскивает элемент журнала Product Backlog в спринт для планирования.

 

Другая команда также видит весь журнал невыполненных работ, включая элементы, запланированные командой Team A. Это понятно из пути итерации: он указывает принадлежность элементов командам.  При планировании и выполнении задач из журнала незавершенных работ команды могут в значительной степени придерживаться собственного представления и им действительно не нужно постоянно переключаться на представление «команды команд», как мы это делали с помощью шаблона пути области.

Как видно из представления планирования команды Team A, все новые возможности и компоненты журнала невыполненных работ и доски задач функционируют так, как было запланировано корпорацией Майкрософт.

 

 

Единственная проблема заключается в том, что отчет об оставшемся объеме работ не справляется со спринтами команд. Мы постоянно будем работать над доступностью отчета об оставшемся объеме работ. Однако с помощью функции построения отчетов Excel в TFS ​​можно просто и быстро создать отчет, аналогичный представленному ниже.

Comments

• Anonymous
  January 21, 2013
  Burndown в новом TFS невозможно использовать для одного спринта, т.к. рисует идеальную линию не учитывая, что в выходные дни никто не работает.

• Anonymous
  May 09, 2013
  Выходные дни (например, в двухнедельной итерации) на самом деле не сильно влияют на представление успеваемости.