Версии Sprint по сравнению с Версиями выпуска в Jira и [закрытом] Greenhopper

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

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

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

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

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

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

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

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

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

Если интересно, я могу предоставить вам дополнительную информацию по этому поводу.

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

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

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

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