Статьи на основе проектов и написаны. Ну и факапов. Так что все свое

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

Более того, если полезть в соответсвующие учебники по обсуждаемой теме, то всё, что ты написал выше, ты найдешь там.

Да, все придумано до нас, но повторять надо снова и снова.

Не хочется флеймить, но Днепрогэс-то американцы и строили...

Днепрогэс, видимо один из таких )

Ну меньшинство-то задумается. На него вся надежда :)

Ну, я там сам непосредственно не участвовал. Но рискну предположить, что в 90% случаев оценка была либо очевидна, либо обсуждение существенно большей точности не привносило — требования были достаточно детальны. А стоило оно при этом: кол-во членов команды Х количество часов обсуждения, т. е. немало.

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

тут неплохой обзор техник оценок (аджайл, в основном)
www.linkedin.com/...​ile-safe-framework-samir

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

Часть 2 в проде:
dou.ua/...​imation-of-labor-input-2

Ну гемблинг в оценках — теперь уже достаточно очевидная вещь (#noestimates, cone of uncertainty). Хотя и гемблинг подчиняется теорверу.
Вопрос только в том, кто возьмет на себя риски — заказчик или исполнитель.

Ссылки хороши

Вадим, спасибо за комментарий. Математика — во второй части, в т. ч. про распределения. Судя по комментарию, близко к вашим рассуждениям. Будет интересно подискутировать. В первой я пока еще ничего не складывал и не вычислял :)

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

Спасибо. Да, где-то была оговорочка, что это больше применимо для вотерфола. Наверное, во второй части затерялось. Замечание ценное.

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

Частина перша готова. За пару тижнів — друга з розрахунками.
dou.ua/...​imation-of-labor-input-1

По суті це різні ризики. contingency — ризик по конкретній задачі. Risk — загального проекту, більше відноситься до взаємозвязку задач. Алек ен всі клієнти розуміють це. Можливо, доведеться сховати

:) Все, що стосується проекта — робота ПМа, але він може комусь делегувати частину. Відповідальність все одно на ньому (ній).

Приблизно так, хоча мої естімейти закінчувалися в основному на годинах. Інші кости (витрати) — відрядження, ліцензіі на софт, залізо, роялті, мита, субпідряники, зарпата, аренда, та ще мільйон можливих статей. Залежить від компанії, проекту, оточення, облікових політик і т.п.Тут краще звернутися до літератури по фінансам або спеціалістів.