Что является приоритетом отклоненного исправления?

Question

Мы пытаемся оптимизировать наш процесс разработки. Наша команда работает с использованием процесса канбан, наша цель - максимально свести к минимуму наш WIP.

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

Способ, которым мы в настоящее время обрабатываем это, вернемся к билету в колонку «в процессе» разработчика, чтобы он возвращался в цикл и фиксировал AFAP, и (а) он решает, что делайте с ним, эффективно работая над несколькими вещами одновременно.

Я не думаю, что это оптимально, и мне интересно, не следует ли нам на самом деле «перерегистрировать» его в нашу разработку To-Do, даже если наверху, учитывая, что мы уже потратили на это время , так что разработчик эффективно заканчивает то, над чем он работает, затем переключается. Моя проблема с этим изменением в нашем процессе будет заключаться в том, что это фактически увеличивает время выполнения одного элемента и нарушает обещание, что когда-то что-то будет развиваться, мы сосредоточимся на нем и зафиксируем его.

Мне интересно, что вы делаете по этому вопросу?

Answer 1

Это отличный вопрос и общая проблема для команд, которые являются новыми для Kanban.

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

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

Вы верны, указав, что если вы переустановите работу с поврежденной ошибкой, вы очень эффективно продлеваете время выполнения. И то, что вы описали, похоже, на самом деле не возвращает его в столбец To Do, потому что обычно разработчики могут решить, что вытащить из Ready Queue, но то, что вы описали, в основном возвращает элемент вверх столбца Development Doing.

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

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

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

Кроме того, это может помочь думать о ваших столбцах в рабочем процессе как о «этапах жизни» для рабочего элемента, а не о точке, где работа передается между функциями в вашей команде. Это означает, что если у вас есть столбцы Analysis, Development и Testing на вашей плате, когда рабочий элемент находится в Analysis, он в первую очередь оценивается, но это не означает, что весь анализ завершен. Он может получить дополнительный анализ, когда он находится в процессе разработки, но главная цель текущей деятельности - разработать исправление. Как только разработка, кажется, завершена, рабочий элемент перемещается в первую очередь в проверку (тестирование), но если исправление является неполным или сломанным, может потребоваться еще немного развития.

Answer 2

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

Так шаги:

1. Определить ошибку
2. Написать тест, который подтверждает ошибку
3. Выполнить тест, он должен терпеть неудачу
4. Работа на исправление до того момента, когда test проходит

Это не поможет решить вашу проблему, но это должно помешать возникшей проблеме.