Только пацаны, канбан доски проектируются не исходя из фаз того, что вы назвали задачами, там чутка по другому

@LevLeontiev включить тебя в группу где только канбан обсуждается?

@LevLeontiev включить тебя в группу где только канбан обсуждается?

@LevLeontiev включить тебя в группу где только канбан обсуждается?

Второе - мы должны рассмотреть процесс реализации как процесс накопления знаний. Почему имеенно так, если мы рассматриваем процесс как state machine, то у нас получается сложный workflow с кучей возвратов и каждый переход из состояния в состояние - это передача работы от одного человека другому (или положить работу на хранениее в очередь). При этом, посмотрев на статус на этой State machine нам зачастую сложно просто понять, насколько запрос клииента близок к завершению. Также, сделав state machine мы напрочь убиваем коллаборацию, т.е. совместную и зачастую параллельную работу, у нас в любой момент времени над рабочим элементом работает только один человек (в подавляющем большинстве случаев). Если мы рассматриваеем процесс работы, как процесс накопления знаний, мы принимаем, что изначально у нас очень много неопределенности и мало знаний о запросе, в конце работы неопределенности мало, знаний много. И в ходе работы у нас делается параллельно много разных активностей, но в один момент времени какая-то активность преобладает, мы ее называем доминантной. Наапример в какой-то момент времени может работать с запросом бизнес аналитик и к нему подключается системный аналитик. Бизнес аналитик телает анализ и готовит БТ, системный аналитик собирает какие-то данные, с ходом времени у бизнес аналитика накапливается определенный пласт знаний и его процесс накопления знаний замедляется, теперь в игру вступаеет системный аналитик и готовит ТЗ и его активность становится доминантной. Мы тут видим, что доминантные активности как бы вытесняются одна другой и в приведенном примере у нас вполне могли параллельно для того-же клиентского запроса разработчик и тестировщик готовить себе окружение или тестовые данные или что-то другое, но их активности станут доминантными позже. Если подойти к проектированию доски с такими соображениями, то колонками на доске должны стать именно доминантные активности. Доска в таком виде становится проще. На ней проще отобразить параллельную работу людей над одним запросом и отпадает вопрос "а надо ли двигать стикеры по доске влево"

Другими словами - сначала выкиньте джиру? 🙂

Ничего не мешает это применить к джире