Версии спринта против версий релиза в Jira и Greenhopper

Question

При использовании Greenhopper с Jira ясно, что Greenhopper использует поле "исправлено в версии" в выпусках Jira, чтобы показать, над каким спринтерским спрайтом работает проблема. Само по себе это немного хакерски, потому что проблема может быть решена в нескольких спринтах, и потому что связь между проблемой и спринтом - это именно то, над чем она работала во время спринта, с осознанием того, что вы можете не завершить задание в запланированное время.

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

Но я обнаружил, что есть и другие проблемы, которые также основаны на поле "исправлено в версии". В частности, нужно уметь видеть, какие проблемы планируется решить, в каких версиях выпуска (реальных версиях) и использовать эту информацию в качестве средства проверки / контроля качества.

Как другие пользователи Greenhopper комбинируют эти два использования поля "исправлено в версиях"? Вы устанавливаете версии спринта как под-версии версий выпуска? Используете ли вы какое-то настраиваемое поле для версий выпуска? Я нахожу это трудным, потому что команда Scrum работает над несколькими компонентами, независимо от версий. Кроме того, могут быть выпуски исправлений ошибок и разработка функций на одном и том же компоненте, происходящие в одном и том же спринте.

Подводя итог, я считаю неизбежным, что команда будет работать над "Некоторым продуктом 3.4.0" (выпуском функции), "Некоторым продуктом 3.3.1" (выпуском исправления) и "Другим продуктом 1.2" в одном и том же спринте., Было бы невозможно пометить этот спринт как подрывную деятельность каждой из этих трех версий (для двух разных компонентов). И создание трех разных спринтов в Гринхоппере действительно уменьшит ценность Гринхоппера.

Находятся ли другие пользователи Greenhopper в такой же ситуации? Как вы справились с этим?

Answer 1

Здесь есть две проблемы.

Сначала ваши спринт-версии на самом деле являются "подрывными" версиями релиза. Это означает, что ваши истории действительно получают два значения в поле fixVersion.

Вы можете настроить это в Greenhopper, установив мастер-версию.

Так что, если у вас есть релиз 3 спринта для версии 1.0, вы устанавливаете дату релиза 1.0 и помещаете свои истории в спринт 1, спринт 2 и спринт 3, так что

• 1,0
  • Спринт 1
  • Спринт 2
  • Спринт 3
• 1,1
  • ...

Когда вы играете в STORY-1 в Sprint 1, вы обнаружите, что STORY-1 будет иметь фиксированную версию "1.0, Sprint 1"

Для элементов, которые вы отслеживаете для выпуска, но не в спринте, просто установите fixVersion в 1.0.

Во-вторых (и это только подсказка), вы можете использовать отдельные проекты для вашей спринтерской работы и для поддержки производства. Это полезно в крупных организациях

Answer 2

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

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

Управление версиями в проекте выпуска означает выпуски (т.е. 2.2-patch1, 1.1 ...) Управление версиями в командном проекте обозначает спринты (спринт 10-15, спринт 10-20)

Проект релиза содержит только ошибки, запросы функций, запросы... Командный проект содержит только задачи, истории, ...

Автоматизация позволяет нам синхронизировать спецификации и связанные задачи: типичный сценарий работает следующим образом

• Спецификация создается в проекте релиза.
• Сотрудник службы поддержки создает одну или несколько задач в командных проектах и ​​связывает спецификацию с задачами, используя ссылку "реализовано".
• С момента начала работы над задачей спецификация переходит в состояние "в разработке".
• Спецификация считается решенной, если все связанные задачи решены

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

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

Я могу предоставить вам больше информации по этому вопросу, если вы заинтересованы.

Фрэнсис Мартенс

Answer 3

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

Если вы хотите, чтобы это стало реальностью так же, как и я, перейдите по http://jira.atlassian.com/browse/GHS-945 и проголосуйте за этот вопрос. Эта цитата подводит итог: "Если бы у GreenHopper были итерации в качестве первоклассных граждан..."

Однако в настоящий момент, вероятно, нам придется создать новое поле с именем version в jira и использовать его для отслеживания "реальных версий продукта", к которым относится проблема. В наших репозиториях исходного кода у нас также есть ловушка фиксации, поэтому, когда разработчик делает коммит, он обновляет билет jira "реальной версией продукта", которая относится к исходному коду, который они фиксируют. Мы храним эту информацию в файле конфигурации, чтобы ловушка фиксации знала, какую версию использовать для какого репозитория / пути исходного кода. Это не идеально, но это наш единственный вариант в настоящее время.

Answer 4

Просто используйте быстрые доски в GreenHopper, они были представлены не так давно, но они дают почти все, что вам нужно.

Вы можете поставить надписи на свои вопросы, например, "sprint-1", "sprint-2" и так далее. Затем создайте выпуск FILTER. Затем создайте RAPID BOARD на основе фильтра. В конце вы получите хорошую доску с текущими выпусками sprint-X независимо от версии и даже проекта.

Пожалуйста, проверьте, что Sprint по сути не является версией программного обеспечения. В реальном мире, когда у вас более одного клиента, вам нужно исправить и поддержать множество версий, но вам все равно нужно держать все на ходу. В этом случае спринты все еще хороши, но они просто представляют объем работы, которую следует выполнить в течение определенного периода времени. В любом случае, версия - это то, что вы подарите кому-либо вне времени разработки. Поэтому не смешивайте версии программного обеспечения и спринты ("отображение" времени и задач)! Не используйте иерархии, где версия спринта является дочерней по отношению к реальной версии программного обеспечения! Храните несвязанные вещи отдельно!

Answer 5

Разве у спринта в теории не должно быть "отгружаемого" продукта в конце? Это означает, что у спринта есть проблемы, которые либо решены, либо "провалились". Вот почему я бы рекомендовал разбить проблему на более мелкие части.

Answer 6

Я стараюсь использовать KISS всякий раз, когда это возможно, поэтому я использовал поле метки для обозначения релизов. Мне редко нужно видеть релиз в контексте Scrum / Taskboard. Поэтому, когда приходит время просмотреть все элементы в релизе, я просто запускаю поиск по названию релиза.