Покер планирования, кто использует?

Этот процесс занимает гораздо меньше времени, чем разгребание результатов «работы» без нормального общения в команде.

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

Причем тут сложные системы? Это способ кратковременного планирования задач для команды. Он не заменяет процесс долгосрочного управления проектом.

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

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

Все то же самое применимо к обычным часам. Если не работали, то понятно, что задача займет больше времени.

Мы обычно разбивали задачи на сравнительно мелкие куски, не больше 16 часов, лучше меньше. Так что «править говнокод» превращается в отдельную задачу. Так чтобы к моменту реальной работы все было готово.

На изучение неизвестного кода тоже часто заводится отдельная задача.

про до детального планирования и оценки в часах и чёткую шкалу ты пропустил намеренно?

Использовался на прошлой работе. IMHO, помогает определить сроки хотя бы примерно

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

Клиенту, например. Или демпферу между ним и командой исполнителей в виде менеджера.

Расскажите, что думаете по этому поводу.

Юзайте сетевое планирование и не ипите себе и другим мозг

Вместо того что бы потратить время и обсудить проблемы и их решения нормальным общением они этой фигнёй страдают

Так там и идет обсуждение. Оценки потом.

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

В том же scrum такой роли нет.

вопрос на голосование.

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

Я без понятия зачем стори поинты вообще нужны. Я работаю в часах и планирую в часах. Все просто.

Ты один что ли работаешь? Тогда особо и не нужны. Как и почти любые другие практики.

Стори поинты лучше всего работают при переходе к относительным оценкам. Т.е. ты перестаешь оценивать задачи абсолютно, а сравниваешь задачи по цене с другими, уже сделанными. Эталонными.

Утверждается, что мозг лучше оценивает относительно, чем абсолютно.

Ну конечно, аджайл святой, а все продакты в состоянии услышать команду.

аджайл не святой, просто будет он у вас работать или нет, зависит только от вас. Это не алгоритм, это подход.

Используем. Что тебе конкретно интересно?

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

Мы пока строили светлый скрам силами программистов все было достаточно удобно. ...
А потом было решено построить правильный скрам силами менеджеров внешних консультантов и сертификации всех разрабов.

Нееее, вот я ваще не понимаю людей, которые одну удобную и хорошо работающую технологию без каких-то понятных причин заменяют на что угодно другое. Где гарантия, что это другое будет лучше (или вообще будет работать)? И зачем менять то, что и так решает задачи? Конечно, я понимаю менеджеров - те получили галочку за внедрение новой технологии, бюджет освоили «как надо», в резюме опять же есть что написать. Но все остальные чего ждали?

IMHO, нужно было поставить условие, что если «правильный скрам» не даст преимуществ, все это оплачивается из кармана того менеджера (или другого умника, который это предложил). Ну, а если «зайдет» как надо - премию в размере 10% бюджета.

Используем. Что тебе конкретно интересно?

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

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

Т.е. задачу X мы оценили в N. Задача X+1 с той задачей X больше/меньше/похожа по сложности.

За прошлую неделю мы успели сделать S, значит на следующую планируем примерно столько же/больше/меньше.

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

А нужно это для само-организации. Менеджеры тут не у дел и права голоса не имеют.

1. Как может инженер оценить трудоемкость задачи, полностью не поняв её сути? Это все-равно, что спросить проходящего мимо электрика за какое время он напишет «Войну и мир». Разумеется, что электрик ответит, что за пару недель книга будет готова. В итоге изначально неверной оценки сроков выполнения задач мы имеем чувство вины у разработчиков за сорванные сроки, которые они установили себе сами. Хитро буржуи придумали, чтобы всякие выскочки и зазнайки внутри коллектива подгоняли остальных, выкрикивая невыполнимые сроки выполнения с короной на голове.

2. Ежедневные утренние обсуждения работают на исправлении ошибок. Тут народ может подсказать что и где можно ещё посмотреть и попробовать. Когда разработчик вынужден думать, а лишь затем писать код неделями, этот подход с нормочасами и обсуждениями только нервирует.

3. Почему внедряется этот подход? Видимо, у людей задачи простые и однообразные, которые не требуют долговременного обдумывания. Вставил десять строк сюда, убрал пять строк там. Разве это программирование?