Меня тоже смущает =) Потомучто оценка в часах никогда не работает, ибо забывают о тестах, баг фиксах, рисках неполного описания, рисках новых технологий или библиотек. Если составлять план проекта, то можно предварительно с командой обсудить длительность +/- 2 недели (очень условно), но что б сказать, что это займет условно 80 часов -- это брехня. Если конечно они не пилят одно и то же каждый день (типа интегрируют стандартную библиотечку для каждого клиента - но это вообще monkey job).

Я именно об этом. Спасибо

Спасибо за ответ).

🖖 Здравствуйте ! Добавлю иное мнение. Оценка в часах всегда работает, если понятно - на какие работы списывается время.

Привет Свят ) Вот мне тоже в практике пару раз попадались проекты, отчетность по занятости сотрудников в которых велась по таймшитам, с подробным описанием и последующей валидацией таймшитов линейным руководителем отдела разработки, причем в мелочах все вписывалось, ибо один внешний чч сениора стоит 500д\час

а что если применять оценку в часах, аналогично абстрактной оценке?

Оценка в часах способна учитывать все риски? И это все, вообще про что? Это Скрам команда, антискркмкоманда, о чем это.

🖖 И ещё раз, здравствуйте. Про оценку рисков, наверное, сейчас поговорит не получится, т.к. тема серьёзная. Про оценку чего-либо (выполняемых работ; создание "полезности") - важно разделять ответы на вопросы:
1) Сколько чистого времени ушло на конкретную работу.
2) Когда "этим" можно будет уже пользоваться.
Пример:
интегрировать библиотечку на определённом стенде - это 1 час
убедиться, что всё работает, в том числе библиотечка на другом - это 4 часа.
А пользоваться результатом на пром стенде можно будет только через 80 часов. В том числе, если не выстрелят риски ошибок сборки, модели данных, версий шаблонов и т.п.

Про Скам и антискрам интересно, но сейчас не готов, т.к. на службе.

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

Серия встреч о GameDev от ВШЭ

Спасибо!!

спасибо Лёша)