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