Atlassian GreenHopper и управление выпуском

Question

Мы играем с атласскими продуктами, и я подготовил гибкий спринт с использованием GreenHopper и немного запутался в потоке.

вот как мы делаем текущую разработку в моем офисе:
1. Разработчики завершают связанные с ними проблемы. отметьте их как разрешенные.
2. После того, как все проблемы для спринта завершены, у нас есть билет на выпуск, который содержит сведения о выпуске, и мы назначаем его команде INF для сборки и развертывания в QA. если что-то одобрено в QA, оно перешло к постановке, производству.
3. Если обнаруженные проблемы или какие-либо проблемы не устранены, мы отклоняем выпуск и назначаем обратно разработчикам. и разработчики исправляют их и готовят еще один релиз.

есть ли у кого-нибудь предложения по достижению чего-то подобного с JIRA + GreenHopper или любыми лучшими идеями.

Заранее спасибо.

Answer 1

Мы делаем что-то очень подобное здесь, и все это хорошо работает в JIRA/GreenHopper:

1. владелец продукта создает эпосы истории/Темы/пользователя в JIRA/кузнечик

2. OCCURS Отставание груминг, рассказ немного рассверлился, а сюжетные точки вошли в историю пользователя

3. Спринт-планирование: Истории выбраны для предстоящего спринта, и с помощью зеленого механика мы создаем рассказы о спринте. см. ниже

4. Спринт начинается. Задачи создаются в JIRA разработчиками для отслеживания прогресса и привязки к истории пользователя. Когда все задания для истории завершены, пользовательская история будет выполнена.

5. Мы поставили скрипты в JIRA на кнопку «done», которая автоматически присваивает историю нашей команде сборки, которая объединяет ее в нашу основную базовую линию (не уверен, что это относится к вам). После того, как они поместили его в сборку, пользовательская история будет присвоена команде QA.

6. QA team tests production build ... если он прошел, история закрыта.

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

Это имеет смысл?

JIRA способен на все это, это здорово - хотя вы, возможно, потребуется сделать некоторые конфигурирования для записей для эпосом/темы и т.д.

Мы используем функции GreenHopper для создания и отслеживания истории и спринтов, но для установки прогресс задачи и т. д., мы используем доску - гораздо более заметную и лучше для ежедневного поиска.

Надеюсь, что это поможет.любые вопросы, на которые я с удовольствием отвечу :)

Answer 2

Похоже, что ваш процесс достаточно прост. Я бы рекомендовал, чтобы вы поехали с новыми Rapid Boards в GreenHopper 5.10.1. У Rapid Board есть четкий план> Работа> Отчетный поток.

Глядя на вашу специфику я бы рекомендовал следующее:

• Сначала создайте Рапид совет для общего развития. Эта плата будет использоваться для вашей команды разработчиков и будет иметь Sprints, которые включают исправления ошибок, истории и элементы отставания. Конечный столбец на этой доске будет «Готово» или «Готово к QA»
  • В конце Sprint команда просто «Завершит» этот Sprint и зарегистрирует билет, чтобы получить построенную и развернутую конструкцию для QA
• Я бы рекомендовал переместить такие же вопросы, которые были в Sprint через процесс QA, так что каждый может быть отклонен. Для этого команда QA может просто иметь отдельную Scrum Rapid Board с первой колонкой «Ready to QA». Это позволит им запускать отдельный Sprint, который включает в себя вопросы только что завершенного Sprint.
  • В конце этого Sprint доступны только истории, которые могут быть полезны в столбце «Готово», и команда может решить развернуть только правильные истории или отклонить весь выпуск
  • Истории, которые не передают QA, могут быть обновлены до состояния, которое возвращает их в отставание команды разработчиков для включения в следующий Sprint. В качестве альтернативы они могут быть подняты отдельно назад с командой разработчиков для крепления