Настройка workflow задач в TFS

2012-07-09 в 5:18, admin, рубрики: agile, TFS2010, управление проектами, метки: agile, TFS2010, управление проектами

Я хочу рассказать о том, как можно расширить стандартный процесс (workflow) для некоторых элементов в TFS 2010 (про 2011 будет позже) при выборе шаблона Agile для проекта. Так же интересно услышать мнение хабрасообщества по поводу донастройки шаблонов, кто как настраивает workfolw, очень интересно.

Стандартные настройки проекта 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

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

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