покер же, две-три итерации и синхронизовались по поводу сложности

Ну так да

Правда я очень долго их убеждал в том, что сп это не условные единицы для минут-часов)))

это идеальный вопрос для собеседования

это идеальный вопрос для собеседования

Какой?

а что для вас стори-поинты, чем измеряются, как понять какой объем за этой оценкой?

И ждать ответ по скрамгайду?

А сори

Там же их нет

если человек начинает рассказывать про часы, начинать ретро)

)

Конкретно мой поинт заключался в том, что в safe environment оценка в часах спокойно заменяется ответом на вопрос "Сделаю сегодня или нет". То же самое, только относительно всего Sprint Backlog, делают команды работающие по #NoEstimates на Планировании. Доверились своему чутью. Получилось - хорошо, продолжаем. Не получилось - анализируем почему на Ретро. ИМХО, опять же

мерять в часах это грустно. тк кажется что часы это точная единица измерения, но оказывается что у каждого свой час работы 😄

мерять в часах это грустно. тк кажется что часы это точная единица измерения, но оказывается что у каждого свой час работы 😄

час работы джуном? или час работы тимлидом?

час работы джуном? или час работы тимлидом?

я понятия не имею кто эт такие 😄

час работы джуном? или час работы тимлидом?

так исполнитель же определен))) Сорри за продолжение глума

Конкретно мой поинт заключался в том, что в safe environment оценка в часах спокойно заменяется ответом на вопрос "Сделаю сегодня или нет". То же самое, только относительно всего Sprint Backlog, делают команды работающие по #NoEstimates на Планировании. Доверились своему чутью. Получилось - хорошо, продолжаем. Не получилось - анализируем почему на Ретро. ИМХО, опять же

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

так без глумежа. у вас уже есть sp, команда понимает сколько sp она делает за спринт. зачем нужны еще какие то метрики?

1. свежесформированная команда может не понимать 2. SP не прокси для объема. Вариантивность задачи в 3-5 SP в реальном времени может быть довольно большой 3. Кросс-функциональные люди не всегда доступны. Если у тебя 5 сторей имеет отношение к работе с базой данных и только один разработчик из команды умеет с ней работать, лучше понимать, сколько точно займет эта работа и есть ли у этого разработчика достаточное количество часов.

У каждой команды правда своя и надо просто делать так, как выходит удобнее и эффективнее

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

"It depends"(c) - как всегда

"It depends"(c) - как всегда

ага

1. свежесформированная команда может не понимать 2. SP не прокси для объема. Вариантивность задачи в 3-5 SP в реальном времени может быть довольно большой 3. Кросс-функциональные люди не всегда доступны. Если у тебя 5 сторей имеет отношение к работе с базой данных и только один разработчик из команды умеет с ней работать, лучше понимать, сколько точно займет эта работа и есть ли у этого разработчика достаточное количество часов.

если у вас на одну экспертизу один человек, пора начинать knowledge sharing, хотя бы DB 101

У каждой команды правда своя и надо просто делать так, как выходит удобнее и эффективнее

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

У каждой команды правда своя и надо просто делать так, как выходит удобнее и эффективнее

Некоторые правды лучше проверять на правдивость :)

1. свежесформированная команда может не понимать 2. SP не прокси для объема. Вариантивность задачи в 3-5 SP в реальном времени может быть довольно большой 3. Кросс-функциональные люди не всегда доступны. Если у тебя 5 сторей имеет отношение к работе с базой данных и только один разработчик из команды умеет с ней работать, лучше понимать, сколько точно займет эта работа и есть ли у этого разработчика достаточное количество часов.

что такое 1 SP? Кто такие кроссфункциональные люди? мы же тут про скрам и команды говорим.

Некоторые правды лучше проверять на правдивость :)

Это да, ну для внесения этой адекватности и нужен мастер))

Индивидуальная оценка может привести к персональному блеймингу. Тем более в незрелых командах

что такое 1 SP? Кто такие кроссфункциональные люди? мы же тут про скрам и команды говорим.

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

Индивидуальная оценка может привести к персональному блеймингу. Тем более в незрелых командах

Индивидуальная == в одиночку или для отдельного члена, но оценка командой?

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

но T-shaping в любом случае надо развивать. Как раз для устранения bus factor

но T-shaping в любом случае надо развивать. Как раз для устранения bus factor

Развивать надо, но это процесс :)

но T-shaping в любом случае надо развивать. Как раз для устранения bus factor

не всем это надо) особенно тяжело семейным

Индивидуальная == в одиночку или для отдельного члена, но оценка командой?

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

не всем это надо) особенно тяжело семейным

Это не так тяжело, как кажется :)

T-shaped постулирует экспертизу в одной области и базовые знания в смежных.

А не экспертизу в нескольких областях.

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

не скрам команда - а команда разработчиков. они так же должны принимать риски фактора автобуса. поэтому если одного сбил автобус PBI должны быть реализованы всё равно.

Это не так тяжело, как кажется :)

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

и я так и не понимаю куда тут втыкать часы 😄 потому что оценка в часах это самое не точное что есть для оценки работы.

и я так и не понимаю куда тут втыкать часы 😄 потому что оценка в часах это самое не точное что есть для оценки работы.

как куда? В поле в Jira!

просто knowledge sharing сессий недостаточно, надо следом workshop и дать время вникнуть

просто knowledge sharing сессий недостаточно, надо следом workshop и дать время вникнуть

Pair programming

или Mob

как куда? В поле в Jira!

даже там вроде как estimate в каких то story point измеряется

Pair programming

а вы вообще пробовали?)

а вы вообще пробовали?)

у меня команды делают и pair и mob

сами, не из-под палки

ну вы попробуйте в своей компетенции сделайте pair или mob

посмотрите, что получится)

и я так и не понимаю куда тут втыкать часы 😄 потому что оценка в часах это самое не точное что есть для оценки работы.

Сначала берутся PBI и обсуждаются. Когда команда поняла, что делать, она фиксирует эти знания в acceptance criteria и, если еще считает это нужным, в подзадачах. Затем команда дает оценку PBI в сторипоинтах Затем, опять же, опционально, комнда решает, кто какую подзадачу будет делать и этот "кто" дает оценку подадаче в часах.

Т.е. в часах оцениваются только подзадачи.

ну вы попробуйте в своей компетенции сделайте pair или mob

ну коучинг и lead by example это и есть своего рода pair/mob programming в нашей компетенции, имхо)

Я смутно помню рекомендацию разбивать на подзадачи и оценивать не дальше чем на 2 дня вперед.

ну коучинг и lead by example это и есть своего рода pair/mob programming в нашей компетенции, имхо)

увы, но даже близко нет

Правда уже не помню, откуда эта рекомендация :)

Правда уже не помню, откуда эта рекомендация :)

на два спринта же вперед, потом устаревает

на два спринта же вперед, потом устаревает

нене, именно на два следующих дня в спринте. Но я реально не помню, откуда это.

Сначала берутся PBI и обсуждаются. Когда команда поняла, что делать, она фиксирует эти знания в acceptance criteria и, если еще считает это нужным, в подзадачах. Затем команда дает оценку PBI в сторипоинтах Затем, опять же, опционально, комнда решает, кто какую подзадачу будет делать и этот "кто" дает оценку подадаче в часах.

это сильно мешает члену команды переключится на другой PBI если там нужна будет его компетенция. И задаешься вопросом ты типо должен выполнить работу которую обещал сделать за 6 часов или помочь другому члену команды реализовать его PBI

это сильно мешает члену команды переключится на другой PBI если там нужна будет его компетенция. И задаешься вопросом ты типо должен выполнить работу которую обещал сделать за 6 часов или помочь другому члену команды реализовать его PBI

В норме подзадачи должны быть разбиты на 2-4 часовые блоки. Но это точно эпирическим путем выведено.

А про "будет мешать" - не будет. Это не commitment, это проверка адекватности плана.

Я вообще не очень люблю практику разбития на подзадачи, вне зависимости от того, будут их оценивать или нет.

А про "будет мешать" - не будет. Это не commitment, это проверка адекватности плана.

ни один план не выдерживает столкновения с реальностью)

А про "будет мешать" - не будет. Это не commitment, это проверка адекватности плана.

так этот коммитмент это обещание которое нужно выполнить. если ты его не выполняешь - оно обезценивается.

Но для "молодой" команды практика нужна, как минимум для старта.

так этот коммитмент это обещание которое нужно выполнить. если ты его не выполняешь - оно обезценивается.

Игорь, еще раз, оценка подзадачи в часах - не commitment. Она нужна чтобы понять наличие или отсутсвтие потенциальных проблем с планом спринта.

Но для "молодой" команды практика нужна, как минимум для старта.

зачем их учить микроменеджменту?

зачем их учить микроменеджменту?

У меня есть смутное ощущение, что мы обсуждаем какие-то совсем разные вещи :)

Я вообще не очень люблю практику разбития на подзадачи, вне зависимости от того, будут их оценивать или нет.

мы даем оценку в sp в общем виде, дальше на момент взятия бастилии задача бьется на несколько подзадач (бек, фронт, qa) с обязательной выработкой контракта в самом начале

Игорь, еще раз, оценка подзадачи в часах - не commitment. Она нужна чтобы понять наличие или отсутсвтие потенциальных проблем с планом спринта.

Я правильно понимаю, что речь о том, чтобы участников "молодой" команды заставить задуматься о всех возможных подводных камнях, прежде чем они скажут "Седня сделаю" на Дейли? Или цель, все-таки, в другом?

мы даем оценку в sp в общем виде, дальше на момент взятия бастилии задача бьется на несколько подзадач (бек, фронт, qa) с обязательной выработкой контракта в самом начале

Я обычно, после того, как команда 2-3 спринта поработала и скрам для нее вошел в привычку, предлагаю вообще не бить задачи на сабтаски.

У меня есть смутное ощущение, что мы обсуждаем какие-то совсем разные вещи :)

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

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

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

сплит дает атомарность, атомарность дает лучшее понимание

paring, mob programming и т.п. внутри спринта для организации прозрачности и collective effort :)

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

а как велосити, росло?

а как велосити, росло?

росло со временем, когда ребята учились и делали работу быстрее.

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

Это не дичь. The Development Team usually starts by designing the system and the work needed to convert the Product Backlog into a working product Increment. Work may be of varying size, or estimated effort. However, enough work is planned during Sprint Planning for the Development Team to forecast what it believes it can do in the upcoming Sprint. Work planned for the first days of the Sprint by the Development Team is decomposed by the end of this meeting, often to units of one day or less. The Development Team self-organizes to undertake the work in the Sprint Backlog, both during Sprint Planning and as needed throughout the Sprint.

Сабтаски это вариант декомпозиции.

Сабтаски это вариант декомпозиции.

команда должна сама определить уровень декомпозиции.

команда должна сама определить уровень декомпозиции.

Спасибо, разумеется сама. А что, я где-то написал, что это менеджер пришел и заставил?:)

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