05.30.08
Parprogrammering – den okända manualen
Vi vet idag att parprogrammering egentligen är fruktansvärt effektivt. Det finns skäl att tro att parprogrammering i kombination med TDD kan ta bort 90-97% av felen. [1] Dom här felen är irriterande, otroligt jobbiga att fixa i efterhand när ingen längre kommer ihåg hur det var tänkt, men framför allt kostar de mycket pengar. Plus en massa andra bra saker, som att fler ser mer kod och man inte blir så personberoende.
Så varför gör vi det inte mer? Ett skäl till det är att det är så förbannat svårt att trivas bra med (det finns andra skäl, som att chefer eller kunder tror att tangentbordet är den trånga sektorn och inte hur snabbt vi kan lösa problem, men det är en annan historia). Jag har haft några av mina roligast stunder som utvecklare när jag har parprogrammerat. För det är ju kul att jobba tillsammans på ett gemensamt problem och lösa det. Att dela den där svindlande känslan av att klarat av ett svårt problem. Wow! Men jag har också upplevt oerhört frustrerande stunder. När magen har morrat och andningen varit kort av irritation. När allt man har längtat efter är en kopp kaffe.
För vad det kan vara värt, här kommer några knep för att lyckas med parprogrammering som har fungerat för mig.
Ping-Pong-Kingen
Folk vet att man ska byta tangentbord ofta, men håller ändå tangentbordet hårt timmar i sträck. Det är oerhört lätt, jag gör det själv. Men det duger inte. Att sitta och titta på när någon programmerar i ett par timmar är tråkigt intill döden, trots att du försöker allt som du kan för att engagera dig.
Så jag ska ge er ett tips: Använd Ping-pongprogrammering. Det fungerar så här: Du skriver ett test som inte går igenom. Din partner får sedan skriva enkel kod som får testet att fungera. Sedan skriver hon ett test och då är det din tur att få testet grönt. Superenkelt! Och det fungerar. Inte nog med att tangentbordet byter ägare med några minuters mellanrum, dessutom blir båda parter mer engagerade. Det är nästan så att ett litet tävlingsmoment uppstår. ”Ok, nu j-klar ska jag ge dig ett svårt test att klara av.” Och av en ren slump så kör ni perfekt, disciplinerad TDD, bara en sån sak.
Så starta idag! Bli Ping-Pong-Kingen på din arbetsplats.
Promiskuös parning
Nästa sak man kan läsa om parprogrammering är att man ska byta partner ofta. ”Varannan dag typ?”, kanske många tänker. Många verkar idag sitta med samma partner dag ut och dag in. Allt känns tryggt och fint. Visst blir ni förbannade ibland och visst kan ingen annan er kod, men det känns ju så lugnt och skönt. Mmm…
Nej nej, det duger inte. Parprogrammering är inte bara en ständigt pågående granskning av kod, det ska också vara ett sätt att flytta runt personer så att alla lär sig stora delar av systemet. Det ligger i allas intresse. Större variation för deltagarna, mindre personberoende för cheferna. Och vad säger det om teamkänslan när ni har ett litet team i teamet?
Men jag kan ge ett litet tips: Använd promiskuös parning. Det låter lite knäppt på en arbetsplats, men det fungerar så här: Var och en i teamet har en uppgift, tagen från till exempel en sprintplan. När du ska lösa en uppgift tar du en uppgift som du kan ganska lite om. Du måste be om hjälp. Om istället någon ber dig att hjälpa till måste du tacka ja. Här kommer det viktiga: Ni får bara arbeta tillsammans i max 90 minuter. Sedan måste ni byta partner. På en dag kan du alltså ha tre – fyra partners, vilket kanske känns spännande bara det.
Det sköna med detta är att ni aldrig hinner tröttna på varandra. Även om du får jobba med petimetriske Olof eller ständigt negativa Ulla så visst klarar du av några timmar? Och jag lovar, Ulla är inte så neggig som man kan tro, när man väl har lärt känna henne.
Så börja redan idag! Hur många partners kan du få till innan dagen är slut?
Fotnot: För fullständig promiskuös parning krävs också att ingen stannar vid samma uppgift genom hela utvecklingen och att varje uppgift ges till den minst kunnige inom området. Enligt forskning ger detta högre produktivitet. Läs mer i forskningsrapporten, om du är intresserad.
Moccamaster
Men hur ska vi komma ihåg att byta partner? Enkelt, i Sverige har vi en enorm fördel som de inte har i andra länder: Fika! Tiofikat och trefikat är perfekt tider för partnerbyten. Lägg till ett byte vid lunch och du har delat in dagen i fyra perioder. Dessutom får du lite paus för att rensa hjärnan mellan bytena. Rekommenderade ministorleken på en uppgift i Scrum är 1-2 timmar och det är ju perfekt! Det är ju exakt den tid ni får om ni delar in dagen i fyra delar. Och det passar också utmärkt för maxtiden 90 minuter.
Fikar ni inte längre på ert jobb? Så… modernt. Fundera gärna på att återinföra det. Kanske fanns det någon poäng med de där fikastunderna förutom att få i sig koffein? Kanske behöver din hjärna tänka på något annat? Kanske lära känna folk i projektet kan göra det lite roligare ändå? Kanske Ruben från det där andra projektet har haft samma problem med CruiseControl som vi? Och nej, jag menar inte betongsverigefika på 45 minuter. Femton sköna minuter av mys räcker för att vara högproduktiv igen när du väl kommer tillbaka.
Vad väntar du på? Gå iväg och brygg en hederlig gammal kanna åt teamet. Bli Moccamaster pronto.
Använd en P3
”Ok, det här låter väl schysst, men det fungerar ju inte. Människor vill känna att man avslutar saker. Om man nu har satt sig hos Karin och påbörjat någonting så vill man ju bli klar.” Ja, jag håller med, flow är viktigt. Problemet är bara att det då stör rytmen för alla andra som behöver byta partner. Och snart blir det heldagar tillsammans. Eller flera dagar. Nej, det duger inte. Vi vill att flera personer ser den där ”smarta” koden som ni håller på med. Vad händer annars när ni drar på kärlekssemester tillsammans?
Men jag ska ge er ett tips: För varje session skapa en P3, en parprogrammeringsplan. ”Äsch, mer planer, jag trodde inte man planerade i agila metoder?” Eh, jo, vi planerar bara väldigt lite väldigt ofta istället för allt på en gång i början. Men det är enkelt, en P3 är inget annat än de steg ni behöver ta för att klara av den uppgift ni har satt er för att göra. Skriv en lista av punkter, typiskt en handfull, det första ni gör tillsammans. Lämna lite utrymme emellan dem för saker som ni kommer på under arbetets gång. Låt den som är kartläsare (bisittaren) sköta planen. När ni byter tangentbord byter ni också blocket. Och här kommer det sköna: Även om allt går åt pepparn och ni bara hinner med några punkter på listan så kommer ni ändå känna att ni har klarat av någonting och kan utan emotionella störningar gå vidare till nästa partner. Ett par saker bortstreckade i alla fall. Inte illa så!
Så sätt igång: Bli P3-chef på en gång.
Referenser
[1] Joakim Sundén, Avega, föredrag på Developer Summit, Stockholm, 2008. Joakim hänvisar till Steve McConnells bok ”Code Complete: A Practical Handbook of Software Construction” som i sin tur hänvisar till Shull et al ”What we have learned about fighting defects”, 2002
05.16.08
Recension: Implementation Patterns av Kent Beck
”Implementation Patterns” av Kent Beck var hett efterlängtad när den kom. Äntligen en ny bok av Kent! Motsvarade den våra förväntningar eller var våra förhoppningar för högt ställda?
Kent Beck var en av upphovsmännen bakom designmönster i mjukvara (tillsammmans med Ward Cunningham), men han skrev inte boken (”Design Patterns”). Kanske har han ångrat detta och velat hitta ett nytt område med nya mönster? Hur som helst, vi har all rätt att ha höga förväntningar på en patternsbok av Kent Beck.
”Implementation Patterns” är tänkt att ligga nivån under ”Design Patterns” i abstraktionsnivå och behandlar sådana beslut som programmerare måste fatta hundratals av varje dag: Vad ska den här variabeln heta? Ska den här klassen kunna subklassas? Hur kan jag bli av med det här duplicerade beteendet? Etc. Detta är inte en bok om stil, utan om kommunikation.
Mönsterna avhandlas på snabba 130 sidor i form av 77 mönster i en lös patternform, dvs utan strikt struktur. Det finns kapitel om klasser, beteende, metoder, tillstånd och kollektioner. Till detta finns några inledande kapitel som introduktion och ett avslutande kapitel om speciella hänsynstaganden vid skapandet av ramverk.
Till att börja med måste jag säga att jag finner syftet med boken både lovvärt och originellt. Att få oss programmerare att inte bara tänka på att skriva enkel, lättläst kod utan också fundera över vad vår kod kommunicerar till en kodläsare är viktigt men ovanligt. Ett exempel på hur man kan tänka: ”Hmm, här har hon valt ett Set… ok, det betyder att det inte få finnas några dubletter i mängden… men ingen implicit ordning mellan elementen…”. För någon som ska ta över vår kod är detta skillnaden mellan en straffspark och ett år i kvalserien.
Som programmerare känns boken relevant. Den berör verkligen sådant som man måste fundera på varje dag. En del saker kanske en erfaren programmerare gör lite med ryggmärgen, men det är kanske inte alltid det är det bästa. Det finns bra saker här och koden är verkligen trevlig att se. En del saker känns ganska grundläggande.
Att Kent valt en lös form på mönsterna tycker jag är bra, därför att olika saker måste presenteras på olika sätt, men å andra sidan ser jag inte riktigt var mönster kommer in alls, annat än att namnen är ”mönstriga”, så att säga. Kapitlena är mest korta utläggningar om olika ämnen. Det finns inga indelningar alls.
Boken använder Java som exempelspråk, vilket säkert är enklast för många läsare, men ibland blir det lite för javaspecifikt. Kapitlet om kollektioner känns som en enklare sammanfattning av det som Joshua Bloch redan har skrivit.
Som alltid med Kents böcker är boken kortfattad. Jag misstänker att han medvetet eftersträvar en kort och enkel form då det korta och det enkla är syskon med det sköna. Och det fungerar på mig.
Kent skriver på ett speciellt sätt, speciellt de senaste åren. Hans stil är väldigt mjuk och försiktig, vilket känns sympatiskt och låter klokt, men jag kan känna att jag saknar lite spets och attityd. Ungefär så långt ifrån David Heinemeier Hansson som man kan komma. Och får man föreslå lite humor ibland för att lätta upp?
Det kanske märkligaste med denna bok om att tänka på vem man kommunicerar till är att det är precis det man undrar om boken själv: Vem kommunicerar Beck till? För den erfarne finns det några guldklimpar, men det mesta har denne sett förut. För nybörjaren är själva konceptet kanske för svårt? Om man knappt klarar av det dagliga kodknackandet kanske man inte har börjat fundera på hur den som läser min kod uppfattar den? (Tack, Joakim på Avega för den insikten.) Kanske någon med ett par, tre års programmering bakom sig i Java är idealet, men det är väl allt en ganska liten målgrupp för en bok?
Sammanfattningsvis: Det är tyvärr inte en blivande klassiker jag har framför mig på bordet. Den är varken rättmätigt upprorisk som Extreme Programming Explained i första utgåvan eller majestätiskt mäktig som ”Design Patterns” eller ”Patterns of Enterprise Application Architecture”. Syftet är strålande, den är bitvis välskriven och har en del guldklimpar. Det man kan sakna är attityd och lite humor. Det svåraste för den här enkla boken blir nog ändå att hitta sin rätta läsare. De som bryr sig om sin kod kan mycket av detta. De som mest ser programmering som ett jobb kommer nog inte att bry sig.
05.10.08
Thoughtworks i Stockholm – en konsekvensanalys
Det ser allt mer klart ut att Thoughtworks (TW) öppnar kontor i Stockholm. Vad skulle detta betyda för konsultmarknaden i Stockholm? Att ett bolag som TW gör sitt insteg på marknaden kommer givetvis ha konsekvenser, men vilka?
Bakgrund 1: Thoughtworks är ett av de mest respekterade konsultbolagen överhuvudtaget. De är internationella och har rykte om sig att vara mycket duktiga. De har en tydlig agil profil, en lång rad innovationer och bra verktyg på sitt samvete (CruiseControl, Selenium och Mingle för att nämna några), en spännande och karismatisk grundare, en stark företagskultur och, sist men inte minst, Martin Fowler, världens bästa ”loud mouth” (enligt min mening), i företaget plus en hel rad andra kända namn.
Bakgrund 2: Dan North, en av Thoughtworks konsulter, anställd nr 1 i England och Mr BDD, har varit i Sverige flera gånger under våren. Han gick ut offentligt både på Jfokus (8 april) och Dev Summit (9-10 april) med att TW skulle öppna kontor i Sverige. På Dev Summit talade jag lite med Dan och försökte lite smått pressa honom på detaljerna, men Dan svarade rätt svävande. Kanske var det inte så klart ändå? Men jag har senare fått andra indikationer på att Thoughtworks verkligen kommer till Stockholm. Det är därför ingen avancerad gissning att säga att TW kommer att ha ett kontor i gång i Stockholm direkt efter sommaren. Minst sagt spännande!
Jag kommer i detta inlägg att försöka mig på en analys av möjliga konsekvenser av att Thoughtworks öppnar i Stockholm. Låt mig från början säga att detta mest är kvalificerade gissningar så ta allt som jag säger med en nypa salt. Jag vill också nämna att jag inte har några direkta kopplingar till Thoughtworks så jag känner att jag kan förhålla mig relativt neutral.
Det första man kan fråga sig är varför Thoughtworks är intresserade av Sverige? Enligt uppgift ska Sverige vara intressant på grund av att vi har många duktiga systemutvecklare. Jag tror att det stämmer, men bara delvis. En annan sak med Sverige som kan ha inverkat är systemutvecklarnas förhållandevis låga löner (med västlig standard). Jämfört med amerikanska och engelsk standard ligger en duktig utvecklare en bra bit lägre (läs: billigare för arbetsgivaren).
Så vad kommer Thoughtworks i Stockholm att betyda? Det första jag tänker på är de andra konsultbolagen. Vad tänker de? De få jag har pratat med är klädsamt fåordiga, men medger att TW kommer att bli en svår konkurrent. Jag tror inte primärt att man behöver vara orolig för sina kunder, snarare för sina anställda. Jag förutspår att många av de 5-10% bästa på varje bolag kommer att åtminstone söka jobb på TW. Som en följd av det kommer det att bli ännu lite tuffare att behålla de bästa på respektive bolag. En löneökning för konsulter känns ofrånkomlig och i dess följd, höjda arvoden. Då konsultpriserna har stått mer eller mindre still de senaste 5 åren kanske inte detta är en alldeles felaktig justering.
Inom några år kommer naturligtvis Thoughtworks att även bli en mycket tuff konkurrens om uppdragen. Man kan riktigt se det framför sig: ”Hi, my name is Martin Fowler and I am here in Stockholm today to tell you how we will ensure success for you, not only in this project, but in all your future IT-driven business that you will permit us to take part in. We did a very similar project in Sydney just last year and we measured an ROI of 67 percent. We have the best people, the best methods, the best tools and the best brains. Any questions?”. Ok, bara på skämt, jag tror inte heller att Martin säljer projekt, men visst kommer TW att bli en verkligt tuff konkurrent inom några år.
Om vi lämnar företagen, det är inte synd om dem, vad innebär detta för stockholmskonsulterna? Det innebär, för det första, att det kommer att finnas en ny, attraktiv arbetsgivare i Stockholm. Inte minst är möjligheterna till att få resa och bo utomlands stora. Naturligtvis kommer man då och då att få träffa och prata med tunga namn i branschen. Vem vill inte prata BDD med Dan North, SOA på rätt sätt med Jim Webber eller DSL:er med Martin Fowler? För mig låter det också helt rätt att arbeta på ett bolag med starka, moraliska ståndpunkter. Den svenska konsultmarknaden är frustrerande kort på bolag som verkligen vill förändra världen.
För det andra tror och hoppas jag att detta kan få positiva konsekvenser på vår arbetsmiljö, våra projekt och utvecklingsmetodik? Thoughtworks har en tydlig agil profil och ju fler som ställer sig upp och tar avstånd från fast pris/vattenfallsvansinnet desto bättre, enligt min mening. Jag förutspår alltså på lång sikt: fler och bättre, lättrörliga projekt och därmed en bättre situation för de flesta systemutvecklare (i bred betydelse).
Men finns det inga utmaningar för dem? Är allt så bra som det låter? Mitt svar är: Tyvärr inte. Ingenting är så bra som det låter. Låt oss göra en liten reality check på vad TW står inför.
För det första så kommer TW att ha svårt de kommande åren med att få några som helst uppdrag som involverar offentliga kunder (annat än som underleverantörer). Sverige dras ju med ramavtalsträsket och TW har inget. Detta kommer rimligen att begränsa TW:s möjligheter att få projekt de kommade åren. Överhuvudtaget kan TW få problem med ramavtal. Mitt intryck är att TW, precis som de flesta duktiga hackers (i positiv mening), är framgångsrika just på grund av av sin förmåga att tänka utanför ramarna. Ramavtal är definitionen på ramar. Som en fotnot kan man här stanna upp och inse att ramavtalen faktiskt fungerar som ett handelshinder för internationella bolag att göra affärer i Stockholm. Var det så det var tänkt, eller (ironi, ironi)?
En annan utmaning för Thoughtworks blir att kontoret intitialt måste bemannas med personal från andra kontor, troligen mest från England. Engelsmän från TW är som engelsmän är mest; ett gäng grabbar som gillar öl och snackar fotboll. Det är chefen som bestämmer och projekt som måste lyckas. Enda skillnaden är att många är några snäpp mer intelligenta än genomsnittet. Jag har arbetat i Englande under några månader och det är bara att konstatera att engelsk företagskultur inte är densamma som den svenska. För jobbsökande svenskar är det viktigt att vara medveten om det. ”They want paterniWHAT leave!? For twelve f-cking months!!?”. Även om man sätter in en svensk chef kommer mycket av den engelska kulturen att överföras automatiskt med personerna. Jag är också väldigt spänd på att se hur väl TW håller sig till den lättrörliga vanan att arbeta i ett ”hållbart tempo” (”sustainable pace”) i sina projekt.
Till sist, om någon som söker till Thoughtworks på allvar tror att ni kommer att mingla med Martin och grabbarna varje fredagsöl så tror ni bestämt fel. Jag har jobbat på ett konsultbolag med en utvecklingsstorhet och man såg honom på ett föredrag någon gång om året. Det är kul att ha en guru att referera till, men det är inte någon större skillnad. I och för sig har ju TW mer än en ”guru” så chanserna är säkert större.
Jag tror att om Thoughtworks ska lyckas i Sverige måste de skapa ett svenskt TW, inte ett TW i Sverige. Ett TW som för in alla sina spännande idéer, men som samtidigt kanske också lär sig av Sverige. Kanske fem veckors semester på sommaren inte är så dumt tänkt? Detta kommer att ta flera år för dem och för de svenskar som börjar tidigt väntar en spännande tid.
Till sist, jag tycker för min del att detta ska bli otroligt spännande. Den svenska ankdammen behöver konkurrensen och det kommer att göra gott för oss i längden, det är jag övertygad om. Så låt mig vara en av de första som säger det: Welcome to Sweden, Thoughtworks!
05.02.08
Kritik mot TDD (och några svar)
På sista tiden har det dykt upp en del kritik mot Testdriven utveckling (TDD). Som stark förespråkare av TDD är jag naturligtvis intresserad av att se vad folk opponerar sig mot. Kanske har de en poäng och kanske bör jag vara mindre entonig i mitt TDD-mantra? Låt oss se efter.
Coplien på JAOO
Från JAOO och andra konferenser har Jim Coplien basunerat ut sitt budskap att TDD inte är bra (”the ugly step-child of XP”, som jag har för mig att han kallade det i en intervju som jag läste). Jag tycker personligen att hans attityd mot Robert C Martin var burdus och tämligen respektlös. Men låt oss förbise sådana saker och koncentrera oss på hans budskap, i den mån jag kan förstå dem.
Om jag tolkar honom rätt är hans första kritik den att TDD inte skapar bra arkitektur eftersom man fokuserar på att göra det enklast möjliga som kan fungera (YAGNI). Hans exempel är att reducera ett bankkonto till ett tal, en siffra, vilket aldrig kan fungera i en seriös bankapplikation.
Mitt svar: Jag tror att det finns en uppenbar risk att man missuppfattar YAGNI. Det innebär inte den enklaste jag kan tänka ut utan den enklaste, snyggaste lösningen av de som faktiskt skulle kunna fungera. För en större bankapplikation kommer inte en siffra att vara ett element i mängden av möjliga lösningarna. (För en applikation som hanterar privatekonomi kan det kanske vara det.) Jag tror att Coplien utnyttjar detta missförstånd för sina egna syften, eller så har han helt enkelt inte förstått.
Jag tror vidare att Coplien kraftigt undervärderar värdet av refaktorisering och hur vi kan bygga design och arkitektur bit för bit, mer och mer generellt, komplexare bara när det behövs, det vi kallar evolutionär design. Vissa saker kan inte TDD:as fram, helt korrekt, men paket, lager och delsystem är faktiskt inte någon av dessa saker (aspekter, loggning, trådhantering är det däremot).
Copliens andra kritik är mer svårförståelig. Han påstår att han har sett applikationers gränssnitt, deras GUI:n, förstöras på grund av TDD. Tyvärr har jag inte förstått exakt varför han tror att TDD har något med detta att göra.
Mitt svar: Jag kan tänka mig många skäl till att gränssnitt blir ointuitiva, men TDD skulle nog inte vara med på min lista. Om skälet skulle vara att utvecklarna har tvingats att arbeta med en funktionsbit i taget (s.k. sashimi) förstår jag att resultatet kan bli plottrigt… om man samtidigt inte har haft en vision, en informations- och navigationsstruktur och en bra UX-designer i sitt team. Jag har svårt att se detta annat än som ett misslyckande hos personerna med det övergripande blicken över det gränssnitt som ska skapas – inte hos TDD. Om Coplien menar att GUI:t blev dåligt därför att utvecklarna testdrev fram det så förstår jag nog ännu mindre. Om någon som läser detta kan se kopplingen så vill jag gärna veta.
Cédric Beust på QCon San Fransisco 2007
Jag har precis hört en intervju med Cédric Beust på InfoQ. Cédric jobbar på Google och är bl.a. en av personerna bakom testramverket TestNG. Cédric är, enligt egen utsago, ”något skeptisk” mot TDD. En av sakerna han menar är att eftersom så mycket av arbetet med TDD är vad han kallar ”mikrodesign” (metoder eller delar av metoder) så har TDD en tendens att göra dig ”närsynt”. Jag förmodar här att Cédric här menar att man inte har en bra överblick av designen.
Mitt svar: Jag håller med Cédric att detta är en fara, men bara om du inte använder seriös refaktorisering och designskisser på tavla. I refaktorisering ingår just att ”ta ett steg tillbaka och reflektera över din design”. Det är tyvärr en vanlig missuppfattning att dessa saker inte ingår i TDD. Som vanligt i XP stödjer arbetssätten varandra på ett subtilt sätt och om man enbart gör TFP, dvs Test-först-programmering, är garanterat risken att du får en svag design. Om du använder refaktorisering för utbyggbarhet och förvaltningsbarhet är risken för närsynthet liten, enligt min mening.
Cédrics andra kritik var att man om man arbetar med TDD ”långa stunder” befinner sig i ett tillstånd där inte koden kompilerar och man därför inte kan använda alla finesser i våra fina IDE:er och det skulle vara ett steg tillbaka.
Mitt svar: Återigen en kritik som är svår att ens begripa. Om jag får gissa, läsandes mellan raderna, så arbetar Cédric med att skriva en komplett testmetod för en hel metod för att därefter skriva en metod som får testet att gå igenom. Detta skulle få effekten att vi är i rött, så att säga, en stor del av tiden. Detta är inte bra TDD, det är alldeles för stora steg. Genom att ta mycket mindre steg kan vi, och bör vi, minimera tiden i rött. Låt mig vara tydlig: Det ingår i TFP att vara i rött (inte kompilera eller test är trasigt), men helst ska enbart ett enda test vara trasigt och vi gör allt för att minimera tiden där (enligt tumregel: 1. Make it work 2. Make it right).
Vidare, Cédric kan inte ha sett Robert C Martin genomföra en TDD-session för då skulle han inse och lära sig hur mycket nytta man kan ha av en IDE för att göra TDD (t.ex. Quick Fix-funktionen).
Allmänt mummel
Till sist en kritik som jag inte kan tillskriva till någon enskild person men som vi ofta hör när vi är ute och pratar om TDD. Det är farhågan att man med TDD måste göra om alltihop, eventuellt flera gånger. Alltså, att TDD leder till mycket omarbetning.
Mitt svar: Ja, detta är delvis sant (men inte i så stor omfattning som vissa tycks tro). Vi kommer att få omarbeta vår ”enkla” lösning då och då därför att behoven visade att den inte var tillräckligt avancerad (komplex). Poängen är här att behoven först måste manifestera sig innan vi inför en mer avancerad lösning. Detta är En God Sak, eftersom en mer avancerad lösning är mer komplicerad att använda, svårare att förstå och underhålla. Vi vill hålla detta till ett minimum i våra system.
Så, hade det då inte varit bättre att designa den avancerade lösningen från början? Jo, om du har en perfekt fungerande kristallkula och kan förutspå framtiden. Men det finns ganska få trollkarlar bland oss. Vad TDD menar är att många gånger kommer inte den där ”uppenbara” funktionen att göras och den generella lösningen sitter bara där och kostar pengar och att detta uppväger kostnaderna för någon eventuell omarbetning.
Min uppfattning att TDD är en teknik som tar tid att lära sig, men som är oerhört kraftfull. Den personifierar Toyotas tanke att vi bör bygga in kvalitet från början istället för att ägna en massa tid på att testa in den i efterhand. Vad är din åsikt?
05.01.08
Enveckasiterationer del II
I ett tidigare inlägg berättade jag om hur vi har arbetat i mitt senaste team. Vi arbetar med enveckasiterationer, men det har vi inte alltid gjort. Tidigare har vi använt tre veckors iterationslängd. I detta inlägg tänkte jag kontrastera lite hur det är att gå från tre veckor till en vecka.
Fördelar
- Planeringsmötet tar inte en tredjedel av tiden, vilket man kan tro, snarare en femtedel. Detta kan delvis förklaras av att vi kan förenkla och hoppa över vissa moment. Typiskt tar det en dryg timme men igår gjorde vi den på 45 minuter. Tidigare tog det 6 – 8 tim, för tre veckors arbete. Detta är givetvis bra då teamet istället kan lägga denna tid på att producera nytta.
- Ett skäl till att planeringsmötet blir kortare är att vi slipper estimera uppgifter, dvs våra nedbrutna user stories. Vi har nått en bra nivå och våra uppgifter är oftast relativt små. Så vi förenklade och provade istället att bara räkna kort. Vi får 15 – 20 st på tre veckor. Det verkar fungera precis lika bra.
- Antal och storlek på felestimeringar har minskat betydligt. Ju större arbetsmängd man ska estimera, desto större är naturligtvis risken att man har hamnat en bit fel. Med en veckas arbete är det mindre risk, även om vi i början var ganska dåliga på att få det rätt. En sprint estimerades till 6 poäng och när den började närma sig sitt slut fick vi lyfta ut 5 poäng. Nu har vi inte missat på många veckor.
- Antalet uppgifter/kort räcker för att se status. Vi behöver därför inte att hålla koll med en sprintförbränningsgraf (eng. ”sprint burndown chart”). I början fortsatte vi att rita den men, herrejösses, det är 4 dagar vi talar om! Det behövs inte. Sprintplanen är redan hanterbar och överblickbar.
- Produktägaren gillar det. Hon kan välja att driftsätta varje vecka. Är något värdefullt för organisationen klart så får de ut detta till användarna på snabbast möjliga sätt. Leantankar omsatt i praktiken.
- Möjligheten till omprioritering och nya tag nästa vecka skapar ett lugn och en flexibilitet hos produktägaren. Om något inte får plats så är det bara en vecka till nästa chans. Vi slipper många debatter om vad som är viktigt just nu.
Nackdelar
- Givetvis kan kortare iterationer ge upphov till oproportionerligt stor andel transaktionskostnad, dvs tid att sätta upp och och avsluta varje iteration. Men som jag berättade ovan är vår erfarenhet snarare den omvända, om man kan utnyttja de förenklingar som man kan göra med en mindre omfattning.
- En annan risk är att leveranserna tar för mycket tid, relativt sätt. Detta hände oss. Vår infrastruktur för leveranser höll inte måttet när vi gick till leverans varje vecka. Man kan välja att se detta som att vi blev avslöjade. Vi sänkte vattnet i floden tills dess att båten gick på grund, för att använda en leanmetafor. Lösningen är förstås inte att gå tillbaka till treveckorsiterationer utan att bli bättre på att leverera. Vi förbättrade våra byggskript, vi blev bättre på att följa IT-enhetens rekommenderade driftsförfarande, vi skärskådade beroenden på vårt system och minimerade vår exponering för att möjliggöra leverans utan att alla beroende system också måste leverera om. Att tvingas att bli bättre kanske egentligen ska ses som en fördel?
Så, borde alla team köra med en vecka?
Nej, det kan man inte säga. Jag kan bara säga att våra erfarenheter har varit mycket goda, så om man har möjligheterna tycker jag definitivt att man ska prova. Det har i alla fall gjort oss ett par snäpp mer agila.
Hur vet jag om vi kan prova enveckasiterationer?
Svårt att säga, men här är i alla fall en lista på vad jag tror är nödvändiga förutsättningar:
- Mogen produktägare och kundteam som är duktiga på att förbereda planeringsmöten, prioritera och formulera user stories.
- Engagerad, samlokaliserad produktägare
- Moget team som är duktiga på agil metodik. De ska vara vana att hålla effektiva, tidsbegränsade möten.
- Automatiserade systembyggen och leveranser
- Troligen krävs ett relativt litet projekt, ett eller några team stort.
Något att fundera på
Så… om tremånadersiterationer är bättre än ett år långa, om enmånadsiterationer är bättre än tre månader och en veckas iterationslängd är bättre ändå, varför sluta där? Det är en relevant fråga. Om vi kan leverera på en vecka, varför inte varje dag? Eller, i förlängningen, kontinuerligt. Leveranser som bara en ständig ström av kontinuerligt värdeskapande. Ja, varför inte?
