Tre vigtige principper for effektiv opgavestyring i jeres it-udvikling
De fleste softwareprojekter benytter sig af en eller anden form for opgavestyring, hvor man kan oprette, organisere og ændre status på opgaver.
Men hvis man blot vælger et produkt til at håndtere opgavestyringen og begynder at oprette opgaver i vildskab, risikerer man hurtigt at miste det overblik, man gerne ville opnå. Hvordan kan man så undgå det?
Hvad er formålet?
Som altid er det et sundt princip at holde sig formålet for øje, når man overvejer, hvordan noget skal laves. I forhold til effektiv opgavestyring af it-udviklingsprojekter er formålet:
- At gøre det klart, hvad der skal udvikles
- At få et overblik over hvad projektet indeholder, og hvordan det skrider frem
- Senere at kunne forstå, hvorfor noget er udviklet, som det er
Gør det klart, hvad der skal udvikles
Beskrivelsen af, hvad der skal udvikles, kan være mere eller mindre detaljeret – men den skal som minimum dække, hvad der forretningsmæssigt skal løses, og hvornår opgaven kan siges at være løst. Det gør nemlig forretningen i stand til at sikre, at løsningen af opgaverne medfører en opfyldelse af det forretningsmæssige behov.
Afhængig af projektdeltagernes tekniske niveau kan man få en mere erfaren udvikler til at skitsere, hvordan opgaven løses mest hensigtsmæssigt.
Få et overblik over hvad projektet indeholder, og hvordan det skrider frem
Når det er beskrevet, hvad der skal udvikles, kan teamet estimere opgaven. Om estimeringen sker med timer, storypoints eller noget helt tredje er mindre væsentligt – så længe der er enighed om betydningen af estimaterne (er test og review indeholdt i estimatet, hvor mange timer er 1 dag etc.).
Når en opgave er beskrevet og estimeret, er den klar til at blive påbegyndt. Som arbejdet skrider frem, kan opgaven ændre status i den detaljering, man finder det passende. Det simpleste er noget i stil med: klar – i gang – afsluttet, men man kan tilføje test – review – mangler afklaring etc. efter behov.
Om man vælger at nedskrive resterende tid undervejs, eller først når opgaven er løst, er en diskussion, der minder om afskrivninger i et regnskab. Gør det, der virker for jeres projekt.
Giver opgaven anledning til spørgsmål, så sørg for at få disse fastholdt i opgavebeskrivelsen.
Dokumenter hvorfor noget er udviklet, som det er
Den udviklede kode ender i et versionsstyringsværktøj. Alle den slags værktøjer kan sende en besked med, når koden sendes. Denne besked skal indeholde en reference til den opgave, koden er udviklet for at løse.
Kodens opgavereference gør nemlig, at man senere kan forstå, hvorfor noget er kodet, som det er. Eller sagt på en anden måde: Man kan altid se i koden, hvordan noget er implementeret, det svære er at se, hvorfor det er gjort, som det er.