Almindelige fejl udviklere gør, når de estimerer tider

Estimeringstider er i forhold til hvert udviklingsteam og hver udvikler individuelt, der er mange faktorer, der påvirker disse estimater, og hvis de ikke tager hensyn til dem, vil de føre til en forsikringskatastrofe i det projekt og dem, vi har tilbageholdt.
Lad os derefter se de almindelige fejl, som udviklere laver, når de estimerer tider i udviklingsprojekter, for at undgå dem og lave et skøn så tæt på det ideelle scenario.

Tillidsinstinkt

Estimaterne ledsages på en bestemt måde af instinkt, som kan forfines med erfaring, og det er fint for en moden udvikler, men det er ikke det, der er tættest på skøn foretaget på en objektiv og effektiv måde.
Til dette er det bedst, at vi ser på antallet af relaterede og vellykkede implementerede projekter, på denne måde kan vi få metrics for, hvor lang tid det tog os med hver af disse og derefter kompilere disse tal i en rapport.
Det er en praksis, der vil tage os lidt længere tid, men det vil hjælpe os med to ting; først for at give et mere præcist skøn baseret på tidligere projekter og for det andet at kontrollere, hvor præcise vores instinkter er.

Spørg ikke

Der er en meget ejendommelig sætning, som mange udviklere vil føle sig identificeret med:

 "Hej, jeg har brug for et hurtigt overslag for et indholdsmodul."

Det er i det øjeblik, hvor vi skal tage et skridt tilbage og stille os selv følgende spørgsmål:

• Hvilke funktioner vil det have?
• Hvad vil dets omfang være, vil det være relateret til andre moduler?
• Mangler der oplysninger?
• Skal jeg vide noget andet?

Disse er blot nogle få, men der er ingen måde, at med en så vag idé, at vi kan lave et pålideligt skøn, er det derfor vores pligt at undersøge, stille spørgsmål, og at vi ikke er i tvivl om det krav, i det tid vi kan give et estimat, resten vil vi kun gætte og bruge magi til at estimere tidspunkterne for det samme.

Mentale og kollektive grænser

Dette er noget ganske almindeligt og refererer til flere faktorer, der indirekte involverer mennesker i vores miljø. Vores overordnede ser kravet og kan sige det "Det ser ret ligetil ud, det skal ikke tage lang tid at implementere", hvilket får os til at se det optimistisk. Det kan også være sådan, at en gruppe udviklere er til stede, og der foretages et gruppeanslag.
Problemet er, at de er "deres" estimater og ikke vores, hvormed estimatet af disse tider normalt altid er tættere på, end det egentlig burde være.

Bliver revet med af tidspres

Et konsekvent og pålideligt skøn tager tid, det gøres ikke i 10 minutter. En klient eller overordnet ønsker måske et estimat med det samme, hvilket er umuligt, medmindre det er et meget lille krav, der har et veldefineret omfang.
Hvis vi tilføjer til dette, at vi kan have et omfattende antal opgaver, der kræver øjeblikkelig opmærksomhed, vil vores instinkter fortælle os, at vi ikke kan spilde tid på dette skøn, så det vil være alt andet end præcist.
Afslutning
Vi har set de mest almindelige fejl, du laver i tidsestimater, men hvad med løsninger? Det er så simpelt som at ændre paradigmerne og vide, hvordan man siger nej, på en vedvarende måde og lade vores overordnede vide, at det er bedre at tabe en halv eftermiddag eller endda en dag med et præcist og pålideligt skøn, end uger eller endda måneder i har taget den forkerte vej. Ved løsning af denne opgave kan du dømme et projekt, selv før det er startet.