Как решить проблему доставки производственных исправлений в Scrum?

Отличные ответы выше.

Но я добавлю... Найдите время с PO & DT, чтобы обсудить исправления производственных ошибок и попытаться разработать политику, чтобы ваша команда лучше понимала исправления Scrum Vs Emergency.

Обычно команды применяют методологию… «Если это так важно… Исправьте, разверните, вернитесь к спринтерским задачам».

Затем следите за скрытым изменением PO как чрезвычайными ситуациями, когда на самом деле это просто пропущенные требования.

Удачи!

Scrum — это средство, позволяющее быстрее и комфортнее добраться до места назначения. Не дубина, чтобы бить друг друга по голове...

В Scrum ничто не мешает вам пересмотреть рамки этого спринта или выпустить новую версию во время спринта. SCRUM говорит только о том, что спринты должны быть достаточно короткими, поэтому обычно в таких вещах нет необходимости (т. е. PO может ждать следующего спринта для всего, что приходит). Но весь смысл Agile в том, что вы можете адаптироваться к меняющимся обстоятельствам. Кроме того, Scrum не говорит, что вы можете выполнить только в конце спринта, но что вы должны быть в состоянии выпустить в конце спринта.

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

Люди и взаимодействия важнее процессов и инструментов

Работающее программное обеспечение над исчерпывающей документацией

Сотрудничество с клиентами в ходе переговоров по контракту

Реагирование на изменение вместо следования плану

Я видел, как люди добавляли аварийную полосу на свою канбан-доску, и эти заявки получали приоритет.

Это предотвращает нарушение концепции Канбана, но, как уже красноречиво ответил Кемпет , инструменты управления проектами существуют для облегчения (и, надеюсь, ускорения) процесса доставки, в конечном счете, в надежде сделать компанию богатой. :-)

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

Я бы сказал, что есть несколько разных вещей, которые нужно решить.

Другое дело, если это ошибка или отсутствующая функциональность. Если это ошибка, внимательно изучите ее масштабы и возможные последствия. Владелец продукта должен быть в состоянии решить, руководствуясь здравым смыслом, можно ли подождать до следующего спринта. Обычно может. А если нет, то подход, вероятно, должен быть таким: исправить это, вернуться к спринту и принять это во внимание, когда Скрам-команда проверит этот спринт в ретроспективе и обсудит, как улучшить, чтобы это не повторялось много раз в будущем. . Например: Было ли у команды определение «сделано»? Прошла ли развернутая разработка контрольный список «Определение готовности»?

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

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

Есть много способов справиться с этим, но, на мой взгляд, следующие два являются наиболее устойчивыми:

1. Если скорость команды составляет 50 историй, начните спринт с 35 историями. Остается 15 для исправления ошибок и/или постоянного улучшения/обучения.
2. Максимально укоротите спринт. Нет смысла отвлекать команду багами. Большинство ошибок можно будет дождаться планирования следующего спринта, чтобы получить приоритет.

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

После того, как все сделано, пробки для производственных шоу все еще могут редко появляться. Мой подход к этому таков: остановите всю команду, исправьте это и двигайтесь дальше.

Что мы делаем на данный момент.

У нас запланирован спринт, состоящий из 2 частей.

• новостройка (70%)
• Исправление багов/инцидентов/горящего производства

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

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

Не забывайте называть это небольшими спринтами или около того. Если это действительно проблема, возможно, вам нужно немного сократить спринты. 1 (или максимум 2) недели. Таким образом, вы также можете быстрее решить эти надоедливые производственные проблемы.