В моем рабочем процессе схватки, когда развитие истории завершено, история переводится в . Решено государство и только после того, как QA завершено, история закрыта.Jira Greenhopper Burndown
Поскольку команда QA работает отдельно с командой разработчиков, когда я отслеживаю прогресс команды разработчиков, я бы хотел, чтобы график выгорания отражал ход команды, поэтому задача должна быть рассмотрена в . Решено. и не только в Закрыто.
Должен сказать, что я согласен с одним из элементов предыдущего ответа: оптимальная настройка в Scrum состоит в том, чтобы иметь только одну команду. К сожалению, в некотором контексте у вас нет этой опции. Так что если это ваш случай, вот мой ответ:
Сначала я не предлагаю создать отдельный проект. С функциями в последних версиях JIRA есть много другого способа сделать это. Один из них - использовать плагин Greenhopper и создать две разные платы в одном проекте: один для Developer и один для QA. У меня был такой же проблемы, вы упоминаете, и вот что мы сделали:
Требования, предъявляемые к этой команде:
установки JIRA:
1) Я создал настраиваемого рабочего процесса для моего проекта, принимая во внимание различные «промежуточный статус» у нас есть между «Решено» и «Закрыто». Вот краткий обзор нашего процесса:
открыт -> InProgress -> Решено -> Staging-> Готов к Prerelease-> Prerelease-> Готовый для производства -> Производство -> Закрытое
2), то Я создал «Развитие» Scrum Совет настроен следующим образом: 
3) наконец, я создал «ОК» Scrum совет по тому же проекту, сконфигурированный следующим образом: 
Теперь у нас есть два вида текущего Sprint, один для разработчиков и один для QA. В этих двух соображениях учитывается тот факт, что определение сделано несколько отличается для каждой команды.
Совет по развитию
QA Совет
Мы эксплуатируем с этой установкой в течение около года, и она по-прежнему отвечает всем требованиям: -)
надеюсь, что это поможет
Обычно у вас будет одна команда (dev + qa) и один проект и отслеживать прогресс для команды, так как в этом случае задача НЕ считается ДОЛЖНА до проверки и проверки.
Если в вашем случае вы хотите иметь две команды - вам может потребоваться два проекта. Однако, на мой взгляд, это не оптический случай. Команды dev и qu должны быть семантически связаны при работе над одним и тем же проектом. Когда команда разработчиков сначала завершает разработку задачи, тогда ее необходимо протестировать, но вы не можете быть уверены, что команда разработчиков выполнена с этой задачей, поскольку в коде может быть ошибка, и команда qa должна вернуть задачу команда разработчиков и эта команда будут иметь новую работу над этой задачей. Я не оспариваю ваши методы управления, я скорее говорю, что это может быть трудно измерить и поддерживать.
В том случае, если «задание считается выполненным», я не уверен, что вы сможете изменить это поведение по умолчанию, но вы можете поднять проблему с самими Atlassian: http://support.atlassian.net/.
Однако вы можете создавать отдельные проекты для обеих команд. Например: ProjectName-Dev & ProjectName-QA. И затем, когда команда разработчиков завершит что-то, создайте соответствующую задачу в другом проекте. Это было бы легко отслеживать прогресс отдельных команд. Однако для меня это кажется слишком много ручной работы. Существует еще одна возможность - возможность перемещения объекта между проектами, но это может повлиять на окончательный вид графика сжигания. Если вы примете модель, которая использует основную проблему для всех задач (для каждого модуля или какой-либо другой части работы), а затем переместите подзадачи, вы сможете сохранить данные «времени».
Идите вперед и спросите Atlassian. :)