Kanban и Scrum: выжимаем максимум

Роли, определѐнные в Scrum-е
Scrum предписывает наличие 3-х ролей: Product Owner (отвечает за видение продукта и приоритеты),
Команда (отвечает за реализацию продукта) и Scrum Master (устраняет препятствия в работе и
руководит Scrum-процессом).
Kanban же не предписывает вообще никаких ролей.

Перелом наступил, когда все стали "тянуть в одну сторону". Менеджеры четко сформулировали, на
чем нужно сосредоточиться, и оберегали команды от посторонней работы, а команды взяли на себя
ответственность за качество и сроки выполнения. На то, чтобы процесс устоялся, ушло три-четыре

Мы начали с отслеживания "производительности по типам работ" (Velocity per work type) и "длин
очередей" (Queues lengths). Производительность по типам работ легко отслеживать, а своѐ дело эта
метрика делает исправно.

Что же мерять?
Померять можно много чего – время ожидания (время с момента выявления потребности до еѐ
удовлетворения), производительность, длины очередей, отклонения от плана работ... Важнее понимать,
какие метрики окажутся полезными для совершенствования процесса. Мой совет:

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

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

Точных оценок все равно не бывает, так что используйте относительные оценки (например,
размеры футболок – S, M, L)

менять такие настроения

Слишком низкое Kanban ограничение => люди простаивают => плохая производительность
Слишком высокое Kanban ограничение => задачи простаивают => плохое время выполнения

Kanban-команд используют формат более ориентированный на доску, фокусируясь на узких местах и
других видимых проблемах. Этот подход более масштабируем. Если у вас 4 команды с общей доской,