Vad innebär det att jobba inkrementellt? Hur levererar man en komplex lösning med en komplex arkitektur i små steg enligt en iterativ process såsom Scrum?
Iterativt = Upprepbar, lärande process. Små steg. Förvänta dig inte att få det rätt första gången. (Sprint = Iteration)
Inkrementellt = Bygg i vertikala tårtbitar (Stories) hellre än i lager, dvs. bygg inte en modul i taget för att i slutskedet försöka foga ihop dem. Bygg och leverera en liten del av helheten i varje iteration.
Så, vad är det man ska undvika?
- Dela inte upp team efter applikationens lager.
- Bygg inte en komponent i taget bara för att i projektets slutskede (under exempelvis integrationstestningen, eller än värre – efter leverans) upptäcka att bitarna inte passar ihop och måste skrivas om.
- Bygg inte något under sprinten som inte resulterar i någonting som inte är av värde för slutanvändaren och som inte kan demonstreras på Sprint Demo.
- Brodera inte ut komponenter med extra funktioner som kan ”vara bra att ha” eller som inte är nödvändiga just nu för den Story som ska levereras. (Med största sannolikhet är det antagligen ogjort jobb. ”Bra att ha”-funktioner visar sig ofta överflödig eller nödvändiga att skriva om när de väl ska anropas/användas.)
Hur ska vi göra istället?
- Gruppera Stories i områden och bygg tvärfunktionella team runt varje område (som har kunskap som krävs för att utveckla och testa alla lager, exempelvis UI, server och databas).
- Bygg en Story i taget och bygg alla funktioner som behövs (dvs. bygg det som behövs i UI, det som behövs på servern och det som behövs i databasen), och inget annat än det som behövs för Storyn.
- Se till att Storyn som utvecklas under Sprint är tillräckligt avgränsad för att bli KLAR (dvs. kodad, testad, integrationstestad, dokumenterad, levererbar och installerbar)
Meh!?
…kanske någon tänker, ”Är det inte svårt att bygga något varje sprint som slutanvändaren kan använda och som har faktiskt värde för verksamheten?”
Svar ja.
De första Sprintarna kommer mycket energi och tid gå till att bygga skelettet och ramverket i arkitekturen. Och det måste det få göra annars riskerar man att få en slarvig struktur som inte går att bygga vidare från. Men ledordet även här måste vara – ”Bygg enbart och endast det du behöver, men gör det bra”. Försök inte förutse framtida behov utan bygg en arkitektur som är tillräckligt flexibel och stabil för att kunna anpassas, byggas ut och justeras i framtiden.
Balansgången är svår men däri ligger också nyckeln till förmågan att kunna leverera värdefull mjukvara efter varje Sprint och en av hemligheterna till hur man uppnår snabbhet och flexibilitet.
(Ursprungligen publicerad på blogg.sogeti.se)
Befinner du dig i Lund imorgon bitti tycker jag definitivt du ska ta en sväng till Sogetis kontor för ett spännande seminarie och lite gratis frukost. Ämnet är Agil testning och en riktigt tung expert inom området, Ken Brennock som hälsar på från Irland, håller i seminariet.
”Scrum är bara en hype. Det är bara coolt just nu att säga att man jobbar agilt men eftersom allt fler bevisligen springer in i bekymmer med Scrum kommer det snart självdö.”
Överhörde häromdagen ”Jag angriper det här väldigt agilt, det vill säga jag tar det som det kommer”.
Jimmy Janlén "Den Scrummande Konsulten" 