в статье написано, какая крутая работа была проделана, но не показан интересный бизнесу результат. Смотреть графики - прикольно, но надо повышенную предсказуемость. Вот как она изменилась?
Я на самом деле думала про расчет какой-нибудь супер-метрики эффективности для инструмента. Столкнулась с тем, что кроме этого дашборда на velocity команды влияет очень много факторов, и я не могу при расчете метрики как-то исключить их влияние. Например, после ретро команда решила иначе оценивать таски, кто-то из команды заболел или ушел в отпуск, произошел инцидент, поменялся процесс, команда тратит время на погружения новичка - и много чего такого может происходить. Если есть идеи, как можно бы было это сделать - то я буду рада их обсудить) при первом подходе не придумала) Поэтому я решила оценивать эффективность на стандартных метриках: просмотры, действия, уникальные юзеры, отток и т.д.
Ну и в результате заказчик был доволен, потому что этот инструмент давно хотели, им начали активно польоваться, и есть позитивная обратная связь. Также потребность была в прозрачности, а тут мы покрыли большинство команд разработки.
Мне как заказчику не очень интересно, насколько быстро команда баги закрывает. Гораздо интереснее, какие из багов заметили клиенты и как они повлияли на бизнес-метрики. Если релиз выходит с большим количеством багов, которые клиенты не замечают и клиентам они не вредят и метрики не падают, то и славно. Можно потом неспешно их поправить.
Я рада, что вы задали этот вопрос :) я решила в статье детально не рассказывать про приоритет багов, потому что достаточно специфичная наша тема, а тут могу это сделать) У нас приоритет бага как раз определяется по числу пользователей, которые с ним столкнулись и по частоте воспроизведения (это 2 оси для оценки приоритета). И в зависимости от критичности бага у него будет SLA на время устранения (чем выше приоритет, тем быстрее должен быть устранен), этот график как раз есть на дашборде. А влияние на бизнес мы оцениваем после закрытия инцидента, разбирая, что пошло не так и как можно избежать этого в дальнейшем.
Так что внутреннюю эффективность мы стараемся приближать к нашим бизнес-метрикам. Хотя это инструмент все же больше не для заказчиков, а для команд разработки
Здравствуйте! У нас каждая команда сама для себя устанавливает шкалу оценки в стори-поинтах, как ей удобно. Аналогично с golden story: у кого-то есть, у кого-то нет. У нас нет задачи прийти к единой шкале для всех команд, это будет очень ресурсозатратно: нужно будет выравнивать по сложности все задачи относительно друг друга, для чего нужно понимание предметной области всех задач. Тут встаёт вопрос, например, как сравнить между собой задачи про фронту, бэку, дизайну и аналитике :)
Да и у нас нет такой цели. Мы ни в коем случае не сравниваем команды по velocity, потому что это относительная величина, и она нужна только для помощи в планировании каждой конкретной команде.
Когда команды дают оценку в SP, что в нее вкладывают?
Я придерживаюсь оценки в story points как относительной сложности задачи, вне зависимости от того, кто ее будет делать: опытный сотрудник или новичок. Для меня это кажется более простым и эффективным. У нас есть команды, которые оценивают задачи в человеко-часах, их относительно мало, но при этом они тоже пользуются инструментом, там есть простой переключатель для оценки.
риски недооцененности "непонятно, как это делать - может вырасти в два раза"
Если задача неопределенная, то на нашей практике мы стараемся создавать отдельный таск на исследование, чтобы получить больше ясности, потом снова грумим задачу и после этого берем ее в спринт. Бывает такое, что мы уверены в себе и думаем, что и исследование, и реализацию сможем сделать за один спринт, то тогдат мы правда немного увеличиваем оценку из-за неопределенности, но какого-то правила на это у нас нет.
риски простоев "может ждать другую команду, ответ от бизнеса, maintenance window etc"
Если задача не может быть выполнена из-за блокера, то мы просто ставим задачу в статус blocked, указываем задачу, которая ее блокирует, и не берем в работу, пока блокер не будет устранен. На оценку задачи это никак не влияет, так как сложность устранения блокера - это оценка блокирующей задачи. Если ждем ответ от бизнеса - то для нас это никак не добавляет сложности в реализации)
Какие разбросы по cycle time внутри отдельных типов задач? Другими словами, насколько пессимистичен 85-й перцентиль
На самом деле разброс достаточно большой, потому что часто несколько задач делаются одновременно одним человчеком, мы не фиксируем точное количество часов, которые потратили на задачу. Так что это для нас скорее ориентир, чтобы можно было выявить задачи, которые решаются слишком долго, например. Или для понимания заказчиков, сколько примерно будет выполняться задача, если мы сейчас возьмем ее в работу - в этом случае лучше сказать большую длительность и перестраховаться, чем меньшую и не уложиться в срок.
Насколько длинные бэклоги команд (в количестве задач и в спринтах по текущей velocity)
А вот на этот вопрос мне сложно ответить :) разброс по командам очень большой, зависит от процессов. Команда может сама создавать бэклог со своим продукт-оунером, или бэклог может формироваться заказчиками, а приоритизироваться уже вместе с командой. Мы здесь тоже не устанавливаем никаких правил, команды работают, как им удобно. Мы от себя даем только рекомендацию, чтобы были прогрумлены задачи минимум на 2 спринта вперед
Если остались еще какие-то вопросы, то буду рада ответить)
Здравствуйте, по выводам с ретроспективы согласна, что часто это бывают договоренности, и их не всегда можно сформулировать в виде задач. В таком случае мы их просто фиксируем в документации, потому что, что не зафиксировано - того не было :)
И даже для договоренностей мы стараемся выносить именно Action Item, где это возможно. Следование договоренности в течение первого спринта - тоже может быть задачей, но без веса в SP. Будет удобно видеть на доске таск с напоминанием, а в конце спринта оценить, удалось ли нам следовать тому, о чем мы договорились, и закрыть задачу.
Или у вас какие-то технические ретроспективы?
Не скажу, что у нас именно технические ретроспективы, но при этом решения часто могут быть техническими: создание какой-то автоматизации, бота в слаке, описание того, что плохо описано, проведение мини-исследования и т.д. То есть в целом на ретроспективе мы держим в фокусе вопрос «Какие шаги мы будем предпринимать, чтобы это улучшить?». Также Action Item может быть встреча с заказачиком или синк со смежной командой. Еще на нашей практике хорошо работает выделение ответственных внутри команды: то есть ответственный не обязан делать задачу сам, но должен будет заменджерить ее решение - это повышает процент выполнения action item.
Надеюсь, удалось ответить на ваш вопрос?)
Если todo после ретры не пополняется - это плохо?
При наших процессах - это плохо и может значить, что мы не делаем шаги к улучшениям, которые мы выделили. Либо другой вариант - мы выделили неправильную проблему или пути ее решения, поэтому команда не считает нужным брать задачи с ретро в спринт и реализовывать, т.к. не видит пользы.
Я на самом деле думала про расчет какой-нибудь супер-метрики эффективности для инструмента. Столкнулась с тем, что кроме этого дашборда на velocity команды влияет очень много факторов, и я не могу при расчете метрики как-то исключить их влияние. Например, после ретро команда решила иначе оценивать таски, кто-то из команды заболел или ушел в отпуск, произошел инцидент, поменялся процесс, команда тратит время на погружения новичка - и много чего такого может происходить. Если есть идеи, как можно бы было это сделать - то я буду рада их обсудить) при первом подходе не придумала)
Поэтому я решила оценивать эффективность на стандартных метриках: просмотры, действия, уникальные юзеры, отток и т.д.
Ну и в результате заказчик был доволен, потому что этот инструмент давно хотели, им начали активно польоваться, и есть позитивная обратная связь. Также потребность была в прозрачности, а тут мы покрыли большинство команд разработки.
Я рада, что вы задали этот вопрос :) я решила в статье детально не рассказывать про приоритет багов, потому что достаточно специфичная наша тема, а тут могу это сделать) У нас приоритет бага как раз определяется по числу пользователей, которые с ним столкнулись и по частоте воспроизведения (это 2 оси для оценки приоритета). И в зависимости от критичности бага у него будет SLA на время устранения (чем выше приоритет, тем быстрее должен быть устранен), этот график как раз есть на дашборде. А влияние на бизнес мы оцениваем после закрытия инцидента, разбирая, что пошло не так и как можно избежать этого в дальнейшем.
Так что внутреннюю эффективность мы стараемся приближать к нашим бизнес-метрикам. Хотя это инструмент все же больше не для заказчиков, а для команд разработки
Здравствуйте! У нас каждая команда сама для себя устанавливает шкалу оценки в стори-поинтах, как ей удобно. Аналогично с golden story: у кого-то есть, у кого-то нет.
У нас нет задачи прийти к единой шкале для всех команд, это будет очень ресурсозатратно: нужно будет выравнивать по сложности все задачи относительно друг друга, для чего нужно понимание предметной области всех задач. Тут встаёт вопрос, например, как сравнить между собой задачи про фронту, бэку, дизайну и аналитике :)
Да и у нас нет такой цели. Мы ни в коем случае не сравниваем команды по velocity, потому что это относительная величина, и она нужна только для помощи в планировании каждой конкретной команде.
Я придерживаюсь оценки в story points как относительной сложности задачи, вне зависимости от того, кто ее будет делать: опытный сотрудник или новичок. Для меня это кажется более простым и эффективным. У нас есть команды, которые оценивают задачи в человеко-часах, их относительно мало, но при этом они тоже пользуются инструментом, там есть простой переключатель для оценки.
Если задача неопределенная, то на нашей практике мы стараемся создавать отдельный таск на исследование, чтобы получить больше ясности, потом снова грумим задачу и после этого берем ее в спринт. Бывает такое, что мы уверены в себе и думаем, что и исследование, и реализацию сможем сделать за один спринт, то тогдат мы правда немного увеличиваем оценку из-за неопределенности, но какого-то правила на это у нас нет.
Если задача не может быть выполнена из-за блокера, то мы просто ставим задачу в статус blocked, указываем задачу, которая ее блокирует, и не берем в работу, пока блокер не будет устранен. На оценку задачи это никак не влияет, так как сложность устранения блокера - это оценка блокирующей задачи.
Если ждем ответ от бизнеса - то для нас это никак не добавляет сложности в реализации)
На самом деле разброс достаточно большой, потому что часто несколько задач делаются одновременно одним человчеком, мы не фиксируем точное количество часов, которые потратили на задачу. Так что это для нас скорее ориентир, чтобы можно было выявить задачи, которые решаются слишком долго, например. Или для понимания заказчиков, сколько примерно будет выполняться задача, если мы сейчас возьмем ее в работу - в этом случае лучше сказать большую длительность и перестраховаться, чем меньшую и не уложиться в срок.
А вот на этот вопрос мне сложно ответить :) разброс по командам очень большой, зависит от процессов. Команда может сама создавать бэклог со своим продукт-оунером, или бэклог может формироваться заказчиками, а приоритизироваться уже вместе с командой. Мы здесь тоже не устанавливаем никаких правил, команды работают, как им удобно. Мы от себя даем только рекомендацию, чтобы были прогрумлены задачи минимум на 2 спринта вперед
Если остались еще какие-то вопросы, то буду рада ответить)
Здравствуйте, по выводам с ретроспективы согласна, что часто это бывают договоренности, и их не всегда можно сформулировать в виде задач. В таком случае мы их просто фиксируем в документации, потому что, что не зафиксировано - того не было :)
И даже для договоренностей мы стараемся выносить именно Action Item, где это возможно. Следование договоренности в течение первого спринта - тоже может быть задачей, но без веса в SP. Будет удобно видеть на доске таск с напоминанием, а в конце спринта оценить, удалось ли нам следовать тому, о чем мы договорились, и закрыть задачу.
Не скажу, что у нас именно технические ретроспективы, но при этом решения часто могут быть техническими: создание какой-то автоматизации, бота в слаке, описание того, что плохо описано, проведение мини-исследования и т.д. То есть в целом на ретроспективе мы держим в фокусе вопрос «Какие шаги мы будем предпринимать, чтобы это улучшить?». Также Action Item может быть встреча с заказачиком или синк со смежной командой. Еще на нашей практике хорошо работает выделение ответственных внутри команды: то есть ответственный не обязан делать задачу сам, но должен будет заменджерить ее решение - это повышает процент выполнения action item.
Надеюсь, удалось ответить на ваш вопрос?)
При наших процессах - это плохо и может значить, что мы не делаем шаги к улучшениям, которые мы выделили. Либо другой вариант - мы выделили неправильную проблему или пути ее решения, поэтому команда не считает нужным брать задачи с ретро в спринт и реализовывать, т.к. не видит пользы.