Спринтерские версии vs версии для версий в Jira и Greenhopper

Question

При использовании Greenhopper с Jira ясно, что Greenhopper использует поле «fixed in version» в вопросах Jira, чтобы представить, с какой проблемой запускается проблема. Это само по себе немного хакерское, потому что проблема, по-видимому, может быть обработана в нескольких спринтах, и поскольку взаимосвязь между проблемой и спринтом - это именно то, что было , работало на во время спринта с признанием того, что вы можете не выполнить задачу в запланированное время.

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

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

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

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

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

Answer 1

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

Answer 2

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

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

Управление версий в проекте релиза означает высвобождает (то есть 2,2-patch1, 1.1 ...) Управления версий в проекте команды обозначают спринты (спринтерской 10-15, 10-20 Спринта)

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

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

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

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

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

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

Фрэнсис Martens

Answer 3

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

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

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

Answer 4

В игре есть две проблемы.

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

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

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

• 1.0
  • Sprint 1
  • Sprint 2
  • Sprint 3
• 1,1
  • ...

Когда вы играете СТРОЙ-1 в Sprint 1, вы обнаружите, что STORY-1 будет иметь fixVersion «1.0, Sprint 1»

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

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

Answer 5

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

Answer 6

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

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

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