Что мне делать с канбан-элементом, не прошедшим проверку?

Я бы разделил состояние «Готово» на «Повторное открытие» и «Готово». В этом случае вы можете четко разделить элементы, которые нужно переделать, и новые элементы. Элементы, которые необходимо переработать, обычно следует обрабатывать в первую очередь, чтобы разработчикам было ясно, что нового и что возвращается на этапе тестирования.

Несколько возможных решений (я уверен, что есть и другие), в том числе:

1) Пометка заявок на месте, при этом команда ожидает, что отмеченные вопросы (по какой-либо причине) будут решены в приоритетном порядке.

2) Перемещение билетов назад. (Но тогда действительно ли доска отражает состояние проекта? Вы также отменяете изменения? Стоит подумать.)

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

Они даже не исключают друг друга. Даже если вы придерживаетесь №1 (мое предпочтение по умолчанию), №3 имеет смысл, когда элемент стоит выпустить даже в его текущем состоянии, а №2 может иметь смысл, если это не столько ошибка, сколько серьезное недоразумение.

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

Это зависит от того, чего вы хотите достичь. Один из вариантов - отнестись к отказу настолько серьезно, что вы откажетесь от текущего рабочего элемента, чтобы исправить ошибку.

Я думаю, ваше решение подойдет (сделайте отметку о провале действительно очевидной).

И, возможно, настоящий ответ - это попробовать какое-то время и посмотреть, как это сработает.

Я почти уверен, что то, что я собираюсь описать в своем ответе, будет сильно отличаться от канонического канбана. Я имею в виду, это может быть очень спорным.

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

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

«Предположим, что доска представляет собой как минимум два столбца (например,« Выполнение »и« Контроль качества, но имена здесь не важны), представляющие действия, которые программист призван выполнить. Задача A перемещена в QA, должен ли программист работать над задачей A или переместить задачу B в Doing и начать работать над ней? Все мы знаем, что многозадачность - это зло, и программист не должен работать одновременно над задачей A и задачей B.

Правильный ответ: сначала поработайте над Задачей А. Канбан - это вытягивающая система, которая проясняет это очень четко: но даже без Канбана очевидно, что задача А ближе к бизнес-ценности, и ее не следует размещать в столбце QA и как можно скорее перемещать в столбец Done. Отходы следует удалять, а не складировать.

Возникает вопрос: есть ли свободный слот в столбце "Делать"? Может ли другой программист продвинуть задачу B вперед?

Вопрос неуместен. Если есть только один разработчик, ответ - нет. Поскольку программист недоступен, фактический предел в столбце «Работа в процессе» должен быть уменьшен до 0. При использовании двух разработчиков правильный вопрос должен быть «Доступен ли другой разработчик?»

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

Доска, которую я пытался представить, использует другой принцип: общее, личное и индивидуальное представление одного программиста, как магнитная наклейка. Назовите это Face. Программист ставит перед собой задачу сообщить, что он работает над этой проблемой. Поскольку у каждого программиста есть только одно лицо, программисты не могут выполнять более одной задачи. Лимит незавершенной работы не является показателем количества доступных бесплатных слотов: доступные члены команды, то есть лица без задачи, - хороший показатель.

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

Тем не менее, последствия нетривиальны: с помощью Faces легко увидеть, кто с кем работает, как группа группируется и кого можно спросить по конкретной проблеме. "

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

Я считаю, что то же самое может относиться к вашему случаю: в столбце QA у вас есть тест на провал Kanban-item. Для меня нет проблем с перемещением его назад в столбце «Делает», разработчик, который работал над ошибочным элементом, по-прежнему привержен этому. Собственно, у вас есть свободный слот.

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

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

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

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

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

Или может тестировщик вернуть элемент в ЗП и заставить их изменить его приоритетность - так, по сути, он снова начнется со столбца дел? Для этого нужен заказ на поставку - они решают, насколько важно внести исправление.

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

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

Что бы вы ни выбрали, делайте это в области «Выполняется» на доске.

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

Стоит задать следующие вопросы. Кто отвечает за разработку? Кто отвечает за тестирование? Кто несет ответственность за повторную разработку в случае неудачных тестов? Надеюсь, ваш ответ был «Команда».