Grey Scope Creep
Når man anvender agile projektledelsformer og processer, så vil der altid være et indbygget krav om, at hver iteration - hvad enten den hedder iteration, sprint eller noget andet - skal levere demonstrerbar og færdig funktionalitet. Det kan være utrolig svært at sikre dette formål. Hvis man ikke er meget påpasselig, så vil der være mange løse ender i det som leveres efter hver iteration. Dette kaldes grey scope creep og betyder, at arbejdet hober sig op på usynlig vis. For hver iteration kommer man længere og længere bagud, specielt hvis man bogfører funktionerne, som er blevet leveret, som "done". Jeg har selv været i den situation og kan derfor kun samtykke, når der tales om, at man skal operere med en meget striks version af "done". Det er langt bedre at lægge ganske lidt funktionalitet i en iteration, og så får denne funktionalitet færdig. Og færdig betyder her, at funktionerne er gennemtestede både på unit-test og brugergrænsefladeniveau, at dokumentation er udført, at alle integrationstests er foretaget osv...
Hvis udviklere/programmører på et givent projekt ikke lever efter denne devise, så skal det tages meget alvorligt. Ingen udvikler skal have lov til at cutte i koden for at komme hurtigere i mål. Heller ingen skal springe test eller review over. Samtidig skal projektlederen aldrig bogføre funktioner som "done", før de rent faktisk er det. Dette er en kunst, tro mig, men det lønner sig altsammen i form af mere stabil kode og mere stabil projektplanlægning (burn-rates der kan bruges til noget, iterationplanlægning som er realistisk osv...)
Hvis udviklere/programmører på et givent projekt ikke lever efter denne devise, så skal det tages meget alvorligt. Ingen udvikler skal have lov til at cutte i koden for at komme hurtigere i mål. Heller ingen skal springe test eller review over. Samtidig skal projektlederen aldrig bogføre funktioner som "done", før de rent faktisk er det. Dette er en kunst, tro mig, men det lønner sig altsammen i form af mere stabil kode og mere stabil projektplanlægning (burn-rates der kan bruges til noget, iterationplanlægning som er realistisk osv...)
Etiketter: krav


0 kommentarer:
Send en kommentar
<< Startside