Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 5
Kanban имеет одну фатальную проблему — он не даёт точки отсечения сотрудника. scrum даёт. Если человек не выполняет спринты из раза в раз — плохой программист (каким бы хорошим он ни был — не делает спринты, какая от него польза?). А в kanban этой простой и ясной метрики нет.
Как же? Все как раз проще. Берете определенный класс задач по оценкам команды и смотрите на cycle time при их выполнении у каждого члена команды. Если отличается сильно у одного, то это повод разобраться. Возможно он всем помогает и благодаря ему вообще движется разработка. Что такое «человек не выполняет спринты» я вообще понять не могу. В Scrum как раз вся командная активность прячется за спринтом и разобраться кто хороший кто плохой потом не так просто.
Только основываясь на опыте Скрама, Канбан судить не берусь.
Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.
Лично в нашей команде главная метрика — успешность спринта, которая основывается на достижении поставленной в начале спринта цели.
К примеру, 8 из 10 задач в спринте крутятся вокруг внедрения нового модуля А. Цель — end-2-end реализация модуля А. Если цель достигнута (все 8 задач выполнены), значит спринт успешен. Даже несмотря на что возможно остальные 2 задачи не были стартованы.
Ориентироваться на Velocity я бы не стал. Если эта метрика растет, это не значит, что вы стали выпускать больший объем задач. Зачастую, если метрика и растет постоянно, то это показатель, что команда начинает давать более реалистичные оценки, не более того. Особенно это характерно для слаженных команд. Для команды из всех новых членов, характеристика должна постепенно улучшаться за счет повышения уровня коммуникации, более глубокие знания предметной области и т.д.
Круто, когда получается совмещать методики. Важно использовать их исходя из проблем и запросов бизнеса и компании.
Скрам был "создан" для быстрых побед продуктовой самостоятельной команды.
Канбан-метод - для анализа работы системы производства (кстати да, не конкретных инженеров).
Их можно совмещать и нужно, когда Скрам уже дал все плюшки своей методологии, а нам нужны ещё улучшения или есть проблемы, которые только Скрамом не выявляются/не решаются. Но всё-таки важно понимать для чего внедряются те или иные инструменты.
Тот же Скрам часто внедряют для сближения бизнеса и it. Тут для пользы метрик канбан надо в начале, до перехода на Скрам, провести большую работу по описанию текущего процесса, покрытию канбан метриками и накоплению исторических данных, чтобы потом было с чем сравнивать.
Подход классный. Очень хочется узнать о реальном кейсе, если есть пример - было бы очень интересно о нём почитать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Метрики в Scrum и Kanban