Что мне делать с канбан-предметом, который не прошел тест?

Question

У меня есть базовая плата Kanban, с переключением между Developer и Test:

----------------------------------------------------
| To Do | Ready |         Develop    | Test | Done |
|       |       | In Progress | Done |      |      |

Предположим, я наложил некоторые ограничения на доску. Что мне делать, если предмет не прошел проверку? Это не работа тестировщиков, чтобы на самом деле исправить ошибку, так что, как я понимаю, она не может перейти к «Готово». Я хочу, чтобы тестер вернул его в состояние «Готово», но это превысит предел. Если тестер понижает элемент с «Готово» до «Делать», он в основном отменяет расстановку приоритетов ПО.

На данный момент у меня все в порядке с превышением предела «Готово», отметьте предметы, которые не прошли тесты, и сделайте их приоритетными.

Есть еще идеи?

Answer 1

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

Answer 2

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

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

Answer 3

Полагаю, у вас должно быть два вложенных столбца в столбце In Progress. Один должен быть «Активно проработан», другой должен быть «Ожидание» или как вы хотите это назвать. Если тест не пройден, верните его в Ожидание.

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

Что бы вы ни выбрали, сделайте это под областью "В процессе" на доске.

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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

Это требуетвопрос: есть ли свободное место в Doing Column? Может ли другой программист продвинуть задачу B вперед?

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

Факт таков: Лимит незавершенного производства не является мерой количества свободных слотов.Число доступных разработчиков:

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

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

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

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

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

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

Короче: двигатьсязадание назад, если у вас есть преданный разработчик.

Answer 7

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

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

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

Answer 8

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

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

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

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

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

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