Комментарии 20
Идея прикольная, но я особо смысла не увидел. Вот у меня в "in progress" есть задачи. Пусть какая-то задача справа снова залетает мне в "in progress". Если она выше моей текущей по приоритету, то это значит что она самая важная. В таком случае я ее и так увижу прекрасно и возьму следующей.
Так и не понял в чем здесь проблема была и что нового вы изобрели, только что двигать задачи не нужно обратно
А как понять что она выше по приоритету? В предложенной схеме то что справа выше всего, не зависимо от приоритета карточки, как я понял.
WSJF выше?
В нормальной доске есть цветовая индикация уровня приоритета. Красные первыми, потом желтые, потом белые, потом зелёные, потом серо-буро-коричневые
Приоритет у задачи с флажками справа на лево и сверху вниз. У задачи в UAT, шансов доехать до релиза выше, чем у задачи которая в QA. По этому если появляется по флажку в этих колонках, нужно первым делать править флажок в UAT, затем в QA и только потом возвращаться к задаче которая в работе.
Если вернется одна задача из QA и еще одна из UAT - нет гарантии, что их, переведя обратно, расположат в приоритетном порядке. А для того что бы посмотреть из какой воронки задача вернулась - нужно заходить в каждую задачу. Так же если разработчиков несколько - Продакту и Тимлиду понятнее в каком статусе задача при одном взгляде на доску.
Мы решали этот вопрос вводом отдельного статуса "Доработать" и правилом "при равных приоритетах сначала делать задачи из колонки Доработать"
А мы это решили тем, что пересмотрели процесс QA и отказались от "вот веточка, потестите". Теперь разработчик зовёт QA инженера, они совместно тестируют фичу, проверяя ее на соответствие Acceptance criteria (которые прописаны заранее) и Test cases, если находят баг, то фиксят его на месте, и после совместного тестирования задача уходит в Deploy/Release.
Так мы избавились от двух проблем - очередей в колонке Test и от того, что задачи двигались влево по доске.
То есть там, где вы тратили 1 час QA, вы теперь тратите 1 час QA + 1 час Dev?
Это некорректное сравнение времени, посчитайте дополнительно время на то, когда QA переводит задачу на доработку, разработчику нужно развернуть ветку заново (так как он уже другой задачей занимался), нужно вникнуть в проблему и решить её, а если вдруг после фикса, QA ещё раз найдет ошибку, то повторить все это снова. Плюс это способствует слаживанию команды.
Мы специально не вносили дополнительных статусов в воронку, для прозрачности этапов которые прошла задача. Визуально задача находится на том месте, где появился блокер. Так же не стоит забывать про small win, разработчику комфортнее видеть на доске задачу которая ближе к завершению))
То есть нужно смотреть не только свою колонку, но и, например, на тестировании может оказаться назначенная на меня задача? А если у меня доска настроена только на мои задачи, я ведь вполне могу забыть что еще одну переназначили?!
<сарказм>История о том, как костыль флажок победил граф переходов.</сарказм>
Мне в глаза сразу бросаются несколько не стыковок, обычно не пишу комменты но тут решил поделится, возможно Вам будет полезно/интересно.
Ваша доска разбита по похожему принципу как было у меня в некоторых проектах, но
1. Почему то я не вижу бэклога, задачи реджектнутые на этапе КУА / Аксептанс, вместо того что бы вернутся в Ин Прогресс должны были улетать обратно в бэклог, и там уже можно помечать их флагами, поднимать по приотетности.
2. На канбан доске обязательно должны стоять ВИП лимиты, это как раз и подняло бы значительно прозрачность работы.
3. Вы пишите что работаете с двух недельными спринтами, но при этом у вас есть промежуточные релизы, что вас подтолкнуло к такому разделению ?
Судя по тексту я у вас вижу работу ближе к Continuous flow of work чем к Ограниченным по времени спринтам
Похоже, что вы изобрели велосипед. Очень рекомендую почитать надёжные источники про Kanban. Одна из основных идей Kanban в том, что работа втягивается, а не вталкивается. Вы, возможно, интуитивно, попытались следовать этому принципу, но реализация слегка хромает. С практической точки зрения этот принцип на Kanban досках обычно реализуется следующим образом (это не я придумал):
Перед каждым "активным" статусом, подразумевающим выполнение какой-либо работы, создаётся статус, в котором накапливается очередь работы, ожидающей втягивание. Например, для вашего Development это может быть Waiting for Development или Ready for Development (суть, думаю, вы уловили).
Работа никогда не вталкивается на любой из "активных" этапов, она всегда помещается в очередь, откуда втягивается на соответствующий этап когда для этого появляется ресурс.
В вашем случае задачи, которые, например, не прошли успешно тестирование, должны возращаться в статус, где будут ждать своей очереди разработки/доработки.
Такая система позволяет сохранять приоритеты (например, Jira глобально отслеживает приоритеты задач относительно друга друга, какой бы путь они ни прошли), но избегать переключения контекста для разработчиков (почитайте об этом). Также она позволяет использовать ещё один принцип Kanban - ограничение объема одновременно выполняемой работы.
Вывод классический - прежде чем изобретать велосипед, стоит изучить накопленную другими мудрость.
Публикации
Как визуализация приоритетности задач позволила нам ускорить процесс разработки и сделать его прозрачным для всех