Я хочу рассказать о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS 2010 (про 2011 будет позже) при выборе шаблона Agile для проекта. Так же интересно услышать мнение хабрасообщества по поводу донастройки шаблонов, кто как настраивает workfolw. Расскажите, как это делаете вы, очень интересно.
Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.
Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды. В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.
Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.
Начнем с рассмотрения того, как было.
В первоначальном виде диаграмма состояний пользовательских историй выглядят весьма бедно и убого.
Большая версия картинки здесь
По сути, пользовательская история может быть только в трех состояниях, что, на мой взгляд, явно недостаточно, так как самих «натуральных» процессов с пользовательской историей (далее просто «история») гораздо больше.
Предлагаю сначала обратить чуть больше внимания на обозначения. Красным обозначены состояния, в которых может находиться история. Указание полей внутри блока говорит о том, что они участвуют в некоторых правилах, которые должны быть выполнены при переходе в это состояние. Минусом помечаются поля, которые будут очищены, звездочка модификатор того, что это опционально.
Синим цветом обозначены переходы между состояниями. Каждый такой блок обязательно должен содержать причину перехода, без этого невозможно будет сохранить настроенную схему. Раздел Actions содержит указание на некоторый триггер, по срабатыванию которого следует применить переход. В Fields указывается, какие поля будут заполнены автоматически, либо какие поля надо будет заполнить в обязательном порядке. Звездочкой обозначается поле, которое будет заполнено автоматически системой. Плюсом обозначается необходимое к заполнению поле.
Диаграмма обязательно должна содержать единственный переход без начального состояния.
Вернемся к нашей истории. В базовой версии она содержит только три состояния:
Я думаю, этого недостаточно, вот по каким причинам:
Можно придумать еще причины, но это будет наверно уже вытекать из ваших особенностей работы над пользовательской историей.
Какой мне видится «правильная» организация системы состояний User story? Сейчас расскажу.
Тюнингованный вариант, конечно выглядит более большим и рассматривать все условия переходов на диаграмме не стоит. Главное описать суть перехода, а уж причины можно будет описать самостоятельно.
Большая версия картинки здесь.
Теперь стандартный процесс работы над историей выглядит следующим образом:
На мой взгляд, состояние истории можно определить с большей точностью, так как предыдущее состояние Active могло определять слишком много активностей, что приводило бы к опросу слишком многих людей, чтобы узнать реальное положение дел. Итак, рассмотрим назначение состояний.
Все начинается с идеи или пожелания бизнес-аналитиков, либо разработчиков. Т.е. есть некоторая идея, которую можно кратко выразить, и которая должна нести пользу для бизнеса. Это состояние New.
Нет еще никаких тестов, еще не понятно как это впишется в проект, непонятны трудозатраты – есть только голая идея. Это повод для разговора. Только после того как первоначальная идея была зафиксирована можно переходить к другим фазам работы.
На данном этапе вопросы могут быть к инициаторам задачи, чтобы получить ответ о важности выдвинутой идеи.
В этой фазе начинается более детальный сбор требований о задаче, проверяется непротиворечивость требований. Анализируется что потребуется сделать для выполнения задания, как оно ляжет на архитектуру приложения. Идет сбор и анализ данных, которые потребуется собрать и использовать. Определяются потоки данных. Дается примерная оценка сложности и времени на выполнение задачи. Должны существовать некоторые приемочные тесты.
После того как указанные данные собраны и проверены, написан документ для задачи, идет переход к следующей фазе.
Ответственными на этом этапе являются аналитики и частично разработчики, или же тех.лид.
Я немного слукавил, в предыдущем пункте. К началу данной фазы должны быть уже определены задачи для разработчиков. Эти задачи пишут сами разработчики, определяют их размер и состав самостоятельно. Данная же метка состояния задачи говорит о том, что все предварительные работы проведены и можно брать историю в разработку. При этом можно быть уверенным, что проблем в результате разработки не возникнет с большой долей вероятности.
Во время формирования конкретных задач могут всплыть разные неясности и задача отправляется на дополнительный анализ. Данный процесс может повторятся несколько раз. Чем больше раз он повторится, тем менее профпригодны бизнес-аналитики на мой взгляд. Хотя некоторые задачи могут иметь технические ограничения и тогда, это нормально, если идет возврат к анализу истории.
На этом этапе спрос идет с прожект менеджера, когда данная история будет включена в спринт.
История в процессе активной разработки. Все задачи ясны, описаны и активно выполняются членами команды.
Если возникли непредвиденные проблемы, которые разработчики не могут разрешить самостоятельно в течение короткого времени, то задача переходит в состояние Hold до разрешения проблем.
Спрос в данном состоянии истории идет с разработчиков целиком и полностью.
После того, как разработчики сделали функционал и приемочные тесты проходят, история переходит в состояние Resolved, что означает готовность к приемочному тестированию и оценке того, правильно ли все было понято и сделано. После этой фазы история может быть отправлена на публикацию или же на доработку в состояние WIP с описанием недостающего функционала или же с описанием найденных ошибок.
Ответственность за состояние истории и спрос с бизнес-аналитиков и тестировщиков, если такие есть.
Данное состояние было введено, для того, чтобы было легче ориентироваться, что уже ушло на какие-либо версии для приема реальными пользователями и для будущей потенциальной автоматизации составления change log приложения.
Является фактически индикатором. Суть та же что и у Resolved.
Данное состояние истории означает что история принята, все приемочные тесты прошли, претензий ни у кого нет.
Конечно, история из этого состояния может быть переведена в состояние WIP, если тестировщики или аналитики оказались нерасторопными или достаточно настырными чтобы в историю протолкнуть дополнительные требования по реализации.
На мой взгляд, такие состояния у пользовательской истории более точно характеризуют процесс работы над ней и можно более четко формализовать и разделить зоны ответственности. При таком подходе легко находятся ответы на вопросы заданные в начале раздела. Можно четко сказать что делается по истории, как минимум сокращается число людей, которых надо будет потыкать палочкой для получения состояния дел.
После того, как разобрались с состояниями пользовательской истории, поговорим о задачах. Базовый вид процесс работы над задачей выглядит следующим образом:
Даже не знаю, что и сказать. По таким состояниям ничего нельзя сказать, кроме того, что история сделана или нет. Этого явно недостаточно на мой взгляд. Опять же возникает миллион вопросов о состоянии задачи, она взята кем-то в работу или нет, есть сложности или нет и так далее.
В такой схеме придется придумывать окольные пути по которым нужно будет определять, задача в работе или же только ждет своего часа. Для этого может быть использовано поле Assignee, но если задача должна быть изначально назначена на определенного человека, то это создает определенные трудности.
Не мучая более вас, можно перейти к тому виду, который я сейчас использую в работе.
Тюнингованный процесс содержит 4 новых состояния задачи, призванных облегчить задачу трекинга и составления запросов для отчетов.
Теперь типичный сценарий работы над задачей будет состоять из 4 шагов:
Если же задача требует уточнений от аналитиков или проблема не может быть быстро решена, то предусмотрено состояние Hold.
Если же задача отменяется, то есть состояние Abandoned. Это позволяет быстро отличить реализованные задачи от снятых по какой-либо причине, вместо того, чтобы заниматься анализированием причин, по которым задача была закрыта.
Все задачи изначально создаются с таким статусом. Буквально дословно: Задача предложена к работе. Еще нет никаких фамилий в поле Assignee, никаких списаний. Видно что задача ждет своего часа и никто ей не занимается. Далее возможны, как уже говорилось, два варианта:
Задача активно разрабатывается, можно интересоваться прогрессом, сроками завершения. Четко видно кто ее делает.
Задача по каким-либо причинам стала не актуальна и данный статус показывает, что указанная задача не была реализована.
Если же задача требует уточнений от аналитиков или проблема не может быть быстро решена, то она попадает в это состояние и находится в нем до разрешения проблемы. Потом задача может перейти только в состояние Active.
Когда разработчик решает, что задача выполнена, он перемещает ее в это состояние. По идее в этом состоянии для задачи должны существовать тесты, и результат должен быть работоспособен.
В это состояние задача попадает после процесса тестирования, либо приемки всей истории. Если тестирование не обнаружило изъянов, то задача считается закрытой.
Опять же насколько проще станет писать запросы к TFS и одним взглядом оценивать состояние задач без дополнительных ковыряний в текстах задачи или же опроса тех.лида или же самих разработчиков.
Не ошибается тот, кто ничего не делает. Так что как ни крутись, а ошибки в процессе работы будут, и требуется точно так же отслеживать работу над ними. Анализировать, делать выводы.
С базовой схемой состояний для багов так же не все так гладко. Опять большинство вопросов утыкается в начальные фазы работы над багом. Нельзя сказать однозначно, ведется ли работа по подтверждению бага, или же он уже в процессе исправления. Или он вообще только что пришел и еще никто на него не смотрел.
Для того, чтобы можно было получить ответы на эти вопросы с первого взгляда, я создал схему, которую вы можете увидеть далее.
Большой размер картинки здесь
Основные изменения коснулись начала процесса. Теперь основной сценарий выглядит следующим образом:
Рассмотрим подробнее эти состояния.
С данного состояния начинается любая запись о подозрительном поведении программы. Это как индикатор того, что кто-то считает описанное поведение неверным. Однако это еще не значит что баг имеет место быть, может быть это фича или же неудачное положение планет при котором наводятся импульсы на процессор или еще что-нибудь.
При этом обязательно должно быть описано правильное поведение функционала с точки зрения того, кто заводит баг.
После того как запись о баге была сделана, необходимо как минимум проанализировать поведение программы и удостоверится что баг действительно воспроизводится на машинах разработчиков или тестировщиков. А так же проводится первичный анализ того, из-за чего происходит такое поведение, чтобы можно было оценить объем и сроки работ по корректировке нежелательного поведения. По результатам этих работ создаются задачи для бага.
После анализа ошибки, баг либо закрывается либо переводится в статус Active, когда его берут в работу.
Еще одной причиной закрытия бага может быть недопонимание природы бага и фичи, либо сайд-эффекта, когда баг перерастает в самостоятельное бизнес-требование.
Данное состояние указывает на то, что баг находится в процессе починки и разработчики заняты устранением причин и/или последствий бага.
В целом аналогично таким же пунктам из UserStory и Task. Состояние обозначающее, что работы закончены и можно провести повторное приемочное тестирование. Если нежелательное поведение сохраняется, то баг переводится обратно в состояние Active.
Это состояние было введено, для того, чтобы было легче ориентироваться, что уже ушло на какие-либо версии для приема реальными пользователями и для будущей потенциальной автоматизации составления change log приложения.
Является фактически индикатором. Суть та же что и у Resolved.
Приемочные тесты пройдены, баг устранен, все счастливы.
Такие небольшие улучшения позволят более точно контролировать ход работ над багами, по моему мнению.
Я думаю, что на основе такой схемы работы уже будет легче определиться с ответственностью ролей и людей, которые заняты на проекте для более слаженной, прозрачной и продуктивной работы. Чтобы не отвлекать друг друга вопросами, ответы на которые способен дать TFS и минута времени.
Расскажите, как устроен workflow у вас? В целом ведь не важно какая система используется, почти любую современную систему баг-трекинга можно донастроить.
О настройки всего этого счастья как-нибудь в другой раз. Готовые примеры шаблонов можно взять здесь.
Стандартные настройки проекта out-of-box на мой взгляд достаточно бедны и не обеспечивают должной прозрачности, если необходимо отслеживать/контролировать работу над проектом распределенной команды, либо когда управляющий (менеджер или еще какой-нито начальник) желает видеть как идут дела с задачами. Стандартные настройки не позволяют, на мой взгляд, уверенно говорить о текущем состоянии задач.
Обычная рабочая доска (task board) имеет больше состояний, нежели базовые настройки типичных артефактов управления проектом из которых строится процесс Agile: UserStory, Task, Bug. Мне кажется это базовые вещи, которые стоит рассмотреть и дополнительно настроить, что собственно я и сделал для себя и команды. В рассказе ниже я затрону только настройку процесса перехода состояний, не затрагивая свойства элементов. Т.е. никаких кастомизаций внешнего вида и свойств не будет.
Прежде чем двигаться дальше, расскажу, какие инструменты вам понадобятся. Все описанные манипуляции производятся над TFS2010 с установленным пакетом TFS Power Tools. Предполагаю так же, что вам понадобятся права администратора TFS.
Начнем с рассмотрения того, как было.
User Story
Настройки out-of-box
В первоначальном виде диаграмма состояний пользовательских историй выглядят весьма бедно и убого.
Большая версия картинки здесь
По сути, пользовательская история может быть только в трех состояниях, что, на мой взгляд, явно недостаточно, так как самих «натуральных» процессов с пользовательской историей (далее просто «история») гораздо больше.
Предлагаю сначала обратить чуть больше внимания на обозначения. Красным обозначены состояния, в которых может находиться история. Указание полей внутри блока говорит о том, что они участвуют в некоторых правилах, которые должны быть выполнены при переходе в это состояние. Минусом помечаются поля, которые будут очищены, звездочка модификатор того, что это опционально.
Синим цветом обозначены переходы между состояниями. Каждый такой блок обязательно должен содержать причину перехода, без этого невозможно будет сохранить настроенную схему. Раздел Actions содержит указание на некоторый триггер, по срабатыванию которого следует применить переход. В Fields указывается, какие поля будут заполнены автоматически, либо какие поля надо будет заполнить в обязательном порядке. Звездочкой обозначается поле, которое будет заполнено автоматически системой. Плюсом обозначается необходимое к заполнению поле.
Диаграмма обязательно должна содержать единственный переход без начального состояния.
Вернемся к нашей истории. В базовой версии она содержит только три состояния:
- Active,
- Resolved,
- Closed.
Я думаю, этого недостаточно, вот по каким причинам:
- Невозможно отделить новую историю, только что созданную, от той, что находится в работе.
- Невозможно определить тип работы с историей, формализация требований, разработка, тестирование или же что-то еще.
- Невозможно приостановить работу над историей, если обнаружились новые аспекты реализации, которые требуют дополнительных решений.
- Невозможно отменить историю, обозначив ее как потерявшую смысл.
Можно придумать еще причины, но это будет наверно уже вытекать из ваших особенностей работы над пользовательской историей.
Какой мне видится «правильная» организация системы состояний User story? Сейчас расскажу.
Customized
Тюнингованный вариант, конечно выглядит более большим и рассматривать все условия переходов на диаграмме не стоит. Главное описать суть перехода, а уж причины можно будет описать самостоятельно.
Большая версия картинки здесь.
Теперь стандартный процесс работы над историей выглядит следующим образом:
- New
- Analysis
- Ready For Development
- Work In Progress (WIP)
- Resolved
- Published
- Closed
- + Hold
На мой взгляд, состояние истории можно определить с большей точностью, так как предыдущее состояние Active могло определять слишком много активностей, что приводило бы к опросу слишком многих людей, чтобы узнать реальное положение дел. Итак, рассмотрим назначение состояний.
New
Все начинается с идеи или пожелания бизнес-аналитиков, либо разработчиков. Т.е. есть некоторая идея, которую можно кратко выразить, и которая должна нести пользу для бизнеса. Это состояние New.
Нет еще никаких тестов, еще не понятно как это впишется в проект, непонятны трудозатраты – есть только голая идея. Это повод для разговора. Только после того как первоначальная идея была зафиксирована можно переходить к другим фазам работы.
На данном этапе вопросы могут быть к инициаторам задачи, чтобы получить ответ о важности выдвинутой идеи.
Analysis
В этой фазе начинается более детальный сбор требований о задаче, проверяется непротиворечивость требований. Анализируется что потребуется сделать для выполнения задания, как оно ляжет на архитектуру приложения. Идет сбор и анализ данных, которые потребуется собрать и использовать. Определяются потоки данных. Дается примерная оценка сложности и времени на выполнение задачи. Должны существовать некоторые приемочные тесты.
После того как указанные данные собраны и проверены, написан документ для задачи, идет переход к следующей фазе.
Ответственными на этом этапе являются аналитики и частично разработчики, или же тех.лид.
Ready For Development
Я немного слукавил, в предыдущем пункте. К началу данной фазы должны быть уже определены задачи для разработчиков. Эти задачи пишут сами разработчики, определяют их размер и состав самостоятельно. Данная же метка состояния задачи говорит о том, что все предварительные работы проведены и можно брать историю в разработку. При этом можно быть уверенным, что проблем в результате разработки не возникнет с большой долей вероятности.
Во время формирования конкретных задач могут всплыть разные неясности и задача отправляется на дополнительный анализ. Данный процесс может повторятся несколько раз. Чем больше раз он повторится, тем менее профпригодны бизнес-аналитики на мой взгляд. Хотя некоторые задачи могут иметь технические ограничения и тогда, это нормально, если идет возврат к анализу истории.
На этом этапе спрос идет с прожект менеджера, когда данная история будет включена в спринт.
WIP
История в процессе активной разработки. Все задачи ясны, описаны и активно выполняются членами команды.
Если возникли непредвиденные проблемы, которые разработчики не могут разрешить самостоятельно в течение короткого времени, то задача переходит в состояние Hold до разрешения проблем.
Спрос в данном состоянии истории идет с разработчиков целиком и полностью.
Resolved
После того, как разработчики сделали функционал и приемочные тесты проходят, история переходит в состояние Resolved, что означает готовность к приемочному тестированию и оценке того, правильно ли все было понято и сделано. После этой фазы история может быть отправлена на публикацию или же на доработку в состояние WIP с описанием недостающего функционала или же с описанием найденных ошибок.
Ответственность за состояние истории и спрос с бизнес-аналитиков и тестировщиков, если такие есть.
Published
Данное состояние было введено, для того, чтобы было легче ориентироваться, что уже ушло на какие-либо версии для приема реальными пользователями и для будущей потенциальной автоматизации составления change log приложения.
Является фактически индикатором. Суть та же что и у Resolved.
Closed
Данное состояние истории означает что история принята, все приемочные тесты прошли, претензий ни у кого нет.
Конечно, история из этого состояния может быть переведена в состояние WIP, если тестировщики или аналитики оказались нерасторопными или достаточно настырными чтобы в историю протолкнуть дополнительные требования по реализации.
На мой взгляд, такие состояния у пользовательской истории более точно характеризуют процесс работы над ней и можно более четко формализовать и разделить зоны ответственности. При таком подходе легко находятся ответы на вопросы заданные в начале раздела. Можно четко сказать что делается по истории, как минимум сокращается число людей, которых надо будет потыкать палочкой для получения состояния дел.
Task
Настройки out-of-box
После того, как разобрались с состояниями пользовательской истории, поговорим о задачах. Базовый вид процесс работы над задачей выглядит следующим образом:
Даже не знаю, что и сказать. По таким состояниям ничего нельзя сказать, кроме того, что история сделана или нет. Этого явно недостаточно на мой взгляд. Опять же возникает миллион вопросов о состоянии задачи, она взята кем-то в работу или нет, есть сложности или нет и так далее.
В такой схеме придется придумывать окольные пути по которым нужно будет определять, задача в работе или же только ждет своего часа. Для этого может быть использовано поле Assignee, но если задача должна быть изначально назначена на определенного человека, то это создает определенные трудности.
Не мучая более вас, можно перейти к тому виду, который я сейчас использую в работе.
Customized
Тюнингованный процесс содержит 4 новых состояния задачи, призванных облегчить задачу трекинга и составления запросов для отчетов.
Теперь типичный сценарий работы над задачей будет состоять из 4 шагов:
- Proposed
- Active
- Resolved
- Closed
Если же задача требует уточнений от аналитиков или проблема не может быть быстро решена, то предусмотрено состояние Hold.
Если же задача отменяется, то есть состояние Abandoned. Это позволяет быстро отличить реализованные задачи от снятых по какой-либо причине, вместо того, чтобы заниматься анализированием причин, по которым задача была закрыта.
Proposed
Все задачи изначально создаются с таким статусом. Буквально дословно: Задача предложена к работе. Еще нет никаких фамилий в поле Assignee, никаких списаний. Видно что задача ждет своего часа и никто ей не занимается. Далее возможны, как уже говорилось, два варианта:
Active
Задача активно разрабатывается, можно интересоваться прогрессом, сроками завершения. Четко видно кто ее делает.
Abandoned
Задача по каким-либо причинам стала не актуальна и данный статус показывает, что указанная задача не была реализована.
Hold
Если же задача требует уточнений от аналитиков или проблема не может быть быстро решена, то она попадает в это состояние и находится в нем до разрешения проблемы. Потом задача может перейти только в состояние Active.
Resolved
Когда разработчик решает, что задача выполнена, он перемещает ее в это состояние. По идее в этом состоянии для задачи должны существовать тесты, и результат должен быть работоспособен.
Closed
В это состояние задача попадает после процесса тестирования, либо приемки всей истории. Если тестирование не обнаружило изъянов, то задача считается закрытой.
Опять же насколько проще станет писать запросы к TFS и одним взглядом оценивать состояние задач без дополнительных ковыряний в текстах задачи или же опроса тех.лида или же самих разработчиков.
Bug
Настройки out-of-box
Не ошибается тот, кто ничего не делает. Так что как ни крутись, а ошибки в процессе работы будут, и требуется точно так же отслеживать работу над ними. Анализировать, делать выводы.
С базовой схемой состояний для багов так же не все так гладко. Опять большинство вопросов утыкается в начальные фазы работы над багом. Нельзя сказать однозначно, ведется ли работа по подтверждению бага, или же он уже в процессе исправления. Или он вообще только что пришел и еще никто на него не смотрел.
Для того, чтобы можно было получить ответы на эти вопросы с первого взгляда, я создал схему, которую вы можете увидеть далее.
Customized
Большой размер картинки здесь
Основные изменения коснулись начала процесса. Теперь основной сценарий выглядит следующим образом:
- Proposed
- Analysis
- Active
- Resolved
- Published
- Closed
Рассмотрим подробнее эти состояния.
Proposed
С данного состояния начинается любая запись о подозрительном поведении программы. Это как индикатор того, что кто-то считает описанное поведение неверным. Однако это еще не значит что баг имеет место быть, может быть это фича или же неудачное положение планет при котором наводятся импульсы на процессор или еще что-нибудь.
При этом обязательно должно быть описано правильное поведение функционала с точки зрения того, кто заводит баг.
Analysis
После того как запись о баге была сделана, необходимо как минимум проанализировать поведение программы и удостоверится что баг действительно воспроизводится на машинах разработчиков или тестировщиков. А так же проводится первичный анализ того, из-за чего происходит такое поведение, чтобы можно было оценить объем и сроки работ по корректировке нежелательного поведения. По результатам этих работ создаются задачи для бага.
После анализа ошибки, баг либо закрывается либо переводится в статус Active, когда его берут в работу.
Еще одной причиной закрытия бага может быть недопонимание природы бага и фичи, либо сайд-эффекта, когда баг перерастает в самостоятельное бизнес-требование.
Active
Данное состояние указывает на то, что баг находится в процессе починки и разработчики заняты устранением причин и/или последствий бага.
Resolved
В целом аналогично таким же пунктам из UserStory и Task. Состояние обозначающее, что работы закончены и можно провести повторное приемочное тестирование. Если нежелательное поведение сохраняется, то баг переводится обратно в состояние Active.
Published
Это состояние было введено, для того, чтобы было легче ориентироваться, что уже ушло на какие-либо версии для приема реальными пользователями и для будущей потенциальной автоматизации составления change log приложения.
Является фактически индикатором. Суть та же что и у Resolved.
Closed
Приемочные тесты пройдены, баг устранен, все счастливы.
Такие небольшие улучшения позволят более точно контролировать ход работ над багами, по моему мнению.
Итого
Я думаю, что на основе такой схемы работы уже будет легче определиться с ответственностью ролей и людей, которые заняты на проекте для более слаженной, прозрачной и продуктивной работы. Чтобы не отвлекать друг друга вопросами, ответы на которые способен дать TFS и минута времени.
Расскажите, как устроен workflow у вас? В целом ведь не важно какая система используется, почти любую современную систему баг-трекинга можно донастроить.
О настройки всего этого счастья как-нибудь в другой раз. Готовые примеры шаблонов можно взять здесь.
