Jag tror jag ska börja med att presentera mig själv. Johan Eriksson heter jag och arbetar som Testledare. Mina intressen i jobbet är framförallt Test och Kravhantering. Jag har också ett intresse för agila utvecklingsmetoder och för andra kvalitetsaspekter inom utveckling av mjukvara. Bloggen startades för att jag ville dela med mig av mina tankar kring agila utvecklingsmetoder men kommer nu vidgas till att omfatta även andra aspekter.
Trevlig läsning.
Efter att ha fått en fråga på bloggen insåg jag att jag kanske ska försöka skriva lite mer inlägg här. Dags att börja fundera kring vad jag vill förmedla tror jag.
Planning Poker tror jag att de flesta som är bekanta med Agil systemutveckling känner till, en metod för tidsestimering där hela gruppen estimerar de aktiviteter som ska genomföras i en sprint. Till hjälp finns en kortlek med siffrorna 0,1,2,3,5,8,13,20,40 och 100. Anledningen till att det är så många små tal och så få höga tal är att aktiviteter ska vara så små att de ska ta 1-2 dagar att genomföra. Ju längre tid en aktivitet beräknas ta desto större osäkerhet innebär det. Har man många aktiviteter på 20, 40 eller till och med 100 poäng bör man istället bryta ner dem till mindre aktiviteter.
Vad betyder då dessa siffror? Är det timmar? Någon pratar poäng, någon annan bananer, vinglas har jag stött på. Hur ska man tänka egentligen?
En första tanke är att det vore självklart att använda timmar, men det är inte det som är tanken. Siffran är tänkt att symbolisera en ideal arbetstimma i just ditt projekt/förvaltning. När allting flyter fritt från störningsmoment. Hur hittar man denna siffra då? Ta en uppgift som är väldefinierad som alla i gruppen är överens tar 4 timmar att göra. Låt denna bli er referensaktivitet. Utför sedan denna uppgift och se hur lång tid den faktiskt tar. Säg att den tar 8 timmar. Enhetstester måste ändras, incheckning mot rätt bransch, frågor ställs till beställaren till exempel. Uppgiften tog således 8 timmar istället för 4. Slutsatsen blir då att det tar oss 8 timmar att åstadkomma 4 timmars jobb. Förstår du nu problemet med att estimera i timmar. Byt istället ut ordet timmar efter 4 till poäng. Då blir förra meningen istället. Det tog oss 8 timmar att åstadkomma 4 poäng.
Om du nu delar antalet poäng med antalet timmar tillgängliga får du siffran 0,5. Den siffran är den som kallas för Velocity. Vad har man då för nytta av den?
Vi flyttar oss till Sprint Planeringen, kärnan i den agila systemutvecklingsmodellen Scrum. Det är tre veckor kvar till nästa demo för beställaren. Hur ska din gruppen veta hur mycket arbete de kan ta åt sig kommande sprint. Säg att det är 3 utvecklare på heltid, ingen semester planerad eller liknande. 360 timmars arbete finns inom ramen för sprinten. Då estimerar vi aktiviteter i Backlogen för 360 timmar och sen tar vi åt oss det. Enkelt. Eller?
Det är här vi har nytta av vår velocity. Genom att se tillbaka på föregående Sprintar och lära oss hur lång tid saker och ting faktiskt tar går det att göra korrekta estimat. I vårt enkla exempel ovan fick vi fram att Velocityn var 0,5. Därför borde gruppen ta Velocityn gånger antalet tillgängliga timmar för att få en mer rättvis bild och korrekt tidsuppskattning.
Men säger då någon ska man beräkna Velocity bara på en aktivitet?
Nej då säger jag. Det tar ett tag för en grupp att hitta sin Velocity. Stirra er inte blinda på en aktivitet. Titta istället på varje sprint. Dela antalet åstadkomna poäng med den tillgängliga tid som fanns och för statistik över er velocity. Efter ett antal sprintar kommer ni inse att ni hamnar ganska likt i sprintarna.
När velocityn är stabil kan man sedan göra en grov tidsuppskattning av sin Backlog för att enkelt se om projektet/förvaltningen kommer att kunna leverera på utsatt tid eller om något i Backlogen måste prioriteras antingen upp eller ner för att kunna nå målet.
Traditionens makt är stor. Varje gång vi behöver ett nytt IT-stöd ska det slås på stora trumman och initieras ett projekt som ska säkerställa att det blir rätt system och att det blir korrekt implementerat trots att vi gjort det flera gånger förut.
På dagens IT-avdelningar sitter en stor samling människor som är experter på att ta fram effektiva IT-stöd, men att få bedriva sin verksamhet i linjeformat det får man inte. Nej, det måste till ett projekt för att man ska få arbeta.
Projekt skiljer sig från linjearbete på flera punkter. Dels har ett projekt egen budget. Ett projekt har också en tydlig och avgränsad uppgift och ett antal personer knutet till sig.
Verksamhetsfolk knyts till IT-projekt för att lämna input och tycker ofta att det är kul att få vara med i ett projekt, men hur är det för IT-personer som näst intill ständigt arbetar i projektarbetsform. Ständig tidspress där du helst skulle levererat igår, problem med att få de resurser du vill ha och ständigt höga förväntningar på resultatet. I projekt finns det sällan toppar och dalar utan pressen att leverera hänger alltid över.
Ett IT-projekt slutar egentligen när det börjar. Ett IT-projekt avslutas med att systemet driftsätts i skarp miljö. Det är egentligen då det hela börjar. I många organisationer har man förvaltningar av IT-system men dessa bedrivs också i projektliknande former. Varje år blir som ett projekt med en planering, avstämning längs vägen samt ett avslut.
Jag skulle vilja se ett nytt perspektiv på styrning av IT. Istället för att hela tiden tänka projekt när man pratar IT kan man istället utgå från ett mer livscykelinriktat. Arbete med IT är inte en ax till limpa-process utan ett arbete som utförs kontinuerligt.Istället för att börja småskaligt och undersöka möjliga lösningar startas ofta IT-projekt upp med full bemanning och blir snabbt ineffektiva vilket får konsekvenser vid slutet av projektet där alltför ofta exempelvis test prioriteras ner.
Jag är inte på något sätt kritisk till projekt som arbetsform. Jag är bara skeptisk till hur det ibland hanteras och hur förvånansvärt lätt det kan vara att starta projekt.
I mitt förra inlägg här beskrev jag metoden Definition of Done, en metod för att definiera när en funktion är klar. Är det då tillräckligt för att veta när man är klar? Ibland kanske men ibland kanske det behövs något mer. Definition of Done säkerställer att vi gör utvecklar funktioner på rätt sätt. Men säkerställer en Definition of Done att vi gör rätt saker? Hur vet vi att det är rätt kod och rätt enhetstest?
Acceptanskriterier är ett hjälpmedel för att komma från dessa bekymmer. Acceptanskriterier används ofta vid acceptanstest men är också vanligt i agila metoder. Acceptanskriterier är de kriterier som en funktion minst måste uppnå för att vara godkänd. Kriterierna definieras när en funktion planeras. Genom att definiera upp acceptanskriterierna vet både den som beställt och den som utvecklat funktionen vad som ska fungera efter implementering.
Kriterierna kan enkelt dokumenteras i bara ett par meningar. Ett exempel på acceptanskriterier för funktionen Spara kund kan vara att:
• Det går att spara en kund.
• Det går inte att spara en kund med samma namn som en tidigare kund.
• Det ska gå att spara efter att ha uppdaterat information om en kund.
Acceptsanskriterierna utgör då en avgränsning av funktionen man ska utveckla och Definition of Done hur det ska utvecklas. Med stöd av teamets Definition of Done och dessa acceptanskriterier går det att effektivt utveckla nya funktioner till en IT-lösning.
– Jag ska bara skriva klart det här dokumentet.
– Jag ska bara få testerna att gå igenom.
– Jag ska bara checka in koden
– Jag ska bara…
Känner du igen dig? Tycker du också att mycket ofta är nästan klart och att det ofta förblir nästan klart. Inom agila metoder och arbetssätt är en viktig artefakt att diskutera just frågeställningen kring att visualisera status på sina arbetsuppgifter. Ofta finns tre kolumner definierade.
Ej påbörjad
Pågående
Klart
Men när får man flytta en arbetsuppgift till klart? Klart är väl egentligen en subjektiv bedömning? När jag diskar anser jag att disken är klar när jag diskat upp den, medan min sambo anser att det även inkluderar att torka disken och även göra rent diskbänken. Samma problem finns inom mjukvaruutveckling. Frågar du fem personer när en funktion är klar får du med stor sannolikhet olika svar. Detta ställer till problem när en tight grupp ska sitta och åstadkomma något tillsammans på en kort tid, säg tre veckor.
Lösningen på problemet är att tillämpa Definition of Done. Definition of Done är precis som det låter en definition på klar. Projektgruppen enas tillsammans vid uppstarten av projektet vad som ska krävas för att få flytta en lapp på projekttavlan till Klar-kolumnen. Definition of Done dokumenteras enklast i form av en checklista på de punkter som gruppen kommit överens om.
Definition of Done ger följande fördelar:
Hur ser en bra Definition of Done ut då? Som jag skrev ovan måste varje grupp enas kring sin egen definition men ett exempel kan jag ge er.
I ett systemutvecklingsprojekt/förvaltning gäller det att hålla isär åsikter från grisar och kycklingar för att bevara fokus i arbetet.
I ett projekt eller i en förvaltning kommer ständigt förslag på funktioner, förbättringar och ändringar in, men vem har egentligen rätten att få sin vilja igenom? Chefer, användare, kringliggande system. Förslagen kommer från olika håll och till slut vet man inte vad man lovat vem.
I den agila världen skiljer man därför på intressenterna i termerna grisar och kycklingar.
Grisar är de som är deltagare i projektet. Det är de som ständigt kreativt måste lösa de uppgifter som kommer in och tänka efter en gång till innan en ny funktion realiseras. Till grisarna hör vanligen projektgrupp, projektledare och produktägare.
Kycklingar är övriga intressenter som kläcker ur sig idéer och sen fortsätter med ordinarie arbetsuppgifter. Dessa åsikter ska inte bara tas in i arbetet utan måste behandlas på ett strukturerat sätt, exempelvis via forum och referensgruppsmöten. De synpunkter som betraktas som bra ska sedan verkställas av ”grisarna”.
Det här tankesättet brukar beskrivas med följande seriestripp.
Har du hört talas om begreppet dokumentera mera? Tänkte nästan det. Men dokumentera mindre då?
Varje dag skrivs en mängd dokument med syfte att dokumentera systemutveckling, men har du någon gång reflekterat över varför du skriver ett visst dokument. Kanske har du känt att du skriver för blinda ögon ibland. All tid som läggs påonödig dokumentation kostar timmar. Timmar som kunde lagts på att utveckla ny funktionalitet.
I det Agila Manifestet som författades 2001 gjordes ett tydligt ställningstagande kring dokumentation. Dokumentation är viktigt, men fungerande mjukvara är viktigare. Du ska inte dokumentera förrän du har en fungerande IT-lösning. Att poängtera är att fungerande i detta fall inte är det samma som färdigutvecklad. Fungerande pekar mer på en specifik funktion i en IT-lösning.
Att dokumentera först när en funktion fungerar skapar förutsättningar för att dokumentationen blir korrekt. Att dokumentera något som inte är fastställt i detalj innebär merjobb med att ändra i dokumentationen om det visar sig att funktionen måste kodas om. Dokumentera därför aldrig något som inte är fastställt eller inte fungerande. Fokusera istället på att få IT-lösningen att fungera istället för att dokumentera hur IT-lösningen borde fungera.
Dokument brukar bli omfattande. Omfattande dokument är svåra att hålla uppdaterade när en IT-lösning ständigt förändras. Ofta är det också så att dokumentation prioriteras lägst och görsi mån av tid. Till slut vet ingen hur IT-lösningen fungerar eftersom dokumentationen inte uppdaterats på flera år.
Hur kan man då arbeta med dokumentation för att undvika det här?
Eftersom uppdatering i dokumentation historiskt sett är eftersatt på många håll bör man se till att ha så lite dubbellagrad information som möjligt. Helst ska den mesta informationsmängden inte finnas i dokumentform. Istället är exempelvis testfall ett oerhört kraftfullt sätt att beskriva hur en IT-lösning ska fungera (positiva testfall) men även inte fungera (negativa testfall). Testfall är något som används i det dagliga arbetet och man är därför mån om att dessa ständigt är uppdaterade.
Koden bör vara välkommenterad eftersom det är lättare att uppdatera kommentarerna när man redan ändrat i koden på samma ställe.
I exemplet ovan finns den detaljerade beskrivningen av en IT-lösning direkt i koden och i testfallen. Ofta finns också en övergripande systembeskrivning. Denna kan med fördel dokumenteras i ett dokument. Denna beskrivning ändras inte särskilt ofta och när den väl gör det är ändringarna så pass små att det är lätt att uppdatera dokumentet.
Granskning då?
En vanlig metod för kvalitetsgranskning är att granska dokument. Man utgår då ifrån att det som står i ett dokument är sant. Verkligheten är tyvärr ofta en annan. Beslut fattas utifrån hur en IT-lösning borde fungera och inte hur den faktiskt fungerar. För att råda bot på detta fenomen bör man som granskare istället för att granska dokument få tillgång till IT-lösningen och titta direkt i exempelvis kod eller testfall.
Självklart finns det dokument som måste tas fram för att kunna leverera en högkvalitativ IT-lösning. GEM arbetar med att ta fram dessa dokument men vi fokuserar på att hålla den obligatoriska nivån så låg som möjlig för att underlätta för flexibilitet. Olika dokument behöver tas fram beroende på IT-lösningen. Därför bör man endast producera dokument först när de efterfrågats för att kunna motivera investeringen i ett dokument.
Just nu pågår VM i Rugby. Jag fick på det häromdagen och satt och tittade på Nya Zeeland mot Argentina. Rugby är ingen sport som brukar få så mycket TV-tid så jag tänkte att jag skulle ge det en chans. Nu undrar du som läser kanske om jag ska debattera om TV-tider för rugby? Du kan vara lugn det ska jag inte.
Det är nämligen så att Scrum har sitt ursprung i just Rugby. 1986 presenterades artikeln “The new new product developement game” av de japanska forskarna Takeuchi och Nonaka. Forskarna hade kommit fram till att flexibilitet i produktion var en faktor som var minst lika viktig som hög kvalitet och låg kostnad vid produktutveckling.
Författarna presenterade i artikeln ”The rugby approach”, som innebär att initialt skapa en helhetssyn och därefter ”spela bollen” mellan sig för att nå resultat. Författarna pekade även på sex karaktärsdrag för den ”nya nya” produktutvecklingen.
1. Inbyggd instabilitet
2. Självorganiserade projektgrupper
3. Överlappande projektfaser
4. Multipelt lärande
5. Minimal kontroll
6. Kunskapsutbyte
Med dessa idéer i bakhuvudet skapade Ken Schwaber Scrum i mitten av 90-talet. Ordet Scrum översätts till klunga och är det ord som beskriver klungan som bildas när bollen sätts i spel inom rugbyn. Namnet är tänkt att peka på de likheter som finns mellan sporten och modellen.
Tomas Gustavsson som pratade på Galaxen för ett par veckor sen nämner tre av desa likheter.
Jag har hittat en fjärde likhet (Finns säkert någon annan som vill göra anspråk på att vara först). För att komma framåt i rugby måste bollen kastas bakåt. Ett Scrum Team måste hela tiden se tillbaka på sin process för att göra den bättre och för att komma framåt i systemutvecklingsprocessen.
Det här var en kort historielektion. Nu åter till nutiden och svaret på den stora frågan ni väntat på.
Hur gick det i rugbymatchen?
Vinst för Nya Zeeland med 33-10
I torsdags bytte vi månad igen. September står det i kalendern. Det fick mig att tänka över min vardag i ett Scrumperspektiv. Jag vill mena att vår vardag är betydligt mer agil än man först kan tro.
Tänk dig nyårsafton. Javisst det är tag kvar dit men vad brukar du göra då. Jag brukar åtminstone ägna en liten stund åt att tänka på vad jag åstadkommit under året. Men även lite övergripande på vad som händer nästa år.Vi tar ett exempel.
Mamma fyller år i februari, kompisen ska bli pappa i juli, och semester i USA i september. Helt naturligt väljer jag att fokusera på mammas födelsedag eftersom det är det viktigaste just nu. Samma är det i systemutveckling. Prioritering av aktiviteter ska göras utifrån det som är viktigast i nuläget.
Eftersom min mamma inte fyller år förrän i slutet av februari känner jag ändå inte att jag behöver stressa med mitt paket inköp i januari. Under januari får jag inbjudan till fest i mars, tandläkaren bokas in i februari och jag anmäler mig dessutom till en löpartävling i september. Händelserna noteras i kalendern, som liknas vid min egna Product backlog.
Den första februari vänder jag blad på kalendern. En snabb överblick av kalendern prickar in månadens aktiviteter. Mammas födelsedag och tandläkartiden. Jag gör en snabb planering i huvudet över aktiviteterna. Kontrollerar så tiden till tandläkaren är noterad i min arbetskalender så jag inte missar den. Jag har nu gjort min det som kallas Releaseplan i Scrum. Jag har på ett övergripande sätt tagit reda på de viktiga aktiviteterna i denna månad.
Tänk dig nu framåt ett par dagar. Det är idag (måndag den 5 september). Jag kommer till jobbet, slår på datorn och öppnar outlook. Det första jag gör är att kolla kalendern. Just det. Tandläkaren på Torsdag klockan 10:00. Och en från 9:30-11:00. Nu måste jag dels meddela en kollega att jag inte kan komma till mötet på torsdag och dels måste jag se till att ha bilen till jobbet på torsdag eftersom Tandläkaren är på andra sidan stan. Jag måste nog även försöka gå lite tidigare från projektmötet som slutar 9:20. Jag har nu skapat 4 aktiviteter som måste genomföras innan tandläkarbesöket kan betraktas som klart.
Jag har med Scrum-ord tagit ett krav (User Story) och brutit ner det i aktiviteter som krävs för att kravet ska betraktas som klart.
Eftersom mammas födelsedag ligger först tre veckor bort avvaktar jag med hennes present till kommande veckor.
Torsdagen kommer. Jag öppnar mailboxen och kollar återigen kalendern om jag på måndagen gjorde en veckoöversikt kollar jag nu mer specifikt på torsdagen. Jag noterar min tandläkartid, men också ett möte på eftermiddagen. Kollar mailboxen och ser att en kollega vill ha hjälp. Däremot inget svar på min fråga jag skickade till en annan kollega. Jag mailar min första kollega och säger att jag återkommer till henne efter lunch. Jag upplever att min dator går segt och skickar därför ett mail till IT-supporten som upptäcker ett fel efter nattens uppdatering.
Jag har nu haft mitt dagliga möte med mig själv. Jag har planerat vad jag ska göra under dagen, uppdaterat mig om gårdagen och angripit de problem jag har?
Dagen löper på helt utan bekymmer.
Till slut är det fredag eftermiddag. Jag lägger lite extra tid på att sortera upp i mailboxen, lägger papper till rätta. Kollar kalendern och inser att allt du skulle göra vad gjort. Det blev lite stressigt tillbaka till jobbet efter tandläkaren, men det löste sig till slut. Jag stämplar ut och går hem. På måndag är det ny vecka.
Jag har där gjort din Sprint Review med mig själv och även hunnit med lite retrospektiv.
Hur agil är du?
Tankar om Agile 