Разделение спринта и релиза в JIRA

в настоящее время у нас есть следующие состояния/столбцы в JIRA:

  • Открыть/Задать (-> Разработчик берет задачу и начинает работу)
  • Выполняется (-> Разработчик ставит задачи на выполнение)
  • Готово (-> тесты контроля качества на стадии подготовки и установка задачи на готовность к развертыванию или повторное открытие)
  • Готово к развертыванию (-> Разработчик развертывает эти задачи в день выпуска)
  • Развернуто (-> Контроль качества/заинтересованная сторона снова тестирует задачу в Live/Production и закрывает или снова открывает)
  • Готово/Закрыто

В моем текущем понимании это неправильно, потому что мы пытаемся решить две проблемы в одном измерении состояния: разработка и развертывание. Я хотел бы отделить спринт от выпуска/версий. В настоящее время мы не можем завершить спринт, пока все заявки не будут утверждены в производстве, что приводит к узким местам.

Что бы вы предложили? Одна идея, которую я имею в виду: ограничить статус «Открыто», «Выполняется», «Готово», «Закрыто» и обрабатывать развертывание/выпуск через встроенную версию JIRA. Если проблема возникает на производстве, необходимо открыть запись об ошибке.

В противном случае я не вижу шансов, поскольку версия/выпуск JIRA 6.4, похоже, не включает столбцы статуса сами по себе.


release jira sprint scrum
person SBehn    schedule 03.06.2015    source источник

Ответы (1)


arrow_upward
1
arrow_downward

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

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

Спринт — это временной интервал, а не установленный объем работы. Когда временной интервал заканчивается, работа, которую вы все еще выполняете, не «сделана». Если вы регулярно не в состоянии завершить всю работу, которую вы вносите в спринт, это говорит о том, что вы вносите слишком много работы. Скорость команды, которая является мерой работы, которая «выполняется» в каждом спринте, должна быть хорошей. указание на то, каковы ваши возможности спринта.

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

person Barnaby Golden    schedule 03.06.2015
comment
Спасибо за Ваш ответ. Но разве не неправильно иметь зависимости вне фактической команды Scrum? Я бы определенно сказал, что заинтересованная сторона не является частью скрам-команды. Команда не может совершить что-то, что выходит за рамки их компетенции. С другой стороны, я бы не хотел передавать всю ответственность за приемку команде QA внутри команды Scrum. Есть предположения? - person SBehn; 08.06.2015
comment
В идеале у Скрам-команды должно быть все необходимое для реализации. Это не всегда возможно, поэтому мы стараемся минимизировать внешние зависимости. Немногие Скрам-команды устраняют все внешние зависимости. Проблема с передачей приемки QA: что происходит, когда обнаруживаются ошибки? Вам нужно будет вернуть эти ошибки в команду. Кроме того, исследования показали, что эффективно исправлять ошибки вскоре после того, как первоначальная работа была сделана. Передача в QA может привести к тому, что ошибки будут исправлены через несколько недель. Лучше запланировать приемочное тестирование в спринте и работать над любыми ошибками по мере их появления. - person Barnaby Golden; 08.06.2015