понедельник, 27 сентября 2010 г. - www.msmirnov.ru

Нумерация версий продукта в TFS (Team Foundation Server)

В продолжении темы миграции в TFS (Team Foundation Server), начатой здесь и здесь, я произвел еще несколько изменений в процессе работы с ним, направленных на повышение удобства работы.

1. Я отказался от использования свойства Iteration Path, которое содержало номер текущей итерации проекта.

Дело в том, что наша деятельность не проектная, а продуктовая, поэтому для нас намного важнее номер текущей версии продукта, на которой мы работаем, чем номер итерации работы над ним. Кроме того, при переходе к работе над очередной версией мы не создаем новый Team Project - мы продолжаем работать в старом, просто новым задачам и багам присваиваем номера новой версии.

Свойство Iteration Path в принципе выполняло отлично свою функцию (тем более что оно было связано в деревом папок в Team Queries), если бы не одно обстоятельство - для него нельзя было устанавливать значения по умолчанию, запрещенные значения и т.п.
Это приводило к тому, что члены команды, которое мало работают с TFS, путались, забывали выставлять это значение, оставляли в качестве значения корневой элемент дерева и т.п. В будущем это стало бы создавать еще большую путаницу, так как с временем количество версий будет увеличиваться и сотрудникам пришлось бы постоянно работать с длинным списком версий, что неудобно.

Так что я убрал свойство Iteration Path с форм ввода ошибок и задач и заменил его на новое поле Version, которому уже задал список значений, соответствующих списку доступных номеров версий продукта. Для поля я Version задал значение по умолчанию, соответствующий текущему номеру версии, так что никто теперь по идее не будет путаться, какую версию выставить. А для задач и багов, запланированных на следующую версию можно всегда вручную установить следующее значение.

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

Хотя конечно если что-то будет неудобно, то будем менять.

2. Я уменьшил количество запросов в Team Queries.
Ранее я писал, что у меня были такие запросы, как My current tasks, My current bugs, All tasks, All bugs и т.д.

Сейчас я оставил в каждой версии продукта только по два запроса: My current work и Tasks and bugs.
- My current work отображает для каждого сотрудника список его активных задач и ошибок, относящихся к выбранной версии.
- Tasks and bugs содержит все задачи и ошибки данной версии.

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

Кроме того, безотносительно версий, я оставил следующие запросы:
- All my work - отображает всю историю задач и ошибок для данного сотрудника.
- All work items - отображает все work items.
- List fixes - отображает список багов и задач, выполненных за последние два дня. Очень удобно для отслеживания прогресса работы.
- My current work - отображает все активные задачи и баги, назначенные на данного сотрудника.

Таким образом, дерево запросов сейчас имеет следующий вид:


Название папок в дереве как и раньше соответствуют версиям продукта.

Продолжение темы - здесь.

P.S.
Другие мои посты на тему TFS:
1. Миграция в TFS (Team Foundation Server)
2. Кто ошибку создает - тот ее и проверяет?
3. Нумерация версий продукта в TFS (Team Foundation Server)
4. Учет трудозатрат и отчетность в TFS (Team Foundation Server)
5. Как создать work item в TFS (Team Foundation Server) из письма в Outlook
6. Как поместить свой control на форму Work Item в TFS (Team Foundation Server)
7. Как настроить номер итерации по умолчанию в TFS (Team Foundation Server)
Мой сайт - www.msmirnov.ru

6 комментариев:

  1. Мы в нашем проекте используем ScrumForTFS шаблон, там IterationPath напрямую мапится в Planning Scope, что логично.

    Выглядит это так: http://storage.raga.name/temp/planningScope.png

    А объясняется так:

    - Разные фичи продукта могут (да и будут) иметь разные итерации, без этого жить в непримитивных проектах сложно, поэтому любое значение по умолчанию вообще не имеет смысла.

    - Если не задавать Planning Scope, то по умолчанию в Scope стоит "весь продукт", что логично, ибо это означает, что workitem пока не запланирован к работе ни в одной из итераций.

    - Люди, которые создают workitems, бывают двух категорий.
    Первых назовём "продакт менеджерами", и это уже их непосредственная работа - помещать workitem в нужный Planning Scope. В общем-то, понятно почему.
    Вторые - все остальные, и это не то, чтобы не их работа, но и они _не имеют права_ вот просто так взять и поместить workitem в понравившийся Scope. Всё, что они могут сделать - это добавить workitem (PBI или Bug), и он именно должен "упасть" в корневой Scope. Потому, что потом его должен оценить Product Manager (либо лицо ответственное за это), выставить приоритеты, определить, когда это должно быть сделано и в каком порядке.

    - Когда люди создают себе Task (SBI), то они делают его на основе уже имеющегося PBI (обычно это делают программисты в процессе работы: "а, вот тут ещё такую штуку надо сделать!"), что логично и что должно быть, в общем-то, обязательным: странно видеть SBI не являющийся частью PBI.
    Так вот, они просто идут в PBI и жмут там кнопарь "New Linked Workitem", создают SBI или баг. Потому, что кому охота все поля самостоятельно заполнять :) И потому, что таким образом они говорят "В такой-то фиче новая таска или новый баг", тут должно быть всё понятно.
    А после нажатия этого кнопаря все "общие" поля типа Planning Scope, Feature Scope и т.д. просто копируются в новый созданный workitem из "родительского", остаётся только добавить описание задачи.
    Повторюсь, PBI уже по определению находится в нужном Scope, так как заведён он был хрен знает когда и Product Manager, прямо выполняя свою работу, поместил этот PBI для реализации вот данный вот Scope. Ну, тут тоже должно быть всё понятно: "такую-то фичу делаем тогда-то" :)

    Вот так нам не приходится решать сферических задач в вакууме.

    ОтветитьУдалить
  2. Ну тут, как говорится, каждому проекту свой процесс.

    Конечно каждая фича имеет свои фазы (именно фазы в терминилогии RUP), но конкретно для нас это имеет мало значения, потому что все равно все фичи выпускаются в рамках одной версии.

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

    ОтветитьУдалить
  3. В блог писать можно и нужно - там просто после проверки появляется, а не сразу.

    В прочем как и тебя.

    ОтветитьУдалить
  4. Ааа, значит я не заметил сообщения о проверке.

    Просто после первого нажатия "отправить" у меня вылетела ошибка блогпоста, он на что-то пожаловался.. Попробовал ещё раз - и увидел снова текстбокс для текста...

    Видимо не заметил :)

    ОтветитьУдалить
  5. @Michael Smirnov а фазы (именно фазы) тут вообще ни при чём. Можно сказать так: RUPовские фазы внутри каждой итерации ещё набором сидят. Просто в agile всё проще и ближе к земле :)

    Спринт - это не фаза, по определению.

    Поэтому а) не надо думать вообще какую фазу выставить, б) и технически об этом думать не надо - нажал кнопарь - оно само привязалось :)

    ОтветитьУдалить