Kurser om Scrum och DDD snart på Citerus

Under hösten kommer vi på Citerus dels att fortsätta med våra populära utbildningar i den lättrörliga arbetsmetoden Scrum, dels ha en del andra intressanta evenemang. Se här till exempel:

Eric Evans budskap är minst sagt angeläget. Han vill hjälpa oss mjukvaruutvecklare att utnyttja kraften i domänmodeller för att lösa våra kunders problem. Det handlar om ett nytt fokus på att använda våra kunskaper om begreppsmodellering för att dels prata med kunden på kundens sätt, dels implementera objektorienterade lösningar på ett elegant och effektivt sätt.

Vår senaste workshop med Eric Evans var mycket populär. Samma gäller vår senaste Scrumkurs. Båda evenemangen är upplagda för att aktivera deltagarna att lära sig genom att göra, snarare än bara genom att lyssna.

Disagreement on Common Sense Caused by Change of Age?

Why do some people see agile methods as common sense, while others see them as senseless? Why is it so natural for some people that development processes need to be broken down into stepwise descriptions of each step to take to arrive at a solution, while others say that this approach does not make sense?

In a speech at the “Systems Thinking in Action” conference in 1993, Russell Ackoff makes the case that we have entered a change of age – a paradigm shift. For Ackoff, this change is about a switch from a Machine Age to a Systems Age. Such a change of age is brought about when we discover enough problems that cannot be solved by the current mode of thinking.

When we start to notice this, we start to challenge the current world view. Gradually, the current view on the world is replaced by a new one, more suited to solve the problems of our time.

Maybe this is why agile methods seem obvious to some, and crazy to others? Maybe this is why we cannot agree on what constitutes common sense? If we have radically different views on the world, we’re bound to disagree like this.

Ackoff presents his argument using a beautiful tour through the history of the world, from the renaissance to today. Follow along in this transcript of his speech (PDF), which I highly recommend to anyone interested in agile methods and systems thinking.

MVKJG 2: Fråga varför tills du får en smäll

I det snudd på magiska ordet varför ryms ett otroligt kraftfullt sätt att lära sig mer om vad som helst.

Det berättas ibland sedelärande historier om chefer hos biltillverkaren Toyota som kommer till insikt om sina egna bristande inköpsdirektiv när de frågar varför det finns en oljefläck på golvet. De lyckas helt enkelt härleda det stora från det lilla, med den frigörande frågan: “Varför?” Det visar sig att de själva är ansvariga för oljeläckaget, eftersom de stipulerat inköp av oljefilter från den billigaste leverantören, som tyvärr också visade sig vara den sämsta.
Själv brukar jag använda mig av ett ganska praktiskt verktyg som ibland kallas varför-hur-trappan [1]. Har man tillgång till något att rita på ritar man helt enkelt en liten trappa, och lägger gärna till en pil som pekar upp för trappan med texten “Varför”, och en pil som pekar nedåt med texten “Hur”. Sen är det bara att skriva in det vi vill lära oss mer om någonstans mitt på trappan, och sedan följa trappstegen i endera riktningen. Tar vi ett steg uppåt frågar vi oss varför, går vi nedåt frågar vi oss hur.

Så här till exempel: vi borde börja skriva fler automatiska tester, skriver vi på mitten av trappan (eftersom någon just föreslagit det efter att ha läst MVKJG 1. Sen frågar vi oss varför, och skriver in svaret på steget ovanför: så att vi effektivt kan fånga och ta bort fler fel. Steget ovanför kommer nästan av sig själv, vi vill såklart bygga en felfri produkt, och anledningen till att vi vill det är förstås att vi vill ha fler kunder.

Vi kan gå nedåt också, genom att fråga oss hur. Varför inte rekapitulera från toppen? Vi vill ha fler kunder. Hur kan vi få det? Genom att ha en felfri produkt. Hur kan vi få en felfri produkt? Genom att hitta och eliminera så många fel som möjligt. Hur då? Genom att skriva automatiska tester som hjälper oss i testarbetet!

Sen kan vi fortsätta ännu längre ner förstås. Hur ska vi skriva automatiska tester? Genom att lära oss hantera ett ramverk för att skriva och aggregera tester. Hur ska vi lära oss ett sånt ramverk? Genom att köpa in böcker och planera in tid för lärande i vårt arbete.

Den här enkla modellen är vansinnigt användbar när man planerar ett projekt eller en iteration. Genom att placera in bitar av planen i trappan kan vi känna om de ligger på rätt nivå. Är de lagom konkreta, lagom målorienterade?

När jag hjälper till att planera iterationer vill jag till exempel att de funktioner och kvaliteter vi planerar i ska uttryckas så att utvecklingsteamet själva kan välja hur man vill uppnå dem. Blir vi konkreta för tidigt riskerar vi att låsa in våra tankar och eliminera möjligheter. Är vi för abstrakta blir det svårt att se om det vi planerar verkligen är genomförbart.

Proffsteknik: låt trappan evolvera till ett träd av orsakssamband som sprider sig i alla riktningar. Det finns ju alltid fler sätt att förklara orsaken till något, precis som det finns fler sätt att åstadkomma ett visst resultat.

Ett varningens ord på vägen dock. Konsulten och författaren Gerald Weinberg har pekat ut [2] att en fortsatt undersökning av ett problem ofelbart leder fram till problemets källa, som med största sannolikhet är din uppdragsgivare. På Toyota pratar man om fem varför. Jag brukar kalla metoden för “fråga varför tills du får en smäll på käften”. Det återspeglar bättre den sanna potentialen i denna grovt underskattade teknik.

—-

[1] Jag lärde mig verktyget i den suveräna “Att sälja och ta betalt för kunskap” av Britt-Marie Ahrnell och Rolf Edman.

[2] Se till exempel den roliga Secrets of Consulting, Gerald Weinberg.

MVKJG*) 1: Skriv automatiska tester

För en tid sedan påminde jag några utvecklare om hur användbart och effektivt det är med automatiska tester. Jag tyckte att jag intog en ganska pragmatisk inställning, och tipsade (för att vi skulle komma igång med testskrivandet) om följande introduktionsupplägg.

Under den kommande iterationen kunde vi för varje bugg vi hade uppdrag att fixa först se efter om det verkade gå att skriva ett automatiskt test som återskapade buggen. Om det å ena sidan verkade gå kunde vi helt enkelt skriva testet. Om det å andra sidan inte verkade gå kunde vi skriva ned några anteckningar om varför det inte gick, och sedan tillsammans gå igenom vad som gjorde det svårt att skriva tester.

Ganska moderat upplägg, om jag får säga det själv. Svaret kom dock rätt snabbt: – “Vi har hört det här förut”. Och det hade de naturligtvis. Idag är det svårt för en utvecklare att missa alla uppmaningar om att man måste skriva sina egna automatiska tester, och som ofta när trycket i en riktning blir högt kommer ett mottryck som ett brev på posten. I det här fallet resulterar det i att inga tester skrivs.

En missuppfattning som kanske bidragit till att skrämma upp många är tron att vi måste skriva tester som täcker in alla möjliga felfall. Det är sällan möjligt, eftersom antalet möjliga kombinationer som måste testas ökar så snabbt i en framväxande mjukvara. Istället måste vi sätta oss in i hur vi kan testa för att få maximal avkastning på våra tester. Att börja med att skriva tester som varnar när en tidigare fixad bugg dyker upp igen är till exempel otroligt väl investerad tid.

Många har förklarat och argumenterat för att utvecklare skriver automatiska tester för sin egen kod. Jag har inga nya argument att tillföra, utöver detta: idag verkar de bästa utvecklarna i världen samstämmigt skriva under på att automatiska tester är viktiga, nyttiga och till och med ganska roliga, och att de ska skrivas av utvecklaren själv. Kanske kan detta åtminstone få dig lite nyfiken?

De är definitivt något du kan börja med idag, utan större investering i vare sig pengar eller tid.

*) Men Vad Kan Jag Göra?

Men vad kan jag göra?

Sitter du fast i ett projekt som också sitter fast? Har du tappat hoppet för mänskligheten (eller bara för den del av mänskligheten som utvecklar mjukvara)? Håll ut: det finns hopp. Du behöver inte förändra världen, eller ens ditt projekt, med ett svepande hugg. Du kan göra saker bättre ett litet steg i taget, helt på egen hand.

I min ficka har jag samlat inte mindre än 99 tips om vad du kan göra redan idag för att börja förbättra ditt projekt. Helt utan att be någon annan om tillstånd. Utan någon större investering. Utan att behöva anlita en hord av RUP-konsulter. Det finns ljus i tunneln. Ett steg i taget bara. Ett steg i taget.