TFS 2013 Использование и рабочий процесс в реальном мире

Question

Команда, с которой я справляюсь, уже много лет использует TFS, но мы использовали стороннюю систему для отслеживания ошибок и функций. Я хочу обновить нашу команду до TFS 2013 года, и я проделал много чтений и исследований, как TFS управляет рабочими элементами, отставаниями, итерациями, задачами и т. Д. И хотя я понимаю принципы того, что «можно» сделать, я «Мне трудно представить, как« наша команда будет работать с этими рабочими элементами в качестве задач ».

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

1) Отставание продукта - Под «графике конфигурирования и итераций», что является концепция для установки текущей итерации отставания? Наша команда использует короткие 2-недельные итерации с номером сборки, но устанавливает итерацию сборки, так как текущее отставание делает все новые объекты PBI привязаны только к этой итерации. Любые объекты, не завершенные в этой итерации, исчезнут после установки текущей сборки на следующий номер итерации. С другой стороны, если я устанавливаю его на родительский корневой узел, я мог бы видеть, что список PBI становится довольно большим с течением времени. Каков наилучший метод управления PBI, который не назначен и работает в простой структуре Parent-> build1/build2 и т. Д.?

2) Особенности. Поэтому я создаю функцию, возможно, она охватывает множество рабочих элементов и несколько задач. Они со временем завершатся, но я заметил, что нет полных или автоматических обновлений для родительских элементов. Итак, кто/когда является элементом Feature, который должен быть отмечен как завершенный? Если владелец продукта должен использовать список функций, чтобы получить обзор работы, они не знают, были ли все зависимые элементы завершены и когда отмечена функция Done.

3) Рабочие элементы. Управление ими, и в частности их «состояние» или статус, похоже на королевскую боль. На панели задач вы не можете изменить свое состояние, только их задачи с перетаскиванием, что приятно. Но вы выполняете все задачи, а родительский элемент работы остается в статусе «Новый». Вам действительно нужно управлять каждым рабочим элементом, открывать его и настраивать состояние «Готово»?

4) QA/testing - для каждого рабочего элемента каждый член команды отвечает за тестирование каждого элемента, поэтому каждый элемент проверяется несколькими людьми и регистрирует все обнаруженные проблемы. Каким образом можно использовать рабочие элементы или задачи для этого?

5) Build Complete - После того, как каждый рабочий элемент на итерации отмечен Готово, я предполагаю, что они удалены из памяти продукта правильно? Исключением для этого являются функции, к которым они привязаны, сам элемент функции остается открытым. Как заинтересованные стороны просматривают список функций, которые были завершены в текущей сборке?

Answer 1

1) Журнал продуктов - в разделе «Конфигурация графика и итераций» Какова концепция установки текущей «итерации журнала»? Наша команда использует короткие 2-недельные итерации с номером сборки, но устанавливает итерацию построения , так как текущее отставание делает все новые области PBI областью до только этой итерацией. Любые объекты, не завершенные в этой итерации, будут исчезнуть, как только я установлю текущую сборку на следующий номер итерации. С другой стороны, если я устанавливаю его на родительский корневой узел, я мог бы видеть , что список PBI становится довольно большим с течением времени. Каков наилучший метод для управления PBI, которые не назначены и работают в простой структуре Parent-> build1/build2 и т. Д.?

TFS имеет два разных отставания. Задержка в работе вашей команды и отставание от Sprint вашей команды.На экране конфигурации итерации вы определяете, какая итерация содержит отставание продуктов вашей группы (путем установки итерации Backlog) и какие итерации ниже этого будут представлять ваши спринты.

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

2) Особенности. Поэтому я создаю функцию, возможно, она охватывает множество рабочих элементов и несколько задач. Они со временем завершатся, но я заметил , что нет полных или автоматических обновлений для родительских элементов. Итак, , кто/когда является элементом Feature, который должен быть отмечен как завершенный? Если владелец продукта должен использовать список функций, чтобы получить обзор работы, они не имеют понятия, были ли все зависимые элементы завершены и когда отметить функцию Done.

Не существует автозавершения или авто-закрытия. Обычно владелец продукта (роль схватки) будет следить за тем, что он запросил, и знает, когда будет завершена функция.

Вы также можете просмотреть иерархию элементов отставания продукта к функциям в представлении Backlog товаров, выбрав представление «Особенности для отставания». Это будет также список состояний основных историй:

3) Работа Предметы - Управление этим, и, в частности, их «состояние» или статус кажется королевской боли. На панели задач вы не можете изменить свое состояние, только их задачи с перетаскиванием, что приятно. Но вы выполнили все задания, а родительский элемент управления остается в статусе «Новый». Вам действительно нужно микроуправлять каждый рабочий элемент, открыть его, и установить состояние «Готово»?

Обычно владелец продукта/руководитель проекта утверждают истории для пикапа и переносят их с нового на утвержденный. Затем во время совещания по планированию Sprint (или в начале спринта) команда выбирает, с какими элементами они будут работать, и переместит их с Approved to Committed.

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

4) QA/тестирование - Для каждого рабочего элемента, каждый член команды отвечает для тестирования каждого элемента, так что каждый элемент проверяется несколькими людьми, и регистрации каких-либо проблем, найденных. Каков наилучший способ использования рабочих элементов или задач для этого?

Зависит от зрелости команды. И зависит от вашего принятия менеджера тестирования (тестовый пример). Если ваша команда довольно зрелая и использует диспетчер тестов для связывания тестовых случаев с вашими историями, вы можете просмотреть статус своих тестов в веб-доступе. Если команда последовательно работает в режиме ATDD, они будут выполнять работу, необходимую для успешного тестирования, прежде чем перейти к следующей части работы. В таком рабочем процессе на самом деле не нужно создавать рабочие элементы «design-build-test».Рабочий элемент, вероятно, будет похож на «Сделать тест X pass» и будет включать в себя всю работу по созданию теста, сборку кода и прохождение теста.

5) Сборка Complete - После того, как каждый элемент работы в итерации отмечен Done, то я предполагаю, что они будут удалены из накопившихся продуктов правильного? Исключением из этого являются функции, к которым они были привязаны, элемент функции сам по себе остается открытым. Как заинтересованные стороны просматривают список функций , которые были завершены в текущей сборке?

Опять же, используйте элемент «Item to Product Backlog Item», чтобы увидеть, какие функции были закончены. Заинтересованные стороны мысленно проверяют, что это действительно все, что они хотели, и что у них нет дополнительных запросов, работы, обратной связи, необходимой для действительно полного выполнения этой функции. Если это так, они закрывают эту функцию, перемещая ее.

Answer 2

Я не могу ответить на все (на самом деле, не существует один «правильный» ответ), но вот как моя команда использует TFS - это может дать вам некоторые идеи:

Мы используем Path Area, чтобы представить проект или Epic, что работа принадлежит. Когда рабочий элемент создается, он назначается проекту с использованием пути к области, и он никогда не изменяется.

Затем для представления работы «когда» мы используем иерархический путь итерации под тремя заголовками (для проекта под названием «Проект»): Project \ Completed, Project \ Current, Project \ Future.

Истории в товарном портфеле изначально присваиваются Будущему (мы идем немного дальше и используем новые истории для представления «предлагаемой» работы, а активные - для представления «утвержденного» отставания - это позволяет нам планировать предварительные проекты/контракты, которые преобразуются в реальную работу, когда они получают зеленый свет). На этом этапе мы планируем покер, чтобы получить очки истории, а затем руководители проектов назначают ряды стека для рассказов, чтобы помочь решить, что нужно переместить из списка «Предложенный продукт», а затем, в конце концов, о чем мы должны думать для следующей итерации.

Когда мы начинаем итерацию, мы создаем новую итерацию (назовите ее 001) под Future, т. Е. Project \ Future \ 001. Затем Stories выбираются из Backlog для реализации - они назначаются для этой итерации. Когда итерация готова к запуску, мы используем подход «конвейерной ленты», который перемещает все итерации вдоль одного «места» в иерархии: в интерфейсе конфигурации Iteration Path просто перетащите итерацию 001 из будущего в текущий. Это автоматически перебирает все в этом пути, так что вся активная работа выполняется мгновенно в Project \ Current.

По завершении итерации у нас будет Current \ 001, и мы добавим Future \ 002. Затем мы перемещаем 001 и 002 вдоль конвейера (в Project \ Completed \ 001 и Project \ Current \ 002 соответственно). Таким образом, работа присваивается одной итерации и остается там, но итерация в целом переходит от будущего ... к текущему ... к завершенному. Это позволяет нам создавать запросы, такие как «вся текущая работа» (все работают под «Project \ Current»), которые нам не нужно переписывать для каждой итерации, и это экономит огромное количество времени и устраняет множество ошибок, пытающихся повторно назначать пути итерации постоянно - в большинстве случаев итерация изменяется только один раз (от будущего до фактической итерации).

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

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

Мы закрываем задачи/ошибки/проблемы по мере их заполнения, но история остается открытой до конца итерации (так что любые новые обнаруженные ошибки могут быть прикреплены и обработаны). Затем мы используем настраиваемый инструмент «Разрешить» историю, которая закрывает все дочерние рабочие элементы, а затем проверяет, завершена ли родительская функция или Epic, а также может быть отмечена «Разрешена». Это также можно сделать на складе TFS только с помощью ручного процесса, но это довольно трудоемко, и код для автоматизации всего лишь час или два. Я действительно не понимаю, почему TFS заставляет вас существенно обновлять все таблицы базы данных вручную, когда их легко автоматизировать. (Подобным образом, KANB TFS не требует много времени для управления, потому что элементы появляются на нем только в том случае, если они полностью сформированы - получить какую-либо из оценочной, оставшейся, завершенной, области, итерации, назначенной, родительской ссылки и т. Д. Неправильно и он исчезает! Поэтому я написал, например, простой инструмент «создать задачу», который запрашивает оценку, правопреемника и титул, и заполняет остальные - мне потребовалось пару часов для реализации и искоренить все трудоемкие ошибки и трудность использования TFS 'raw')

При обработке задач TFS предоставляет состояния «Activity» (планирование, разработка, тестирование, документация и т. д.), что подразумевает, что каждая отдельная задача будет передаваться линейно через цепочку разных людей который будет реализован ... но мы считаем, что это плохой подход, потому что мы хотим, чтобы команда, работающая над историей, работала параллельно и работала вместе, а не «бросала свой бит» над забором к следующему парню ». Таким образом, вместо этого каждый человек в команде создает одну или несколько задач под сюжет, которые представляют собой участки работы (программирование, тестирование, документирование), которые они должны лично сделать, чтобы донести историю, и каждая задача только имеет одного владельца. (Это хорошо работает на нашей панели управления, поскольку она показывает историю и список дочерних задач/ошибок/проблем, так что весь контекст работы истории можно легко увидеть с первого взгляда). Отдельные задачи позволяют программисту и тестировщику работать вместе в тесной, итеративной, кооперативной гибкой петле, часто с прогрессивным развертыванием частей функции для тестирования, а не программистом, заканчивающим всю свою работу, прежде чем передать полную статью до тестера по водопаду. В конце итерации рассказ-команда демонстрирует свою историю более широкой команде разработчиков, и все они одинаково ответственны за обеспечение того, чтобы все необходимое было доставлено. После демонстрации владелец продукта/Чемпион принимает эту работу как выполненную (или отклоняет ее). Это значительно уменьшает количество работ, которые теряются «между трещинами», когда люди думают, что кто-то еще это сделает, помогая нам получить твердую доставку в конце. Мы обнаружили, что общение в команде и доставка сюжета значительно улучшились, так как мы перешли к этому подходу.

Следует отметить, что для получения хороших оценок и выгорания мы стараемся, чтобы каждая задача работала менее 5 дней, и чтобы избежать микроуправления, мы стараемся избегать разделения задач на что-либо менее чем за 2 дня (хотя, очевидно, некоторые задачи обязательно короче).

Как я уже упоминал, мы регистрируем ошибки/проблемы как дети задачи или истории, которые они затрагивают (а также могут добавлять связанные ссылки, если они влияют на более чем одну историю). В конце итерации, а также демонстрации новых функций остальной части команды, сборка релизов проходит регрессионную проверку в целом. Любые обнаруженные ошибки фиксируются в ветви релиза и, как мы надеемся, через день или два у нас стабильная версия клиента. Мы стремимся к тому, чтобы с каждой итерации производилось качество выпускаемых пользователями продуктов, а также количество выдающихся ошибок для разработчиков ниже 5 (обычно 1-3). Перед внедрением этой системы у нас было в среднем 20 ошибок на одного разработчика, что было неприятным техническим долгом.(Примечание: мы сохраняем некоторое время на каждой итерации для исправления этих ошибок, но когда ошибки слишком грубые, чтобы исправить тогда-и-там, мы обычно конвертируем их в новые истории, чтобы их можно было оценить и запланировать для будущей итерации, как другая работа, поэтому список ошибок и технический долг никогда не разрешается наращивать, и там, где это возможно, исправление ошибок не позволяет сорвать наш план итераций.

Мы не рассматриваем незавершенное производство (элементы на итерации) как отставание продукта - отставание продукта - это работа, которую мы планируем сделать в будущем, и когда она переходит в итерацию, она активно работает и больше не входит в список «делать» (это отставание Iteration, а не отставание продукта). Когда вся работа (задача/ошибка) будет завершена, родительский рассказ может быть разрешен («мы думаем, что это сделано»), а затем «Закрыто» («владелец продукта принимает его как« сделано ») и поэтому простой запрос (w ork в Project \ Current, который закрыт) сообщит вам, что вы поставили эту итерацию.

Наконец, когда мы завершаем итерацию, вся итерация переходит в Project \ Completed, поэтому вы можете легко запросить всю работу, которая когда-либо была завершена (в разделе Project \ Completed) и по-прежнему сгруппированы в пределах их отдельных итераций , Поэтому в любое время, если вы хотите знать, что добавляет «Build 107», вы можете просто выполнить запрос для всех закрытых историй по пути итерации Project \ Completed \ 107. Мы отмечаем неполную/оставленную работу как «Удалено», поэтому для нас «Закрытые» означает «Готово». Если работа не завершена на одной итерации и продолжена в следующем, мы просто переносим историю на следующую итерацию, и поэтому завершенная работа затем появляется в любых запросах для «Build 108», поэтому это прекрасно отслеживает достигнутые поставки для итерации.

Чтобы все было в порядке, только несколько членов команды могут изменять различные типы предметов. Поэтому наши «пункты планирования» (Epics, Features, Stories) изменяются только Менеджером проекта или владельцами продуктов. Задачи все принадлежат и, таким образом, созданы/изменены/закрыты разработчиком, который выполняет эту работу. PMs отслеживают ход рассказов и развивает отслеживание хода Задачи.