Подтвердить что ты не робот

Версии Sprint vs Release версии в Jira и Greenhopper

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

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

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

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

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

  • 1,0
    • Sprint 1
    • Sprint 2
    • Sprint 3
  • 1.1
    • ...

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

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

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

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

Ответ 6

Я пытаюсь использовать K.I.S.S. по возможности, поэтому я использовал поле метки для отметки выпусков. Мне редко приходится видеть выпуск в контексте scrum/taskboard. Поэтому, когда приходит время просматривать все элементы в выпуске, я просто запускаю поиск для моего имени выпуска.