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

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

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

Понял, спасибо

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

Для УЧЁТА потраченного времени, не важно в чём оценивать,важно списывать в часах.

SP (Story Points, единицы истории)  -относительные оценки, они хорошо для быстрого разброса Больше/меньше, по ним можно считать диаграмму сгорания/возгорания и строить прогнозы если оценки примерно равны. Но стоит помнить что 2 SP + 2SP != 4 SP . И их нельзя использовать как аргумент для  ускорения работы и раннего выявления проблем. (использование SP для этого, приводит к натягиванию их на дни и противоречит идее SP)

Оценка в идеальных днях:  это крупная оценка, годится для прикладной разработки, не годится для задач "тут за полчаса починить". Но может использоваться как аргумент  для  ускорения работы и раннего выявления проблем, за счет сравнения "планировали за 3 дня сделать, уже 5 дней прошло".  

Двойная оценка в идеальных днях мин/макс:  как и вариант  "Оценка в идеальных днях" но дает возможность построения критической цепи и корректного расчета резервов. За счет разброса оценки можно понять наличие угроз при выполнении задачи.

Оценка в часах:  её любят в 1С и аутсорсе, но смысла в ней  нет. Так, как рабочих (эффективных)  часов в дне 4 , в лучшем случае 6.5.  Неважно , выполнил задачу за 5 или 6 часов , в этот день никакая другая задача начата не будет. после обеда мало кто начинает новую задачу. Также и оценкой на 12 часов - 1.5 дня. Вы уверены что инженер сможет что-то начать после вкусного обеда когда кровь идет на переваривание и хочется спать??

вы разделяйте оценку объема задач и сроков выполнения. SP в данном случае это просто относительная оценка объем задач. А сроки вычисляются через производительность команды на основании некоторого кол-ва спринтов

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

Здравствуйте, сейчас в команду пришел новые разработчик без опыта оценки в SP и получился очень интересный разговор на 1 час на планировании спринта, как раз на оценке первой задачи. Вся команда выложила карты по 20 и 40, а новый разработчик - 13. И тут выяснилось, что у коллег разное понимание "сложности". Одни вкладывают объем, другие технологическую сложность, третьи неопределенность требований, четвертые риски.

Для человека просто в голове представить, что задача в 2 раза сложнее или в 3 раза сложнее, чем самая простая. А как представить, что она в 13, в 20 или 40 раз сложнее оказалось у всех понимание разное, Поэтому видимо, раньше все в уме на часы перемножали (не говоря, конечно, никому об этом 😊

Все, кого я знаю так или иначе sp коррелируют с часами работы :)

А они проверяли это?

что именно? корреляцию?

Зависимость, что 10 sp это условно 4 дня

Интересная тема, в нашей команде, особенно недавние сотрудники тоже затрудняются в оценке задач по SP

Если коротко отвечать, то в 13-20-40-144 раза и не надо оценивать, она относительная друг относительно друга, рядом с близкими элементами, в целом, выстраивая шкалу ожиданий сложности\объема\рисков\неизвестности\новизны.
Planning Poker очень тяжело в таком случае помогает (там задачи в вакууме обычно на столе лежат по одной,э или в JIRA по одной открываются) скорее, одни дисфункции от него, так как разговора про эти области не происходит. Есть ещё Bucket Estimation, он поинтереснее в этом плане и CEO - максимально много контекста, но и времени занимает. Зато вопрос с новичками и шарингом знаний\пониманий\проблем решается тоже.

Левон, привет! Что за СЕО?

https://www.sheidaei.com/article/challenge-estimate-or-override-ceo-game-for-effective-estimations/ Challenge, Estimate or Override (CEO)
1. Этап 1 - раскладываешь в ряд все задачи, от менее затратных\сложных\больше усилий к более
2. Этап 2 - Кладёшь сверху оценки, тоже челленджа, какая оценка к какой группе задач подходит, а какие - пограничные.

Вот скриншот с воркшопа (пример выдуманный)

Механика подробнее - по ссылке)

Спасибо, похоже на bucket estimation же? Или я что-то пропускаю 🤔

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

Понятно, спасибо ✊🏻