Все мы строим новое на плечах гигантов. Я про КПД. Но текст-то про то, как намучились с внедрением :) Может, не очевидно, но во всех этих роадшоу и версионированиях сквозит боль...
Тимур! Спасибо за вопросы, они очень глубокие и правильные. Получилось целое рассуждение на тему.
Какую пользу приносят все перечисленные метрики?
Мои самые любимые вот эти: Item Aging и WIP. Это даже не метрики — это просто визуальные сигналы — тут что-то не так. Они помогают в моменте понять, что есть проблема и направить усилия на разблокировку.
Данные по Throughput (сколько штук работы мы делаем за спринт) берегут команду от переполнения бэклога спринта. На планировании может прозвучать вопрос: “мы никогда столько не делали, почему мы думаем, что в этом спринте сделаем?”
Cycle Time сейчас для нас не очень полезна. Наша основная единица — история. История попадает на прод за 1 спринт. Пока нам этого достаточно.
Предлагаю на метрики смотреть через призму ситуации, когда у вас есть 2-3 команды и вас есть 20-30 команд. Пока у вас немного команд метрики могут казаться лишними, надуманными и не отражающими всю богатую жизнь вашего коллектива. Когда мы переходим к масштабу, появляется потребность в абстракции.
Как среднестатистическое нечто даст возможность более четко планировать?
Не совсем среднестатистическое. Это данные одной и той же команды за несколько аналогичных периодов по аналогичным задачам. Работает ли тервер в жизни? Лучше один раз попробовать на своих данных, чем читать в пересказах :)
Просто выглядит так, что метриками пытаются нормальную ежедневную менеджерскую работу заменить, но в итоге она всё равно нужна и всё равно приходится спускаться на уровень каждой задачи и рассматривать ее индивидуально.
Метрики сами по себе не могут заменить работу, только показать аномалии, помочь сделать прогноз, подсветить, куда копать. Если говорить о работе Delivery Manager, то в фокусе внимания не сама заблокированная задача, а причина блокировки — нужно ли нам поменять процесс, чтобы такие задачи нас больше блокировали и не застревали в нашем процессе.
И еще раз наведу фокус на масштаб команды — чем больше людей, тем сложнее без цифр. Представьте, вы приходите менеджером в незнакомую команду, неужели не хочется взглянуть на метрики?
И ещё момент — а как ребята из разработки отнеслись к играм по канбан-методу и по скраму?
По-разному. Люди разные. Кто-то не любит играть, кто-то не любит изменения. А кто-то ровно наоборот, за любой движ и говорят спасибо.
Иллюстративный эффект был достигнут в обоих случаях. На дебрифе после игр участники обращали внимание на моменты, отвечающие дидактическим целям.
Scrum более комплексная вещь, ее с одной игры не продашь. Было весело, но само по себе не убедило.
И в итоге всё же какие преимущества дало внедрение? Что получилось значительно улучшить?
Предсказуемость. Мы релизим каждый спринт. Для нас это много значит.
Перевешивают ли эти преимущества стоимость внедрения?
Стоимость — коварное слово. Отвечу так: те усилия, которые мы потратили в краткосрочной перспективе полностью окупили себя в долгосрочной перспективе. Мы значительно меньше времени и сил тратим на обсуждения, почему что-то не получилось и в какие сроки мы что-то можем или не можем сделать. Все шаги и сроки прозрачны, в головах у всех одно видение процесса.
Не придется ли через какое-то время всё отменять и внедрять новый фреймворк?
Суть Agile (Канбан и Scrum) в изменениях и постоянной работе над процессами. Изменения — это просто часть работы.
А, ну и момент по встречам — зачем их переименовывать и т.п.?
Когда работаешь с группой людей необходимо установить общее понятийное поле. Можно изобрести свой словарь, а можно взять готовый. Идем в Канбан — берем словарь Канбан, там все написано и можно сверить свое понимание.
Я упомянула про смену названий в контексте того, что бывают настоящие изменения, а есть просто смена названий. Смена названия сама по себе не поменяет содержание.
Разогнать — просто, вот заставить работать...
Все мы строим новое на плечах гигантов. Я про КПД. Но текст-то про то, как намучились с внедрением :) Может, не очевидно, но во всех этих роадшоу и версионированиях сквозит боль...
Тимур! Спасибо за вопросы, они очень глубокие и правильные. Получилось целое рассуждение на тему.
Какую пользу приносят все перечисленные метрики?
Мои самые любимые вот эти: Item Aging и WIP. Это даже не метрики — это просто визуальные сигналы — тут что-то не так. Они помогают в моменте понять, что есть проблема и направить усилия на разблокировку.
Данные по Throughput (сколько штук работы мы делаем за спринт) берегут команду от переполнения бэклога спринта. На планировании может прозвучать вопрос: “мы никогда столько не делали, почему мы думаем, что в этом спринте сделаем?”
Cycle Time сейчас для нас не очень полезна. Наша основная единица — история. История попадает на прод за 1 спринт. Пока нам этого достаточно.
Предлагаю на метрики смотреть через призму ситуации, когда у вас есть 2-3 команды и вас есть 20-30 команд. Пока у вас немного команд метрики могут казаться лишними, надуманными и не отражающими всю богатую жизнь вашего коллектива. Когда мы переходим к масштабу, появляется потребность в абстракции.
Как среднестатистическое нечто даст возможность более четко планировать?
Не совсем среднестатистическое. Это данные одной и той же команды за несколько аналогичных периодов по аналогичным задачам. Работает ли тервер в жизни? Лучше один раз попробовать на своих данных, чем читать в пересказах :)
Просто выглядит так, что метриками пытаются нормальную ежедневную менеджерскую работу заменить, но в итоге она всё равно нужна и всё равно приходится спускаться на уровень каждой задачи и рассматривать ее индивидуально.
Метрики сами по себе не могут заменить работу, только показать аномалии, помочь сделать прогноз, подсветить, куда копать. Если говорить о работе Delivery Manager, то в фокусе внимания не сама заблокированная задача, а причина блокировки — нужно ли нам поменять процесс, чтобы такие задачи нас больше блокировали и не застревали в нашем процессе.
И еще раз наведу фокус на масштаб команды — чем больше людей, тем сложнее без цифр. Представьте, вы приходите менеджером в незнакомую команду, неужели не хочется взглянуть на метрики?
И ещё момент — а как ребята из разработки отнеслись к играм по канбан-методу и по скраму?
По-разному. Люди разные. Кто-то не любит играть, кто-то не любит изменения. А кто-то ровно наоборот, за любой движ и говорят спасибо.
Иллюстративный эффект был достигнут в обоих случаях. На дебрифе после игр участники обращали внимание на моменты, отвечающие дидактическим целям.
Scrum более комплексная вещь, ее с одной игры не продашь. Было весело, но само по себе не убедило.
И в итоге всё же какие преимущества дало внедрение? Что получилось значительно улучшить?
Предсказуемость. Мы релизим каждый спринт. Для нас это много значит.
Перевешивают ли эти преимущества стоимость внедрения?
Стоимость — коварное слово. Отвечу так: те усилия, которые мы потратили в краткосрочной перспективе полностью окупили себя в долгосрочной перспективе. Мы значительно меньше времени и сил тратим на обсуждения, почему что-то не получилось и в какие сроки мы что-то можем или не можем сделать. Все шаги и сроки прозрачны, в головах у всех одно видение процесса.
Не придется ли через какое-то время всё отменять и внедрять новый фреймворк?
Суть Agile (Канбан и Scrum) в изменениях и постоянной работе над процессами. Изменения — это просто часть работы.
А, ну и момент по встречам — зачем их переименовывать и т.п.?
Когда работаешь с группой людей необходимо установить общее понятийное поле. Можно изобрести свой словарь, а можно взять готовый. Идем в Канбан — берем словарь Канбан, там все написано и можно сверить свое понимание.
Я упомянула про смену названий в контексте того, что бывают настоящие изменения, а есть просто смена названий. Смена названия сама по себе не поменяет содержание.