Precis som utlovat kommer här min åsikt om vad ”Definition of DONE” bör innehålla. Oavsett innehåll är det viktigt att alla i projektet, dvs. Teamet, Scrum Mastern och Produktägaren, alla är överens om vad den definerar – och vad den utelämnar.
”DONE” bör enligt min uppfattning minst innehålla:
Collaborated & Designed
Coded
Versioned
Tested
Documented
Knowledge Shared
Deployable/Deliverable
Approved
Denna lista är på intet sätt komplett eller tillräckligt tydlig. Varje team måste själva tillsammans med sin Produktägare och Scrum Master ta ställning till vad DONE ska innehålla och vad varje punkt betyder. Glöm inte bort att DONE beskriver krav på vad som ska ha utförts/fullgjorts av teamet för varje User Story som demonstreras på Sprint Demo.
Sedan kan det vara så att alla kriterier inte är applicerbara eller meningsfull för allt som teamet åtar sig under en sprint. Det kan också självklart vara så att man för vissa typer av User Stories lägger till ytterligare kriterier. Men lägger man till för mycket bör det diskuteras ifall något annat kanske ska tas bort. För många och för höga kriterier kan resultera i överprestation som inte är efterfrågad, a.k.a Waste.
Har ni i ert team inte alla DONE kriterier ovan? Försök införa dem än efter än så kommer ni se att er kvalitet och kundnöjdhet kommer att öka och er tekniska skuld att minska.
Vidare vill jag trycka på att alla i teamet är ansvariga tillsammans för att DONE efterlevs och uppfylls. Detta innebär också att var och förväntas hjälpa till för att färdigställa alla påbörjade åtaganden och tasks innan Sprint Demon.
Tvivlar du på om det är värt besväret? För några dagar sedan skrev jag ett inlägg om värdet på ”Definition of DONE”.
.
Collaborated & Designed
Teamet har tillsammans med produktägaren (och eventuellt med kund) diskuterat och beskrivit funktionen. Vad gäller den tekniska implementeringen har teamet suttit och diskuterat vad man vill uppnå och kommit överens om en teknisk lösning. (Detta kan t.o.m. ha skett i föregående Sprint.)
Coded
Funktionen/featuren är färdig kodad, dvs. all kod som ska skrivas har blivit skriven. Jobbar teamet med TDD på enhetstestnivå har dessa enhetstester blivit skrivna.
Versioned
Kod och dokumentation är incheckat i versionshanteringssystemet.
Tested
Den utvecklade funktionen/featuren är testad. Här behöver det detaljeras vilka krav på tester som krävs och vilka typer av tester funktionen/featuren ska utsättas för. Exploratory Testing? Automatiserade Acceptance tester? Integrationstestat av det nattliga bygget?
Documented
Överenskommen dokumentation är skriven och/eller uppdaterad. Exakt vilken dokumentation behöver defineras. Finns det system översikter som ska uppdateras? Användarmanualer?
Knowledge Shared
Antingen utövas Par Programmering eller så har person/personerna som utvecklade funktionen berättat för övriga i teamet vad de gjort, hur de tänkte och vilka moduler, klasser, tester, dokument, etc. de har skapat/ändrat.
Deployable/Deliverable
Funktionen/featuren är redo för leverans/installation, dvs. eventuella installations script har uppdaterats, installationspaket har kompletterats, etc. Testmiljöer ska dessa ha uppdaterats. (Detta betyder dock inte att funktionen automatiskt ingår i nästa leverans. Dock ska funktionen, med minimal ansträngning, kunna ingå i nästa version av produkten/systemet närhelst det beslutas av Produktägaren.)
Approved
Produktägare och/eller kund har gett feedback och sitt godkännande genom att prova på och testa i testmiljön.
.
Uppdatering: 2010-03-19
InfoQ presenterar ett intressant förslag på ”Definition of DONE” från Alixx Skevington på sin hemsida: http://www.infoq.com/news/2010/03/mainfesto-of-done