Чья мотивация?

А какие критерии были?

Вариант 1: чистая прибыль от продукта в горизонте года Так себе история, так как тут огромная роль РО Вариант 2: SP в месяц

Sp в месяц тоже так себе метрика :)

Ещё бы, у всех тут же случился мега-рост... На бумаге

мерять по успеху продукта очень тяжело - очень часто команда не отвечает именно за успех продукта.

Вариант 3: число US Вообще неудачно, на техдолг и сложные технически истории стали забивать

Вариант 4: time to market Самый приемлемый из всех, но хакается мега-дроблением задач и качество работы оставляет за скобками. Плюс технически сложные продукты всегда в отстающих. Тоже не айс

В общем, не видела удачного примера😒

мерять по успеху продукта очень тяжело - очень часто команда не отвечает именно за успех продукта.

Именно, атмосфера стала очень нездоровой за месяц

Вариант 4: time to market Самый приемлемый из всех, но хакается мега-дроблением задач и качество работы оставляет за скобками. Плюс технически сложные продукты всегда в отстающих. Тоже не айс

t2m - метрика, которая тяжело хакается, но она часто не от команды зависит.

Какая разница, какой у теюя t2m, если 90% этого времени PBI просто в очереди в релиз висит.

Я потому и предлагал lead time и cycle time мерять рядом.

lead time показывает эффективность всей производственной системы, cycle time - конкретно производства.

Да, я попробую посчитать по своим командам. Но мне кажется, что в рамках компании все равно не особо корректно: есиь объективно более простые и более сложные технически проекты

Хотя предпочла бы чтобы команды не оценивали вообще. Хоть это и неправильно с точки зрения бизнеса

Хотя предпочла бы чтобы команды не оценивали вообще. Хоть это и неправильно с точки зрения бизнеса

Татьяна, спасибо за хорошую тему и отличное обсуждение. И Павлу большое спасибо, и всем участникам! Лишний раз ваш опыт подтверждает мой - метрики команды либо легко хакаются, либо включают факторы вне команды. Конечно, правильная команда форматирует под себя и окружающую среду тоже, но до этого состояния ей ещё надо дорасти... На мой взгляд, команда лучше всего «меряется» по cycle time + субъективному довольству владельца продукта. Различные синтетические метрики здоровья спринта - это вряд ли про «эффективность», это именно про процесс. И они больше имеют смысл для наблюдения за ними на протяжении нескольких спринтов в 1 команде, чем как сравнительная метрика «у этих хорошо, а у тех не очень».

Татьяна, спасибо за хорошую тему и отличное обсуждение. И Павлу большое спасибо, и всем участникам! Лишний раз ваш опыт подтверждает мой - метрики команды либо легко хакаются, либо включают факторы вне команды. Конечно, правильная команда форматирует под себя и окружающую среду тоже, но до этого состояния ей ещё надо дорасти... На мой взгляд, команда лучше всего «меряется» по cycle time + субъективному довольству владельца продукта. Различные синтетические метрики здоровья спринта - это вряд ли про «эффективность», это именно про процесс. И они больше имеют смысл для наблюдения за ними на протяжении нескольких спринтов в 1 команде, чем как сравнительная метрика «у этих хорошо, а у тех не очень».

Спасибо за спасибо:) Согласна с вами.

Татьяна, спасибо за хорошую тему и отличное обсуждение. И Павлу большое спасибо, и всем участникам! Лишний раз ваш опыт подтверждает мой - метрики команды либо легко хакаются, либо включают факторы вне команды. Конечно, правильная команда форматирует под себя и окружающую среду тоже, но до этого состояния ей ещё надо дорасти... На мой взгляд, команда лучше всего «меряется» по cycle time + субъективному довольству владельца продукта. Различные синтетические метрики здоровья спринта - это вряд ли про «эффективность», это именно про процесс. И они больше имеют смысл для наблюдения за ними на протяжении нескольких спринтов в 1 команде, чем как сравнительная метрика «у этих хорошо, а у тех не очень».

Андрей, добрый день. Большое спасибо за развернутое, аргументированное мнение.

Друзья, привет! Есть вопрос, кому-то он может показаться странным. Есть спринт=итерация, есть релизы. Вопрос: должен ли релиз происходить в день окончания спинта? Или мы можем в один релиз уложить несколько спринтов? Какие взаимосвязи?

Друзья, привет! Есть вопрос, кому-то он может показаться странным. Есть спринт=итерация, есть релизы. Вопрос: должен ли релиз происходить в день окончания спинта? Или мы можем в один релиз уложить несколько спринтов? Какие взаимосвязи?

релизы никак со спринтами не связаны

Не связаны они.

спасибо, а то меня клинить начало немного..

Релизьтесь по Требованию

чем чаще релизитесь тем лучше

спасибо, а то меня клинить начало немного..

Многих клинит. Ничего страшного :)

кстати, чтобы можно было аргументировать Продакту: это прописано где-гибудь?

CI/CD

Желательно после каждого, в этом случае у тебя бизнес будет получать ценность после итерации сразу же. Но! не обязательно. CI/CD ускоряют

А как же спринт релиз?🕶

А как же спринт релиз?🕶

что7

что7

Алексей, кстати, вопрос: в какой день лучше всего делать релиз?

В пятницу, в 17.00

В пятницу, в 17.00

👍

Алексей, кстати, вопрос: в какой день лучше всего делать релиз?

Лучше когда релизы выходят 2 раза в день :)

Лучше когда релизы выходят 2 раза в день :)

Yep

Алексей, кстати, вопрос: в какой день лучше всего делать релиз?

Лучше всего во вторник.

В пятницу, в 17.00

аж сердце екнуло😁

Лучше всего во вторник.

Павел, you are welcome))

Желательно после каждого, в этом случае у тебя бизнес будет получать ценность после итерации сразу же. Но! не обязательно. CI/CD ускоряют

я просто сейчас столкнулас с ситуацией в команде, где в Джира нет спринтов, но есть двухнедельные итерации, заканчивающиеся релизом. Хочу объяснить, что спринта да, две недели, а релиз не обязательно

с другой стороны, если по результату спринта должен быть бизнес-результат, наверное просто релиз=спринт — идеальная картина

и правильно я понимаю, что в релиз могут пойти фичи из разных спринтов

я просто сейчас столкнулас с ситуацией в команде, где в Джира нет спринтов, но есть двухнедельные итерации, заканчивающиеся релизом. Хочу объяснить, что спринта да, две недели, а релиз не обязательно

"не обязательно" это в конетксте фреймворка. В контексте бизнес-процессов - почему бу и нет?

Коллеги, всем привет! Можете посоветовать хорошие курсы по kanban? Работаю в крупной транспортной компании, нужно внедрить управление операционной по kanban

с другой стороны, если по результату спринта должен быть бизнес-результат, наверное просто релиз=спринт — идеальная картина

Идеально спринт=несколько релизов

Идеально спринт=несколько релизов

а что делать с DEMO. Вдруг не то?

а что делать с DEMO. Вдруг не то?

Делать обзор спринта. Демо может быть его частью, а может и отсутствовать вообще

Идеально спринт=несколько релизов

а в чем преимущество такой "идеальной" модели?

ээ можно я не буду отвечать на э тот вопрос? :) просто человек озвучил свое идеальное представление, я пытаюсь понять почему =) и подойдет ли она для меня например :) идеально это хорошо, только без контекста причинно-следственных связей - не очень полезная инфа

ээ можно я не буду отвечать на э тот вопрос? :) просто человек озвучил свое идеальное представление, я пытаюсь понять почему =) и подойдет ли она для меня например :) идеально это хорошо, только без контекста причинно-следственных связей - не очень полезная инфа

👍

Если хочется релизиться чаще чем в конце спринта, то, по моему лучше смотреть в сторону Канбана, а Скрам же предполагает релиз после демо и принятия выполненной цели спринта со стороны PO. Нет?

Если хочется релизиться чаще чем в конце спринта, то, по моему лучше смотреть в сторону Канбана, а Скрам же предполагает релиз после демо и принятия выполненной цели спринта со стороны PO. Нет?

Нет

Читайте гайд. Там про релизы вообще ни слова. Равно как и про демо

Зато там про цели спринта.

Зато там про цели спринта.

для достижения цели, могут потребоваться релизы каждый день например. или несколько раз в день. или вообще ни одного релиза ... scrum guide ваще про релизы ничего не говорит, поддерживаю предыдущего оратора

Читайте гайд. Там про релизы вообще ни слова. Равно как и про демо

а по поводу идеала 1 спринт = несколько релизов, расскажите чем это лучше 1 спринт = 1 релиз? или это просто ваши субъективные ощущения?

а по поводу идеала 1 спринт = несколько релизов, расскажите чем это лучше 1 спринт = 1 релиз? или это просто ваши субъективные ощущения?

тем что для поставки ценности конечному пользователю вам не приходится ждать окончания каденции

ИМХО релизы больше зависят от специфики продукта и самого понятия релиза, чем от процесса.

Релизы завися только от вашего умения релизить. Необходимость развивать это умение зависит уже от контекста

например, мы не можем релизить ios приложение в apple store несколько раз в день из-за специфики платформы

для достижения цели, могут потребоваться релизы каждый день например. или несколько раз в день. или вообще ни одного релиза ... scrum guide ваще про релизы ничего не говорит, поддерживаю предыдущего оратора

Может потребоваться, согласен. Вопрос как вы будете в процессе верифицировать цель снпринта и результат с PO. Практика релизов внутри спринта тогда должна предполагать механизмы такой верификации. Это усложняет процесс либо добавляет рисков.

чтобы вести подобный разговор, думаю стоит определиться с тем, что мы называем релизом?

тем что для поставки ценности конечному пользователю вам не приходится ждать окончания каденции

разработка одновременно в двух релизах - дополнительные накладные расходны на переключения, поэтому для меня идеальная картина несколько другая - итог спринта - релиз, который потенциально можно поставить - когда решает бизнес, но команда синхронно переключается на новый спринт с новой целью и работает над одним инкрементом, фокусируясь на нем. Хотя допускаю что в каких то случаях критичнее выпустить релиз в середине спринта, если процессы настолько зрелые, что успевают обеспечить качественный инкремент до окончания спринта

разработка одновременно в двух релизах - дополнительные накладные расходны на переключения, поэтому для меня идеальная картина несколько другая - итог спринта - релиз, который потенциально можно поставить - когда решает бизнес, но команда синхронно переключается на новый спринт с новой целью и работает над одним инкрементом, фокусируясь на нем. Хотя допускаю что в каких то случаях критичнее выпустить релиз в середине спринта, если процессы настолько зрелые, что успевают обеспечить качественный инкремент до окончания спринта

дополнительные расходы означают несовершенство ваших процессов, а не нежелание пользователей получать по фиче в час

разработка одновременно в двух релизах - дополнительные накладные расходны на переключения, поэтому для меня идеальная картина несколько другая - итог спринта - релиз, который потенциально можно поставить - когда решает бизнес, но команда синхронно переключается на новый спринт с новой целью и работает над одним инкрементом, фокусируясь на нем. Хотя допускаю что в каких то случаях критичнее выпустить релиз в середине спринта, если процессы настолько зрелые, что успевают обеспечить качественный инкремент до окончания спринта

Как понять одновременно в двух релизах?

дополнительные расходы означают несовершенство ваших процессов, а не нежелание пользователей получать по фиче в час

пусть будет так ) хотя конкретно у меня таких задач бизнес не ставит и пользователи не готовы получать по новой фиче в час, у вас именно такая ситуация? интересно было бы узнать опыт, и как получилось выстроить процессы для обеспечения Continious Dilivery.

пусть будет так ) хотя конкретно у меня таких задач бизнес не ставит и пользователи не готовы получать по новой фиче в час, у вас именно такая ситуация? интересно было бы узнать опыт, и как получилось выстроить процессы для обеспечения Continious Dilivery.

у нас есть разные команды в разных контекстах

Всем добрый день! #Job #OSAHP #ProjectManager #Scrum #Agile Www.osahp.com OSA DC is a decentralized, AI-driven blockchain platform that collects and analyzes data from retailers, manufacturers, consumers, and open data sources in real-time ROLE · Work closely with the business throughout the project (Token Sales) · Manage project lifecycle using agile methodology/kanban · Oversee and motivate the team, organise their work load and manage any issues. · Run daily scrum meetings, project reviews PERSON SPECIFICATION · Minimum of 2 years' experience as a Project Manager/Scrum master · Solid experience of working in a digital area (ICO is a plus, but not required) · In-depth knowledge and experience of managing high profile international projects; preferably within an agile working environment. · Ability to work under pressure and deal with a demanding workload · Very strong interpersonal skills, including the ability to negotiate and to build and maintain good working relationships both internally and externally, up to and including senior management. To apply - i.ladyko@osahp.com

Как понять одновременно в двух релизах?

если процесс предполагает ручное тестирование (у нас он предполагает), значит нужно время на это тестирование и чтобы обезопасить от регрессионных ошибок, если принимается решение о выпуске релиза в середине спринта, то для нас это значит отсаживать ветку и новые фичи делать уже в новой ветке, а в старой только править ошибки - это я имел в виду под работой в двух релизах. Если же мы релизим в конце спринта, то проблем распараллелить оставшуюся работу между всеми - меньше.

если процесс предполагает ручное тестирование (у нас он предполагает), значит нужно время на это тестирование и чтобы обезопасить от регрессионных ошибок, если принимается решение о выпуске релиза в середине спринта, то для нас это значит отсаживать ветку и новые фичи делать уже в новой ветке, а в старой только править ошибки - это я имел в виду под работой в двух релизах. Если же мы релизим в конце спринта, то проблем распараллелить оставшуюся работу между всеми - меньше.

ну то есть вы не умеете регрессить и править баги с регресса быстро

(наверное потому, что нет такой необходимости)

если процесс предполагает ручное тестирование (у нас он предполагает), значит нужно время на это тестирование и чтобы обезопасить от регрессионных ошибок, если принимается решение о выпуске релиза в середине спринта, то для нас это значит отсаживать ветку и новые фичи делать уже в новой ветке, а в старой только править ошибки - это я имел в виду под работой в двух релизах. Если же мы релизим в конце спринта, то проблем распараллелить оставшуюся работу между всеми - меньше.

Спасибо, а под релизом вы что имеете в виду? Новую версию вашего продукта?

Master<-test<-dev<-feature?

Мне кажется после ручного уже на мастере, следрвательно уже в релизе нет?

А фича как была на фича так и осталась там

если процесс предполагает ручное тестирование (у нас он предполагает), значит нужно время на это тестирование и чтобы обезопасить от регрессионных ошибок, если принимается решение о выпуске релиза в середине спринта, то для нас это значит отсаживать ветку и новые фичи делать уже в новой ветке, а в старой только править ошибки - это я имел в виду под работой в двух релизах. Если же мы релизим в конце спринта, то проблем распараллелить оставшуюся работу между всеми - меньше.

А не пробовали внедрять инженерные практики ? автотесты? регресс ? парное программирование ? Учить людей это делать?

Ну смотрите, по факту ваша команда разработки становиться зависима от тесировщиков, становится заложниками человеческого фактора и команда разработки в уже не могут работать без тестировщиков.

отвечу чуть позже

Спасибо, а под релизом вы что имеете в виду? Новую версию вашего продукта?

Да дистриб новой версии

Мне кажется после ручного уже на мастере, следрвательно уже в релизе нет?

В мастер льется из редизной ветки, но думаю это уже специфика, ключевое на что хотел обратить внимание, разработка в параллель двух версий

А не пробовали внедрять инженерные практики ? автотесты? регресс ? парное программирование ? Учить людей это делать?

Конечно пробовали и внедряем, но не все рационально покрывать автотестами, часто новый ui после демо может меняться