Сергей, я тебе такой сложный вопрос задам сейчас: а зачем нужны эстимейты?

Пошла философия)

Пошла философия)

Совсем не философия :)

Ну я примерно понимаю куда ты планируешь развивать этот вопрос) а может и не понимаю)

Просто бывает, что есть валидная причина, а бывает, что "мы так привыкли\а как еще спринт планировать" :)

Да можно и без оценки обойтись на опытных командах.

Они и так знают, успеют или нет сторю в Спринт

Ну хз) по мне так эстимейты это waste, который в соответствии с lean подходом надо стремиться ликвидировать. Но как платформа для обучения команды декомпозиции и здоровому обсуждению задач покер планирование заходит хорошо. А так конечно, если понимание механики работы и желаемой гранлярности задач уже достигнуто, лучше переходить к тому же probabilistic forecasting на основе throughput и др Канбан метрик, имхо

Как то писал про метод Майка Кона Capacity Driven Sprint Planing. Это когда берется очередной элемент Бэклога, бьется на таски, оцениваются таски в ЧАСАХ, потом принимается решение и берется следующий элемент. И так пока не наберем полный Спринт. Это по мнению Майка позволяет более точно планировать. Комитмент, мать его ...

Ну хз) по мне так эстимейты это waste, который в соответствии с lean подходом надо стремиться ликвидировать. Но как платформа для обучения команды декомпозиции и здоровому обсуждению задач покер планирование заходит хорошо. А так конечно, если понимание механики работы и желаемой гранлярности задач уже достигнуто, лучше переходить к тому же probabilistic forecasting на основе throughput и др Канбан метрик, имхо

Просто бывает новые люди приходят. Им проще через оценку.

И вообще я на уровне Shu. Не сбивайте меня с пути истинного :)

Сергей, у тебя imposter syndrome. Уровня Ha то ты уже точно достиг мне кажется)

За год? Не. Меня пока еще не посещают мысли нарушать правила. Хотя я много копаю и пытаюсь понять для чего они именно такие. И нахожу удовольствие в этом. А вот когда все пойму, тогда и придет время ...

Я еще столького не знаю, аж дух захватывает!

Да мы уже с Глебкой решили в феврале на КМР I податься) PSK попробую сам чуть позже сдать

Я, кстати, на базовый курс в Эриксоновский универ коучинга записался. В феврале. Если понравится, то на четырех модульный курс двину. Такой вот путь.

Я, кстати, на базовый курс в Эриксоновский универ коучинга записался. В феврале. Если понравится, то на четырех модульный курс двину. Такой вот путь.

Круто! Расскажешь потом)

Я еще столького не знаю, аж дух захватывает!

Павличенко до сих пор то же самое говорит_)) это бесконечная дорога)

Конечно поделюсь.

Павличенко до сих пор то же самое говорит_)) это бесконечная дорога)

Думаю многие с этим согласятся.

Поедешь?:)

на метро 😁

Хехе, я рекомендую считать эти вот поинты на фибоначи - просто уровнями. Т.е. задача на 2 sp не обязательно в два раза сложней задачи на 1 sp, это просто более сложная. 3 sp - еще более сложная, 5 sp - сложней, чем 3 sp.

👍

Я, кстати, на базовый курс в Эриксоновский универ коучинга записался. В феврале. Если понравится, то на четырех модульный курс двину. Такой вот путь.

а я в записи почти первый модуль просмотрел))

Хехе, я рекомендую считать эти вот поинты на фибоначи - просто уровнями. Т.е. задача на 2 sp не обязательно в два раза сложней задачи на 1 sp, это просто более сложная. 3 sp - еще более сложная, 5 sp - сложней, чем 3 sp.

Я собственно тоже (про просто уровни). Но вот Майк с Сергеем возражают =) А насчёт эстимейтов, они нужны для выстраивания ожиданий. Ожидания, в свою очередь, для планирования.

Хотя лучше - ещё проще. Ожидания нужны для принятия решений.

Господа и дамы, реквестирую вашу помощь. Особенно от опытных СМов. Дано: Не Т-шейп команда с разными специалистами (бэк-енд, фронт-энд, QA). Скрама толком никогда не было (была только работа Спринтами). Раньше планировались в часах отдельно на каждого специалиста, сейчас пришли к выводу, что в сроки все равно не попадают и готовы пробовать сторипоинты. Вопрос: Как начать использование сторипоинтов, если у людей на сложность задач и сторей совсем разные оценки и стоит ли вообще в текущем положении пробовать сторипоинты?

Им точно в их проекте необходим Скрам? Другие фреймворки объективно хуже?

Хехе, я рекомендую считать эти вот поинты на фибоначи - просто уровнями. Т.е. задача на 2 sp не обязательно в два раза сложней задачи на 1 sp, это просто более сложная. 3 sp - еще более сложная, 5 sp - сложней, чем 3 sp.

Story Points, кстати, не про сложность =) Обзац Майка не просто так содержит такую строгую трактовку. При обсуждении во сколько раз объем командных усилий будет больше в том или ином PBI команда вытягивает все мелочи и ловит Дьявола в мелочах. И у него (Майка) не слово про ряд Фи, ктсати. При использовании ряда Фибоначчи, естественно, это не работает, так как значения растут быстрее и так точно (по определению Майка), не поместить все задачи и не оценить их. Выбрав Фибоначчи как инструмент для инструмента Story Point, вы стали его применять по другому, относительно Майка ;)

Story Points, кстати, не про сложность =) Обзац Майка не просто так содержит такую строгую трактовку. При обсуждении во сколько раз объем командных усилий будет больше в том или ином PBI команда вытягивает все мелочи и ловит Дьявола в мелочах. И у него (Майка) не слово про ряд Фи, ктсати. При использовании ряда Фибоначчи, естественно, это не работает, так как значения растут быстрее и так точно (по определению Майка), не поместить все задачи и не оценить их. Выбрав Фибоначчи как инструмент для инструмента Story Point, вы стали его применять по другому, относительно Майка ;)

Сложность - это упрощение. Но оно лучше, чем объем, например.

Во, отредактировал с компьютера)

Сложность - это упрощение. Но оно лучше, чем объем, например.

Существует оценка командной сложности задачи?)

Нет, но существует командная оценка солжности задачи :)

Сложность - удобный термин, потому что включает в себя и объем, и неопределенность.

И да, это упрощение концепции сторипоинта.

Хотел написать про запутанность архитектуры при лёгкой и определенной задачке, но увидел последнее сообщение)

окей)

Очень чёткая грань, почему Майк использует "estimate of the overall effort" потому что это именно общие усилия. Что хорошо показывает, когда SP не работают, например -когда в беклоге продукта задачки на конкретных людей в команде =)

Как показывает моя практика, если описывать SP через effort, команда рискует начать оценивать объем :)

Ну, конечно же, нужно ей рассказать, что входит в объем работ, это же не всё определение SP - типа сказал фразу "estimate of the overall effort" и ушёл в закат)

Ну, конечно же, нужно ей рассказать, что входит в объем работ, это же не всё определение SP - типа сказал фразу "estimate of the overall effort" и ушёл в закат)

Увы, да. А было бы неплохо уйти в закат :)

Story Points, кстати, не про сложность =) Обзац Майка не просто так содержит такую строгую трактовку. При обсуждении во сколько раз объем командных усилий будет больше в том или ином PBI команда вытягивает все мелочи и ловит Дьявола в мелочах. И у него (Майка) не слово про ряд Фи, ктсати. При использовании ряда Фибоначчи, естественно, это не работает, так как значения растут быстрее и так точно (по определению Майка), не поместить все задачи и не оценить их. Выбрав Фибоначчи как инструмент для инструмента Story Point, вы стали его применять по другому, относительно Майка ;)

Ок. Майк не про Фи. Майк про оценку общих усилий команды. Этот объем общих усилий Майк таки количественно предлагает оценивать? То есть 2sp - это в два раза больше усилий, чем 1sp?

И, кстати, нагуглился и такой текст Майка = https://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size The team doesn’t have to precisely estimate how long a given product backlog item will take. Instead, the team has only to put the product backlog item into the right bucket: “Does this item belong in the 5-point bucket or the 8-point bucket?”

Ок. Майк не про Фи. Майк про оценку общих усилий команды. Этот объем общих усилий Майк таки количественно предлагает оценивать? То есть 2sp - это в два раза больше усилий, чем 1sp?

Относительно друг друга, да. Другой текст Майка про другой метод планирования - bucket estimation, как я понял.

Там же и Фибоначчи Майк вспоминает: "I like to do this by pre-identifying a set of values teams will estimate with. A team might choose to estimate using 1, 2, 4, 8 and 16. Another team might use the Fibonacci sequence of 1, 2, 3, 5, 8 and 13, which is my slight preference."

Естесвтенно, надо понимать, что это не призыв прокапывать в течение спринтов 1-2 задачи, что бы точно их сравнить

Да хоть в размерах домов

смысл то не в этом

Относительно друг друга, да. Другой текст Майка про другой метод планирования - bucket estimation, как я понял.

метод один и тот же

я вас не понимаю, простите

смысл то не в этом

не, погодите, либо ты говоришь что "2 sp is twice big as 1sp" либо ты говоришь что это просто 2 соседних бакета (уровня)

не, погодите, либо ты говоришь что "2 sp is twice big as 1sp" либо ты говоришь что это просто 2 соседних бакета (уровня)

https://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size тут ни слова о стори поинтах,кстати.

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

https://www.mountaingoatsoftware.com/blog/how-can-we-get-the-best-estimates-of-story-size тут ни слова о стори поинтах,кстати.

тут о story size. Вы полагаете Майк в этой статье что-то особое хотел затронуть? совсем не sotry points?

тут о story size. Вы полагаете Майк в этой статье что-то особое хотел затронуть? совсем не sotry points?

User Story же

Ща, я перечитаю

То есть Вы утверджаете, что у Майка есть одна теория, которая про story sizing и в ней совсем не важна количественная оценка, а важны бакеты. А есть другая теория, которая про story points и там важна количественная оценка, и 2sp = 1sp + 1sp?

Не, он там о поинтах, да

Думаю, надо спросить у самого Майка =)

Вы уж простите, но вординг ваш подходит под войну на дебатах

я вам ничего доказывать не собираюсь

То есть Вы утверджаете, что у Майка есть одна теория, которая про story sizing и в ней совсем не важна количественная оценка, а важны бакеты. А есть другая теория, которая про story points и там важна количественная оценка, и 2sp = 1sp + 1sp?

Ну, если посмотреть видео в статье про SP он там прямо так и говорит (т.е. повторяет своё мнение, написанное в статье) Мол, да - в два раза больше относительно или 2\3 от 3. А в статье с бакетами он просто показывает другой подход к оценке - он гораздо быстрее. Он об этом так и пишет =) Разница, кстати, между статьями 3 года и про бакеты написана раньше. Возможно, Майк переосмыслил жизнь))))

При этом он выделяет голосом, что важны ОТНОСИТЕЛЬНЫЕ оценки. Из чего, долго размышляя как бы мне дальше жить с этим (некоторое время назад), я написал те мысли, что выше привёл - делая такое строго определение, Майк предлагает людям более осознанно ставить оценки.

Прям вот горячие дебаты, как будто оба подхода не имеют права на жизнь и не зависят от контекста :)

Я, вообще, кстати, эти вещи сочетаю =) Подход называется CEO - http://blog.sheidaei.com/2015/08/challenge-estimate-or-override-ceo-game.html Там в первом этапе люди просто расставляют задачки относительно друг друга, вообще без якорения на оценки (вообще какие либо) и очень много общаются друг с другом, споря и переставляя бумажки. Потом кофебрейк минут 5 И уже потом расставляют оценки поверх этих листочков, ищя ту грань, где задачки становятся "чуть сложнее". И там уже следующая цифра идёт. Иногда фибоначчи, иногда степень двойки. Иногда размеры рубашек. Цель вообще в другом - проговорить и понять все подводные камни и договориться и поймать общее ощущение, что такое "1 SP" или 5 SP или какие задачки уже "невпихуемые" =)

Прям вот горячие дебаты, как будто оба подхода не имеют права на жизнь и не зависят от контекста :)

Вот вот, я привёл третий =)

Я не Майк, конечно, но сугубо имхо, «ведра» удобней для одной команды, 1+1=2 - для нескольких команд в параллели, особенно когда над ними большой портфель.

Прям вот горячие дебаты, как будто оба подхода не имеют права на жизнь и не зависят от контекста :)

Ну тут такое. Что бы понять, как использовать надо докопаться до основ =) Кажется - докопались =)

Вот вот, я привёл третий =)

Теперь я знаю, как этот процесс называется :)

Теперь я знаю, как этот процесс называется :)

крутяк =) Он самый офигенный, кстати. Максимальное количество косяков выплывает в нём. И то что люди не понимают, что делают и ПО может не всё знать и описание если мутное - никогда не поставишь точно - всё уплывает сразу в конец очереди. И если задачки декомпазированы по слоям - люди начинают скучать и вообще уходить)

Я для стартующих команд похожий "придумал", обычные участники вебинаров даже обсуждали его пару недель назад. Не полностью 1 в 1 такой же, но близко.

Им точно в их проекте необходим Скрам? Другие фреймворки объективно хуже?

А вы спрашиваете с какой целью? Есть ощущение, что можно применить какой-то другой фреймворк?

Всем привет. А есть ли статья, книга, исчерпывающий гайд :) про инженерных техники, которые желательны в Agile-командах?

Всем привет. А есть ли статья, книга, исчерпывающий гайд :) про инженерных техники, которые желательны в Agile-командах?

Тут много. Все по делу. Картинка кликабельная. https://less.works/ru/less/technical-excellence/index.html

Основное в LeSS, например - CI, покрытие тестами, общее владение кодом (мержиться как можно чаще в Мастер).

А вы спрашиваете с какой целью? Есть ощущение, что можно применить какой-то другой фреймворк?

Конечно можно. Почему не канбан, например? Выявить узкое звено и работать над его расширением. Все лучше, чем людей т-шейпить насильно.

Тут много. Все по делу. Картинка кликабельная. https://less.works/ru/less/technical-excellence/index.html

Классная картинка. 👍 Спасибо! :)

Конечно можно. Почему не канбан, например? Выявить узкое звено и работать над его расширением. Все лучше, чем людей т-шейпить насильно.

А с чего вы взяли, что Канбан не предполагает т-шейп? В чем отличие?

Не предполагает и требует все таки разные вещи ) @gospodchikovs в сркам гайде есть что-нибудь про T-Shape? )))

Тут много. Все по делу. Картинка кликабельная. https://less.works/ru/less/technical-excellence/index.html

Забавно там uml диаграммы обсуждают)

Не предполагает и требует все таки разные вещи ) @gospodchikovs в сркам гайде есть что-нибудь про T-Shape? )))

кроссфункциональная команда = т-шейп

кроссфункциональная команда = т-шейп

что-то пропущено логическое звено ))

одно из другого вот вобще не вытекает однозначно

Не, я понимаю, что T-shape подразумевается. Я скорее спрашивал про как об это гайд говорит.