История изменений

Да кто бы сомневался с таким подходом :) Свалки быть не должно. Побей всё на эпики, в эпиках выдели юзерстори. Пойми разницу между эпиком и юзерстори. Карточки промаркируй релизами, релизы надо действительно выпускать. Между карточками проставь связи типа «блокирует», «заблокировано», «связано», «является подзадачей», итп.

Когда заказчик прибегает с новыми фичами - фигачь новые юзерстори и эпики. При этом важно с берега договориться с бизнесом, что вы работаете именно по канбану и никак иначе. В рамках канбана, предполагается специальная «производственная линия» на «задачи от бигбоссов» с большим приоритетом и срочностью. Емкость этой линии заранее обговаривается с бизнесом, например - не больше 1 задачи в линии. Или 3. Если линия заполнилась - бизнес ждёт. Это нерушимое правило #1. (При этом в эпик можно напихать задач сколько угодно - это не значит, что они встанут в приоритетную линию). Этот подход - это классика канбана, кстати.

Канбан - это о том, что ты решаешь стандартные проблемы. Он как раз создан для того, чтобы было визуально видно проблемы типа «много work in progress».

Самоорганизующаяся команда (типа нашей) или руководятел (в случае рабско-ориентированной) может просто бросить больше сил на development. Или может быть, куча задач в разработке потому, что их не успевают принять тестировщики, и перед тестированием образовался затор - тогда надо бросить силы на тестирование.

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

Для R&D проектов кабан больше подходит, чем для серийных. Серийное - это скрам, когда ты уверен что к концу спринта ты что-то сделаешь. А что делать, если ты не уверен, что сделаешь хоть что-то - ни за спринт, ни за два? А в канбане задача может валяться хоть месяц. (Чтобы они там не загнили, есть специальные методики).

Короче, чините свой канбан.

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

Да кто бы сомневался с таким подходом :) Свалки быть не должно. Побей всё на эпики, в эпиках выдели юзерстори. Пойми разницу между эпиком и юзерстори. Карточки промаркируй релизами, релизы надо действительно выпускать. Между карточками проставь связи типа «блокирует», «заблокировано», «связано», «является подзадачей», итп.

Когда заказчик прибегает с новыми фичами - фигачь новые юзерстори и эпики. При этом важно с берега договориться с бизнесом, что вы работаете именно по канбану и никак иначе. В рамках канбана, предполагается специальная «производственная линия» на «задачи от бигбоссов» с большим приоритетом и срочностью. Емкость этой линии заранее обговаривается с бизнесом, например - не больше 1 задачи в линии. Или 3. Если линия заполнилась - бизнес ждёт. Это нерушимое правило #1. (При этом в эпик можно напихать задач сколько угодно - это не значит, что они встанут в приоритетную линию). Этот подход - это классика канбана, кстати.

Канбан - это о том, что ты решаешь стандартные проблемы. Он как раз создан для того, чтобы было визуально видно проблемы типа «много work in progress».

Самоорганизующаяся команда (типа нашей) или руководятел (в случае рабско-ориентированной) может просто бросить больше сил на development. Или может быть, куча задач в разработке потому, что их не успевают принять тестировщики, и перед тестированием образовался затор - тогда надо бросить силы на тестирование.

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

Для R&D проектов кабан больше подходит, чем для серийных. Серийное - это скрам. А в канбане задача может валяться хоть месяц. (Чтобы они там не загнили, есть специальные методики).

Короче, чините свой канбан.

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