Комментарии 9
Анастасия, добрый день.
Заинтересовал график Retro AI.
Какого рода задачи заводятся после ретроспективы?
Всё ли после ретроспективы оформляется в задачи? По моему опыту - чаще всего с ретроспектив мы выходим с некоторыми договорённостями, которые надо поддерживать, а не выполнять как разовую задачу. Или у вас какие-то технические ретроспективы?
Если todo после ретры не пополняется - это плохо? Это не показатель того, что в данный момент всё хорошо и нет причин для значимых перемен?
Здравствуйте, по выводам с ретроспективы согласна, что часто это бывают договоренности, и их не всегда можно сформулировать в виде задач. В таком случае мы их просто фиксируем в документации, потому что, что не зафиксировано - того не было :)
И даже для договоренностей мы стараемся выносить именно Action Item, где это возможно. Следование договоренности в течение первого спринта - тоже может быть задачей, но без веса в SP. Будет удобно видеть на доске таск с напоминанием, а в конце спринта оценить, удалось ли нам следовать тому, о чем мы договорились, и закрыть задачу.
Или у вас какие-то технические ретроспективы?
Не скажу, что у нас именно технические ретроспективы, но при этом решения часто могут быть техническими: создание какой-то автоматизации, бота в слаке, описание того, что плохо описано, проведение мини-исследования и т.д. То есть в целом на ретроспективе мы держим в фокусе вопрос «Какие шаги мы будем предпринимать, чтобы это улучшить?». Также Action Item может быть встреча с заказачиком или синк со смежной командой. Еще на нашей практике хорошо работает выделение ответственных внутри команды: то есть ответственный не обязан делать задачу сам, но должен будет заменджерить ее решение - это повышает процент выполнения action item.
Надеюсь, удалось ответить на ваш вопрос?)
Если todo после ретры не пополняется - это плохо?
При наших процессах - это плохо и может значить, что мы не делаем шаги к улучшениям, которые мы выделили. Либо другой вариант - мы выделили неправильную проблему или пути ее решения, поэтому команда не считает нужным брать задачи с ретро в спринт и реализовывать, т.к. не видит пользы.
Какую шкалу стори-поинтов вы используете? (количество и распределение элементов - степени двойки, числа Фиббоначи etc)
Используете ли golden story? Другими словами, есть ли зафиксированная история с неким количеством SP, чтобы команды на грумингах говорили "история A вполовину проще эталонной, а история B в четыре раза сложнее"?
Когда команды дают оценку в SP, что в нее вкладывают?
• трудоемкость в time units (вплоть до "идеальных человекодней"),
• риски недооцененности "непонятно, как это делать - может вырасти в два раза",
• риски простоев "может ждать другую команду, ответ от бизнеса, maintenance window etc"
Какие разбросы по cycle time внутри отдельных типов задач? Другими словами, насколько пессимистичен 85-й перцентиль?
Насколько длинные бэклоги команд (в количестве задач и в спринтах по текущей velocity)?
Здравствуйте! У нас каждая команда сама для себя устанавливает шкалу оценки в стори-поинтах, как ей удобно. Аналогично с golden story: у кого-то есть, у кого-то нет.
У нас нет задачи прийти к единой шкале для всех команд, это будет очень ресурсозатратно: нужно будет выравнивать по сложности все задачи относительно друг друга, для чего нужно понимание предметной области всех задач. Тут встаёт вопрос, например, как сравнить между собой задачи про фронту, бэку, дизайну и аналитике :)
Да и у нас нет такой цели. Мы ни в коем случае не сравниваем команды по velocity, потому что это относительная величина, и она нужна только для помощи в планировании каждой конкретной команде.
Когда команды дают оценку в SP, что в нее вкладывают?
Я придерживаюсь оценки в story points как относительной сложности задачи, вне зависимости от того, кто ее будет делать: опытный сотрудник или новичок. Для меня это кажется более простым и эффективным. У нас есть команды, которые оценивают задачи в человеко-часах, их относительно мало, но при этом они тоже пользуются инструментом, там есть простой переключатель для оценки.
риски недооцененности "непонятно, как это делать - может вырасти в два раза"
Если задача неопределенная, то на нашей практике мы стараемся создавать отдельный таск на исследование, чтобы получить больше ясности, потом снова грумим задачу и после этого берем ее в спринт. Бывает такое, что мы уверены в себе и думаем, что и исследование, и реализацию сможем сделать за один спринт, то тогдат мы правда немного увеличиваем оценку из-за неопределенности, но какого-то правила на это у нас нет.
риски простоев "может ждать другую команду, ответ от бизнеса, maintenance window etc"
Если задача не может быть выполнена из-за блокера, то мы просто ставим задачу в статус blocked, указываем задачу, которая ее блокирует, и не берем в работу, пока блокер не будет устранен. На оценку задачи это никак не влияет, так как сложность устранения блокера - это оценка блокирующей задачи.
Если ждем ответ от бизнеса - то для нас это никак не добавляет сложности в реализации)
Какие разбросы по cycle time внутри отдельных типов задач? Другими словами, насколько пессимистичен 85-й перцентиль
На самом деле разброс достаточно большой, потому что часто несколько задач делаются одновременно одним человчеком, мы не фиксируем точное количество часов, которые потратили на задачу. Так что это для нас скорее ориентир, чтобы можно было выявить задачи, которые решаются слишком долго, например. Или для понимания заказчиков, сколько примерно будет выполняться задача, если мы сейчас возьмем ее в работу - в этом случае лучше сказать большую длительность и перестраховаться, чем меньшую и не уложиться в срок.
Насколько длинные бэклоги команд (в количестве задач и в спринтах по текущей velocity)
А вот на этот вопрос мне сложно ответить :) разброс по командам очень большой, зависит от процессов. Команда может сама создавать бэклог со своим продукт-оунером, или бэклог может формироваться заказчиками, а приоритизироваться уже вместе с командой. Мы здесь тоже не устанавливаем никаких правил, команды работают, как им удобно. Мы от себя даем только рекомендацию, чтобы были прогрумлены задачи минимум на 2 спринта вперед
Если остались еще какие-то вопросы, то буду рада ответить)
каждая команда сама для себя устанавливает шкалу оценки в стори-поинтах, как ей удобно
Может быть, какие-нибудь команды смогут поделиться принципами, по которым они выбирали и калибровали свою шкалу? Если они сложнее, чем "взяли случайную, понравилось", конечно. Использование story points зачастую связано с операцией сложения (да хотя бы velocity), и мне кажется, что шкала может сильно влиять на результаты. Я знаю пример, в котором 3 <> 1 + 2 <> 1 + 1 + 1 - в результате velocity осциллировала аки хвост трясогузки, и о предсказуемости не могло идти и речи
Согласен, сравнивать шкалы и скорости команд между собой - крайне скользкая дорожка. Более того, шкала одной и той же команды из 2021 и из 2022 года уже могут значительно отличаться. Переоценка важна - меняются задачи, меняется состав команды, появляются новые скиллы
Я придерживаюсь оценки в story points как относительной сложности задачи
"Да кто такая эта ваша сложность нафиг?" :) Мы так и не нашли ответа на этот вопрос. Сопоставить миллион человеческих профилей между Excel-файлом и БД - это сложно? А ускорить систему в два раза? А пробросить поле через 7 сервисов разной степени "микровости" и разными процессами разработки и релизов? А раскатить новую функциональность, опробованную на небольшой группе любителей bleeding edge, на 1000 клиентов из 10 стран ("пфф, кнопку нажал, и готово", или "когда все может пойти не так")? Опять же, чем крупнее задачи в спринте, тем меньше будет пользы от эффекта "где-то недооценили, где-то переоценили - в итоге само выровнялось"
На самом деле разброс (cycle time по типам задач) достаточно большой
Тогда вопрос - почему текущий набор типов задач именно такой, и были ли мысли его пересмотреть на основе кластеризации по cycle time? Или из-за невысокой точности этой метрики пользы также будет немного?
разброс (длин бэклогов) по командам очень большой, зависит от процессов
Нет ли команд, у которых в бэклоге задач на год вперед? Как они к этому относятся, нет ли ощущения "мы никогда это не сделаем"?
Initial Scope Drop
Бывает ли (и как часто) "отрицательный scope drop" (когда команда была слишком пессимистична на планировании)?
Да, работа проделана крутая, получилось красиво и мощно. Но если бы я был заказчиком этой работы, меня бы результат
Тимлиды, юнит-лиды и аналитики могут оценить по графикам общую картину продуктивности команд, увидеть проблемные места и скорректировать рабочий процесс. Сами команды смотрят на график Velocity, чтобы при планировании следующего спринта понимать, какую нагрузку они могут взять.
не устроил. И вот почему:
в статье написано, какая крутая работа была проделана, но не показан интересный бизнесу результат. Смотреть графики - прикольно, но надо повышенную предсказуемость. Вот как она изменилась?
Bug policy: баг багу рознь. Мне как заказчику не очень интересно, насколько быстро команда баги закрывает. Гораздо интереснее, какие из багов заметили клиенты и как они повлияли на бизнес-метрики. Если релиз выходит с большим количеством багов, которые клиенты не замечают и клиентам они не вредят и метрики не падают, то и славно. Можно потом неспешно их поправить. Просто замечу, что в своё время Chrysler (если память мне не изменяет) закрытие своих заводов начал с завода-победителя соревнования по внутренней эффективности. Соответствие bug policy - это внутренняя (!) эффективность.
А так работа крутая. Пойду с инженерами нашими обсуждать, что можно из этого хорошего перенять.
в статье написано, какая крутая работа была проделана, но не показан интересный бизнесу результат. Смотреть графики - прикольно, но надо повышенную предсказуемость. Вот как она изменилась?
Я на самом деле думала про расчет какой-нибудь супер-метрики эффективности для инструмента. Столкнулась с тем, что кроме этого дашборда на velocity команды влияет очень много факторов, и я не могу при расчете метрики как-то исключить их влияние. Например, после ретро команда решила иначе оценивать таски, кто-то из команды заболел или ушел в отпуск, произошел инцидент, поменялся процесс, команда тратит время на погружения новичка - и много чего такого может происходить. Если есть идеи, как можно бы было это сделать - то я буду рада их обсудить) при первом подходе не придумала)
Поэтому я решила оценивать эффективность на стандартных метриках: просмотры, действия, уникальные юзеры, отток и т.д.
Ну и в результате заказчик был доволен, потому что этот инструмент давно хотели, им начали активно польоваться, и есть позитивная обратная связь. Также потребность была в прозрачности, а тут мы покрыли большинство команд разработки.
Мне как заказчику не очень интересно, насколько быстро команда баги закрывает. Гораздо интереснее, какие из багов заметили клиенты и как они повлияли на бизнес-метрики. Если релиз выходит с большим количеством багов, которые клиенты не замечают и клиентам они не вредят и метрики не падают, то и славно. Можно потом неспешно их поправить.
Я рада, что вы задали этот вопрос :) я решила в статье детально не рассказывать про приоритет багов, потому что достаточно специфичная наша тема, а тут могу это сделать) У нас приоритет бага как раз определяется по числу пользователей, которые с ним столкнулись и по частоте воспроизведения (это 2 оси для оценки приоритета). И в зависимости от критичности бага у него будет SLA на время устранения (чем выше приоритет, тем быстрее должен быть устранен), этот график как раз есть на дашборде. А влияние на бизнес мы оцениваем после закрытия инцидента, разбирая, что пошло не так и как можно избежать этого в дальнейшем.
Так что внутреннюю эффективность мы стараемся приближать к нашим бизнес-метрикам. Хотя это инструмент все же больше не для заказчиков, а для команд разработки
Спасибо, очень интересный материал!
Cycle Time в динамике не отслеживаете? Какую глубину задач используете для подсчёта Cycle Time?
Здравствуйте, Анастасия. Прошло довольно много времени. Интересно узнать быть может в нескольких предложениях.
Пользуетесь ли до сих пор этим?
Что-оказалось лишним, что обрезали, или наоборот докрутили?
Свой инструмент в Tableau для scrum-команд с Bug Policy и Scope Drop