Как обрабатывается разделение пользовательских историй, когда первая версия интегрирована с HPALM?

Question

Наша организация движется к интеграции Версии Один и HP ALM, чтобы требования, тесты, дефекты синхронизировались в двух направлениях.Прямо сейчас мы исследуем все возможные варианты использования, которые мы можем настроить для интеграции.Одна из проблем, с которой мы сталкиваемся, это «Разделение пользовательской истории».Если пользовательская история не завершена во время спринта, мы разделяем пользовательскую историю и переносим оставшуюся работу на следующий спринт.Как работает синхронизация после первой версии и HP ALM?Как определить этот случай для интеграции?

Answer 1

Посмотрите на пример использования, приведенный ниже:

Постановка проблемы : команда управления проектами и разработки используют VersionOne в качестве системы управления проектами и HPALM в качестве системы разработки.Если эти две системы не синхронизированы, у менеджера проекта нет четкого представления о состоянии задачи и аналогичных данных для планирования входящих запросов клиентов.

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

• Менеджер проекта регистрирует «пользовательскую историю»в VersionOne.

• «Пользовательская история» синхронизируется с HPALM.

• Команда разработчиков разбивает «историю» на «задачи» в JIRA.

• Как только команда разработчиков выполнит все задачи и изменит статус пользовательской истории в Jira на «завершено», изменение также будет синхронизировано с VersionOne.

Если это похоже на то, что вы ищете, закажите OpsHub Integration Manager и таблицу данных для VersionOne - интеграция HP ALM наИК-сайт.

Answer 2

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

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

Эта функциональность Rally, однако, не представлена ​​в его интерфейсе RestAPI, и никакие события не запускаются или не доступны уведомления.Новая пользовательская история приходит с событием add, но изменения, внесенные в существующий префикс, не выполняются.

Чтобы отследить изменения, внесенные в более старую пользовательскую историю, мы попросили пользователя внести изменения в старую историю вручную.

Надеюсь, это поможет.