Man lär så länge man lever! Håller på att läsa en bok om agil testning. Där lyfter författarna fram skillnaden mellan test-driven development och test-frist development. Om man kollar runt på nätet så verkar en del tycka att att det verkligen finns en skillnad, medan andra menar att det är samma sak. Men, för att ägna sig åt lite hårklyveri:

Test-first development. En av praktikerna i XP. Man känner till kraven, men framför allt designen i förväg, och skriver testerna först för att driva implementationen av dem.

Test-driven development. Förfining av test-first development, men innefattar också evolutionär design, d v s att koden driver fram designen, som man inte känner till á priori. 

Min mening är att man hamnar precis däremellan om skriver kod genom att testa först. Det som gör test-driven development lite roliga än test first är att man inte riktigt vet hur den slutliga koden kommer att se ut. Den evolveras berkligen fram!

Man lär sig alltid någonting nytt! Jag läser för närvarande boken Implementing Lean Software Development av Poppendieckarna. Den sammanfattar agil utveckling på typ 10 sidor och innehåller en hel del visdom. Däri har jag för första gången träffat på begreppet Set based design.

Set based design handlar om att ta fram flera alternativa lösningar till ett och samma problem och låta den bästa överleva. Det är främst en riskreduceringsstrategi som är lämplig att använda om man MÅSTE leverera ett visst datum. Då föreslås det att man t ex drar igång tre parallella spår.

Spår A: minimi som kommer att funka

Spår B: bra design som kommer att fungera snyggt och långsiktigt

Spår C: bästa möjliga design, som delvis bygger på erfarenheter från spår B. 

Vid leveransdatum väljer man alltså det mest färdiga spår, som ger bäst kvalitet, samtidigt som man är garanterad att den enklaste lösningen finns implementerad som ett skyddsnät.

Givetvis kan man diskutera ekonomin i att göra “dubbelarbete”, eller om Spår A alltid blir klart. Man inser också att man naturligt hamnar i set based design om man arbetar någorlunda agilt. Det roliga är dock att ha ett namn på något man gör och en formaliserad kunskap om det. Djupare analys lämnas till framtida inlägg.

Att refactoring är premissen för samtliga agila metoder har jag som premiss. Detta leder till intressanta diskussioner när man möter folk som lägger en annan betydelse i ordet. Själv använder jag definitionen: små, kontrollerade ändringar, som bevarar kodens funktionalitet.

Ibland är jag inte så duktig och kompletterar detta med: …och kanske någon liten förbättring. Ingen är perfekt. På vår sommarfest förra veckan fick jag dock höra följande (citaten är inte exakta, men andemeningen är infångad):

D: A (som är projektledare) blir helt stel när han hör ordet refactoring. Det är svårt att motivera att man gör om något som fungerar för kunden.

A: Ja. Refactoring tar en massa tid.

D: Och producerar inget värde. Fungerar koden, så ska man inte röra den.

A: Absolut! Dessutom är det sällan man har tid att skriva om en massa kod, fastän det är dåligt.

D: Ja. Små refactorings på 3-4 timmar går bra, men att skriva om så mycket att projekted blir lidande… Det går absolut inte.

Var ska man börja? Har man så dålig kod att man måste skriva om den, då är det inte direkt refactoring som är problemet…

Vidare tycker jag att det är jättekonstigt att inte inse vilket värde refactoring faktiskt tillför på sikt i avseende på underhållskostnader. Om man arbetar agilt (vilket väldigt få verkar göra när det kommer till kritan), så löser man sitt specifika problem, och arbetar man dessutom med TDD, så blir det så definitivt. Den kod som löser det specifika problemet kan vara perfekt… ända fram till nästa iteration där ett nytt specifikt problem har dykt upp. Här kan man välja två vägar.

Antingen bygger man på bredden, d v s implementerar lösningen på det nya problemet helt frikopplat från det föregående (inte röra fungerande kod), eller så transformerar man koden så att den i största möjliga mån löser bägge problemen. Det senare fallet kräver att man tänker efter, har tester och rör fungerande kod. Avkastningen är konceptuell integritet och en kodbas som går att underhålla. Alternativet är en otestbar gegga som ingen begriper och som löser samma problem på flera olika sätt. Att unifiera lösningarna i efterhand brukar sällan gå att göra till en rimlig kostnad.

Refactoring är således (förutom den självklara förutsättnignen för TDD) även ett sätt att säkerställa att framtida undehålls- och vidareutvecklingskostnader hålls ner. Eftersom kostnader=pengar=tid, så bli time to market också beroende av kodens kvalitet, som ju upprätthölls genom refactoring.

Har man inga bra argument så kan köra med detta en aning lama:

Förra iterationen ville vi komma över bäcken. Då lade vi en planka på tvären och fick en bra. Det fungerade.

I denna iteration vill vi att även bilar ska komma över. Vi hade kunnat lägga flera plankor bredvid varandra och hoppas att de håller, men om vi tar bort plankorna och gjuter raka betongfundament, och lägger dit dem igen, så vet vi att de inte knäcks eller glider iväg.

Jag har läst några böcker om agila utvecklingsmetoder (tyvärr inte tillräckligt många), och hört en eller annan presentation av t ex Scrum. Det som har slagit mig i ett tidigt skede är att de agila metoderna inte problematiserar kring arktitektrollen särskilt mycket, och när det inträffar så hör man att arkitekten inte ska sitta i sitt “Ivory tower”, utan vara med i teamet. Innan jag läste på lite på bloggar och i forum, så ville jag själv problematisera kring tre områden som blir lidande när arkitektrollen försvinner:

Kodpolisen: någon måste ansvara för coding conventions, dokumentstandarder och informaitonsinfrastruktur.

Konceptuell integritet: detta är ett ord som sällan nämns i den agila världen, eller i alla fall av dem som vill sälja in agil utveckling. Mina erfarenheter är att konceptuell integritet är extremt svår att upprätthålla som team. Kostnaden för att lyckas är otroligt mycket kommunikation.

Icke-funktionella krav: dessa ska vara lösta inom scope för varje story… På pappret.

Sedan läste jag som sagt på lite och hittade lite fakta kring den agila arkitekten. En agil arkitekt är inte bara en stenhård utvecklare, han är också testare, försvarare av den konceptuella integriteten, mentor, balanskonstnär av affärsnytta/kvalitet/fungerande lösning, men framför allt en extrem team player och superb kommunikatör.

Allt detta låter vettigt, men pitchar man agila metoder måste man hitta praktiska former för hur allt detta ska ske. Hur jobbar akritekten? Har han egna tasks/stories, inte så förenligt med det jag vet om t ex XP och Scrum. Jobbar han istället med alla andra och försöker “få in” arkitekturen i de andras tasks? Har han mandat att köra över enskilda teammedlemmars designval? Hur ser hans dagliga rapport ut?

Dessutom, om rollen blir en duktig allt-i-allo. Är det lätt att motivera när man bildar nya team som ska jobba med “affärsnytta”. En Ivory tower-akritekt låter tungt i alla fall…

Som i en tonårings dagbok… Bara frågor, inte svar.

En kul grej att läsa kan vara “Who needs an Architect” av Martin Fowler. Handlar inte riktigt om detta problem, men kort och tänkvärd läsning.

Detta problem har vårt team råkat ut för vi ett flertal tillfällen, och det är kanske dags att försöka formalisera det. Problemet torde vara lika stort i både Scrum och XP, eftersom bägge bygger på att stories bryts ner i uppgiftslappar.

Det finns en massa fel man kan göra här, och det största torde vara att skapa stories som medger horisontell indelning, alltså: en lapp blir “Webb”, en annan blir “Business-lager”, och den tredje blir kanske “Databas”. Denna läxa är dock lärd, och vi går vidare till det verkliga problemet.

Vad den bakomliggande orsaken är kan man spekulera i: otillräcklig kunskap om storyn, dålig story, eller bristande engagemang i planeringen. Resultatet blir dock att teamet kan planera fram en taskindelning som innehåller en personberoende kritisk linje!

Vid sprintens början ser tavlan bra ut. Vi har tre stories (på samma tema, men olika) med elva olika tasks. Om nu utvecklaren Kalle plockar Task 1 och utvecklaren Jesper tar Task 3 i samma story kommer allt att fungera. Nästa dag har Jesper blivit färdig, medan Kalle har stött på problem, men också upptäckt att Task 2 i själva verket har ett beroende till Task 1, som måste bli färdig först. Då det inte är någon idé för Jesper att plocka Task 2, plockar han Task 4.

Nästa dag är Jepser åter igen färdig, medan Kalle förklarar att Task 1 var svårare än teamet förutspått och bryter ner den till Task 1a och Task1b, varpå han förklarar att Task 1a är klar och att han nu förstått problemet med Task 1b, men behöver en dag till. Tyvärr är det Task 1b som begränsar Task 2.

Eftersom teamet består av flera utvecklare har samtliga lappar förutom Task 1b och Task 2 blivit klara, och teamet börjar på den andra storyn i väntan på att Kalle blir klar. Dock visar det sig att när någon väl plockat Task 2 i den andra storyn, så skriker Kalle att denna delar funktionalitet med Task 2 i den första storyn… Hur den sista pilen i bilden uppkommit kan man gissa sig till vid det här laget…

Detta mönster kan försena en hel sprint och det är tyvärr inte så enkelt som att teamet estimerat fel och borde haft andra lappar. Det är inte heller så enkelt som att alla beroende tasks kan slås ihop till en enda.

Hur dylika planeringsfel uppkommer, och hur man handskas med dem borde kunna mata många inlägg till. The story doesn’t end here…

Att sitta ihop är en av grundpelarna i XP. Tanken är att parprogrammering ska reducera antalet defekter och bidra till kunskapsöverföring. Vidare är det tänkt att det surr som uppkommer när ett antal par arbetar ihop i ett enda öppet landskap ska skapa det Shore och Warden i boken “The Art of Agile Development” kallar “osmotisk kommunikation”. De arbetande paren ska, i bakgrunden, höra saker som angår dem och eventuellt spontant ge sig in i diskussioner. Ljudnivån anses inte vara ett problem, eftersom par kommer in i flow på ett annat sätt. Detta kan jag hålla med om, MEN…

Shore och Warden berättar också att en programmerare som arbetar solo som blir störd behöver 15 minuter för att komma tillbaka. Räkneövning: Hur många minuter behöver en soloprogrammerare för att komma tillbaka under ett konstant surr och ständiga avbrott?

Vissa uppgifter är svåra att utföra i par; att skriva komplexa algoritmer eller vanliga textdokument kan vara två exempel. Vad gör soloprogrammeraren då? Shane och Ward menar att hörlurar, öronproppar eller “att flytta bort en bit” löser problemet. Vad händer om man inte är duktig på att skriva dokument med musik i öronen? Vad händer om man inte kan flytta bort p g a platsbrist, eller helt enkelt har en dag man inte vill arbeta i par? Öppna frågor allihopa…

Två av Scrums fundament kan tillsammans bidra till kvalitetsbrister om en grupp ovana eller ovetande utvecklare anammar processen. Kombinationen utgörs av tidsestimering inom Sprint planning samt Daily standup.

Tidsestimeringen görs av hela gruppen. Alla får säga sitt och den kan göras än mer sofistikerad genom Planning Poker. Givet att gruppen får tillräckligt med tid har den producerat tidsestimat som alla medlemmar mer eller mindre tror på.

Daily standup garanterar transparensen i Scrum. Genom att alla varje dag får berätta om vad de pysslat med, vad de tänker göra härnäst, samt huruvida de har stött på patrull, kan såväl gruppen som vilken utomstående som helst ta tempen på sprinten.

Om en ny, ocan och icke samspelt grupp anammar processen kan dock detta case inträffa:

Gruppen gör sitt bästa för att tidsestimera under planeringsmötet, men kommer trots konsensus inte fram till verklighetsanknutna estimat, kanske p g a bristande rutin, eller dåliga krav.

En ovan utvecklare utan pondus och insikt om att gruppens estimat kan vara helt åt skogen tar en lapp estimerad till x timmar. Uppgiften visar sig vara svårare än väntat och utvecklaren måste på standup-mötet efter x timmar säga sig behöva minst x timmar till. När dessa är förbrukade börjar utvecklaren bli stressad och säger sig behöva, säg x/2 timmar och använder dessa för att leverara någonting med undermålig kvalitet, bara för att inte känna av lappstressen. Denna stress uppkommer främst, tror jag, p g a utvecklaren känner att tidsestimatet varit genomklubbat av hela gruppen och kan inte vara felaktigt. Den naturliga konsekvensen är att utvecklaren känner sig dålig och gör allt för att bli av med Svarte Petter.

Detta problem inträffar inte lika ofta i en grupp mer erfarna utvecklare, och framför allt mer erfarna inom Scrum, förmodligen p g a:

1) Den erfarne utvecklaren vet att snabba omröstningsbaserade estimat lätt blir fel om någon detalj glöms bort, och att det är helt i sin ordning att revidera dem.

2) Gruppen i sig vet om detta och bidrar aktivt till att hjälpa personer med för stora lappar att klyva dem om någonting oväntat inträffar.

Kanske inte världens största problem, men värt att ha i åtanke om man introducerar Scrum i en ny grupp.

Detta kanske är så självklart att det är pinsamt att nämna, men det är bra att ha en stark rubrik för att inte glömma det basala.

En av premisserna bakom agila metoder är att man inte planerar mer än nödvändigt för att klara den kommande iterationen. Detta leder till att man kan hamna i situationen där en planerad modifiering, som verkade vara ett lätt och avgränsat arbetspaket, i själva verket påverkar mer av systemet är man önskar. I detta läge har man två val:

1) Skygglappar på; bygga in sin modifikation “på bredden”, vilket medför lite copy’n paste, lite duplicerad funktionalitet, men också att vi arbetar utanför fungerande delar av systemet och kan i 99% av fallet inte paja något som fungerar.

2) Stanna upp, tänka efter, göra om, göra rätt. Vi stannar till och gör vårt yttersta för att få det existarande systemet att innefatta den nya logiken. Detta gör vi genom refactoring. Är systemet vi underhåller väldigt dåligt och saknar testtäckning, får vi kanske träna en hel del på dependency breaking också. I ett bra system finns redan tillräcklig testtäckning för att på ett säkert sätt genomföra sin refactoring.

Metod 1 brukar användas om vi inte vet någonting om systemet vi modifierar (och det saknar tester), och brukar framför allt förespråkas av okunniga projektledare som tror att de kan det där med “business”, kundnytta, och “good enough software”.

Metod 2 är det enda sättet att få lättrörlighet (och underhåll) att fungera på sikt. Det är nämligen så att byggande på bredden, som jag kallar det, leder till att vi får system med moduler som gör snarlika saker (t ex fyra olika klasser gör nästan samma sak), som per definition får sin konceptuella integritet urholkad, och som blir svåra att dokumentera och underhålla. Läggs detta ihop med faktum att 70+ procent av alla kostnader för ett system är underhållsrelaterade, så behövs inga fler argument.

Hur vi sköter vår oförutsedda refactoring inom iterationen är en stilfråga. Antingen accepterar vi att detta är priset för agila metoder och reviderar tidsestimatet för arbetspaketet, eller så skapar vi en så kallad “tech story” och börjar arbeta med den. Själv förespråkar jag det första alternativet med argumentet att vi inte lyfter fram faktum att vi skriver en for-loop, och vi behöver inte lyfta fram faktum att vi anpassar det existernade systemet för att fungera med vår nya funktionalitet.

Det man absolut inte får göra är att skjuta fram sin refactoring till nästa iteration, för då hamnar man i “metod 1″ och får det aldrig gjort!