Ha egy programozó nem tudja jól megbecsülni a feladatainak a hosszát, vagy mondjuk egy projekt idejét, akkor nem is való a szakmába?

Kezdőként sztem senki se tudja jól megbecsülni az időket. Minden esetre ha más nem kérdezi, akkor is érdemes magadnak kitalálni h kb mikorra kéne végezned.

Plusz sok projektnél közbejöhetnek váratlan dolgok amúgy is

Tökéletes becslést nyilván nem lehet adni, mivel előre nem lehet biztosan tudni, hogy mennyi munkával jár, ezért szoktak inkább nagyobbat mint kisebbet adni.

Pl. van a fibonacci becslés:

[link]

De vannak más módszerek is:

[link]

#3

Ez pl. teljesen nagy marhaság.

A management-nek pont semmi ismerete arról, hogy mivel jár egy új funkció fejlesztés ügyileg.

A programozók tudják, hogy egy új funkcióhoz csak fel kell venni egy új függvényt és 3 sor az egész vagy át kell írni a teljes kódot kb.

A management nem tudja, hogy az adott alkalmazás belül hogy nézki, hogy működik. Amit tud, hogy mit csinál jelenleg, illetve mit kell még csinálnia.

Ez a "mit kellene még csinálnia" átmegy az architect-eken, akik kidolgozzák, hogy mivel járna, mivel az architect-eknek már pont van rálátása a működésre, de pl. ők se tudnak garantálni semmit.

"Miért nem kell az egyetemeken ilyen időbecslő gyakorlatilag végezni?"

Ennek a mondanak nincs így értelme.

Egyébként ez a becslés egy durva blöff.

Főleg amikor a feladatkiírása homályos, pontosan nem meghatározható a feladat.

Becslés után derül ki, hogy "hát azt mi nem is úgy gondoltuk hanem így", "nem mondta XY, hogy azt nem úgy, hanem így kell?" stb.

Úgy látom nagyon jellemző hogy akik a feladatot meghatározzák és leírják azt sem tudják pontosan mit akarnak.

Sokszor nem lehet tudni mennyi ideig tart.

Szerintem mindenkivel előfordult már, hogy volt egy laza 2 órás simán megoldható feladat, amiből 1,5 hét lett, mert kiderült, hogy a rendszer nem alkalmas, hogy szépen implementáld, meg találsz 1-2 hibát, így jön a jó nagy refaktorálás.

Persze ez csak ott van, ahol számít a kódminőség, hiszen mindent meglehet oldani olcsón és gyorsan.