Faktormetoden

Det er velkendt at der kan være meget stor forskel på hvor lang tid to udviklere er om den samme opgave. Der er først og fremmest to faktorer der spiller ind, nemlig udviklerens generelle erfaringsniveau (nyuddannet vs. erfaren) og hans specifikke viden inden for design eller kodning og kendskab til værktøjer, forretningsområde o.s.v.

Disse forhold samles i to faktorer som er knyttet til den enkelte udvikler. Udviklerens generelle erfarings- og vidensniveau samles i en produktivitetsfaktor (PF), og hans / hendes mere specifikke kendskab til forretningsområde, specifikke værktøjer m.m. betegnes vidensfaktor (VF). Sidstnævnte er ikke blot individuel fra person til person, men også fra projekt til projekt, idet det er forskellige faktorer der er vigtige. At jeg har en høj vidensfaktor inden for programmering i Java hjælper jo ikke noget hvis jeg skal være med til at udvikle en applikation i Cobol.

I en del organisationer kan det sikkert være kontroversielt at den enkelte udvikler bliver vurderet og eksplicit bliver udstyret med en produktivitetsfaktor, hvilket jo betyder at man kan sammenligne sig med andre i organisationen. Dette er dog en stor fordel at kunne tage disse forhold i betragtning ved estimering på lavt niveau.

Denne metode bygger oven på elementmetoden. Det vil sige at projektet skal nedbrydes i mindre bestanddele på ideelt set ikke over en arbejdsuge, som der direkte kan sættes et estimat på. For yderligere detaljer på dette område henvises til elementmetoden.

En ny udvikler vil typisk starte med en meget lav produktivitetsfaktor, og kun de bedste og mest erfarne når op på meget høj.

Det kræver modenhed at bruge denne metode, men lad mig undersøge om der er basis for et implementere et sådan system i din organisation.