Показать сообщение отдельно
Старый 15.09.2021, 12:55   #117  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,273 / 3466 (122) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от axm2017 Посмотреть сообщение
Что не всегда скажем так помогает.

Традиционно оценка от n часов (в каких то конторах от 40, в каких то выше) означает высокие риски что может и не повезти.

Собственно по этой причине и родился agile в том числе:
я могу конечно оценить путь до Владивостока по земле в n дней однако в реальности +- спрогнозировать точно получается лишь путь от себя и до той горы так как вижу дорогу до горы + чувствую погоду и прочие вещи.
Ну тут главное не путать понятия "сроки" и "трудозатраты". Сроки действительно планируются до горы, а дальше с учетом погоды и прочих вещей (собственно - любая методология agile, scrum и т.д. ориентирована в первую очередь на планирование сроков). Но от того, что день пережидаешь под дождём где-то в укрытии - трудозатраты не меняются.
Для себя я заметил закономерность - если при постановке задачи в голове уже есть чёткое понимание конкретных строк кода - то оценка не должна превысить 8 часов. А если чёткого понимания нет - значит будет больше 8 часов.

Оценка в 40 часов - небольшая, если в ней сидит 8 часов проработки задачи. Потому что оставшееся время можно поделить непосредственно на разработку, тестирование и написание инструкции / обучении заказчика использованию модификации. В итоге получается, что непосредственно на разработку остается часов 16-20, а это вполне посильный горизонт оценки при правильной проработке задачи.

Ну а если задача действительно большая - то надо дробить. И время на дробление должно входить во время проработки задачи.
__________________
Возможно сделать все. Вопрос времени