Size: a a a

Software Design/Architecture/Zen

2021 June 07

M

Mixer in Software Design/Architecture/Zen
Фесор как проснётся может скажет чето такое что позволит нам отмазаться от дурацких оценок этих)
источник

SP

Sergey Protko in Software Design/Architecture/Zen
нууу. с эстимациями или без - всякие диаграммы ганта и прочие роадмапы делать надо. Ну то есть если ты лид команды скажем или там деливери менеджер какой то от этого не уйти. Всей команде в этом учавствовать не особо надо. Но "экспектейшенами" управлять надо, там есть целая вериница стэйкхолдеров обычно которым "это очень интересно".

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

Один из аргументов который "иногда" работает - ты когда оцениваешь задачу в часах - это часы чего? сколько конкретно ты будешь делать задачу? сколько QA будет ее проверять? Сколько разработчики будут багфиксы делать? А сколько она будет лежать и ждать "слещующего этапа"? "А какая вам разница сколько мы делаем задачу если деливери всеравно раз в спринт?"

Однако какие-то оч хайлевл эстимации сложности задачи полезны так как это помогает с приоритизацией. Всякие скрам покеры и прочее - выкидывай к херам. бесполезная трата времени. Оно не про оценку деливериблс и не про "все поняли требования".  Просто лид может проходиться и выставлять t-short size эстимации что бы понимать какие вещи дробить еще надо а какие может быть "стоит отложить ибо есть вещи похожей важности но проще"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
однако есть довольно много "менеджеров" которые требуют эстимацию в часах не с целью планирования. А просто что бы "ты комитмент дал - это будет наша контрольная точка - не вписался объясняйся что пошло не так".
источник

SP

Sergey Protko in Software Design/Architecture/Zen
как бы мотивация понятна но люди "обычно" пытаются "вписываться" даже если для этого придется говно в мастер залить. Или потом "а я не успел потому что вот тот хер долго ПР апрувил"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
и прочее и прочее
источник

SP

Sergey Protko in Software Design/Architecture/Zen
ну договоритесь что вы оценки в неделях давать будете. "далекие перспективы расплывчатые оценки". или опять же t-short size. Это обычно не так муторно и в долгосрочной перспективе с учетом статистики может оказаться надежнее
источник

SP

Sergey Protko in Software Design/Architecture/Zen
вот "переоценки" звучат странно. Намекает что вы часто обсуждаете то что не планируете брать в работу ближайшие месяц-два. Если в это еще и команда вовлечена то не завидую
источник

M

Mixer in Software Design/Architecture/Zen
да. спасибо, надо подумать будет.может у нас и не самые плохие обстоятельства кстати.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
можно настаивать на iceberg модели бэклога. Мол "мы подробно обсуждаем и эстимируем только те вещи которые вам важно получить ближайший месяц. Все остальное - просто будем обсуждать что бы вы могли приортизировать. Тут достаточно лида.
источник

SP

Sergey Protko in Software Design/Architecture/Zen
хотят чет подробно обсудить - пусть поднимают наверх по бэклогу. НУ а если не срочно то пусть полежит
источник

M

Mixer in Software Design/Architecture/Zen
переоценки это случается на текущих проектах которые в проде уже. там отдельная команда и там своя типа кухня. но все плохо и от этого уходить пытаемся
источник

SP

Sergey Protko in Software Design/Architecture/Zen
просто скорее всего "там где-то есть стэйкхолдер которому надо знать когда и не ебет"
источник

SP

Sergey Protko in Software Design/Architecture/Zen
опять же - скорее всего они там все нервничают и хотят знать когда потому что когда они просят чет сделать они ждут по пол года
источник

M

Mixer in Software Design/Architecture/Zen
ну да, вот как ты говоришь вроде оно так и происходит плюс минус. то есть в целом по идее и норм
источник

SP

Sergey Protko in Software Design/Architecture/Zen
очень занятное к слову упражнение - побыть стэйкхолдером для бэклога какой-то команды. Когда ты автор хотелок и "какого хуя уже пол года пусть оценки делают" - возникает такое желание)
источник

M

Mixer in Software Design/Architecture/Zen
чуть не так. когда - уже определено в целом. и вот стараемся разделенные куски оценить и сопоставить с этим "когда" - и понять успеем или нет
источник

M

Mixer in Software Design/Architecture/Zen
но вроде первоначальная оценка общего этого большого скоупа совпадает с той - когда уже декомпозированные задачи начали оценивать уже более скурпулезно так сказать. первоначальную оценку проводил я - типа "нууу за год сделаем" ))) щас вот я свою собственную оценку сопоставляю уже с живой оценкой.
источник

M

Mixer in Software Design/Architecture/Zen
хорошо что я там в три конца перезаложился и мы даже чуть быстрее графика идем ))
источник

SP

Sergey Protko in Software Design/Architecture/Zen
по сути оценка нужна бизнесу только для приоритизации. Условно если есть 3 critical asap айтема и 2 из них маленькие а один жирный - можно смело брать два меленьких первыми - low hanging fruit все дела
источник

SP

Sergey Protko in Software Design/Architecture/Zen
а вот внутри эстимация - можете договориться мол "дробите таски так что бы они максимум 3 дня висели".
источник