Fäst korten på väggen - du har väl inte glömt bort CRC?

CRC cards identifieras av IREB® CPRE FL1 som en hjälpande (supporting) eliciteringsteknik på samma sätt som mindmaps eller workshops. Faktum är att både mindmaps och CRC ofta är aktiviteter i en workshops. Bra kravupptäckartekniker får alla inblandade att lämna datorskärmarna och sina arbetsrum och tvingar/inbjuder folk att ställa sig upp och berätta hur man tänker och hur man resonerar. Hur hänger det ihop? Vilka ord använder man när man pratar om “systemet”, “problemen” och “lösningarna”?

Vokabulären är en viktig del av förståelsen. Den gemensamma närvaron gör att delaktigheten i designen ökar. Den så kallade “tacit knowledge” (kunskapen som sitter i huvudet och i väggarna) sprids lättare med tekniker som omfattar FYSISKA moment och verbala förklaringar istället för författande av tjocka dokument.

Det som sägs “mellan raderna” är kanske lika viktigt som själva resultatet. Den gemensamma resan till en lösning ger många positiva spinn-off effekter för alla.

1989 presenterade Kent Beck och Ward Cunningham CRC-metoden på den årliga forskarkonferensen inom Objektorienterad programmering (OOPSLA; Object-Oriented Programming, Systems, Languages & Applications)

Deras papper “A laboratory for teaching object oriented thinking” baserades på deras praktiska erfarenheter av att undervisa och arbeta med objektorienterad programmering i olika typera av projekt.

De insåg att det inte är lätt att lära ut OO-tänkandet. Även gamla programmeringsrävar med en bakgrund inom procedurell programmering, vana att ha en global kontroll över helheten, och istället förlita sig på en distribuerad konstruktion och att de lokala objekten verkligen löser sina respektive uppgifter i relation med varandra.  Att sluta upp med globala variabler och centralt styrda pekare och referenser. Paradigmskiftet innebar ett nytt sätt att tänka och det kräver ofta nya sätt att jobba på.

Cunningham-Beck.jpg

Beck och Cunningham identiferade tre grundläggande principer för att jobba bättre med objektorienterad utveckling. CRC, Class, Responsibility och Collaboration.

Det gäller att hitta rätt nivå på den aktuella informationen. Ett kort rymmer inte en hel roman, utan man tvingar de involverade att definera sig bättre. Vad kallar man klassen? Är det ett bra namn när man pratar om objekten och hur de relaterar till varandra och samarbetar för att lösa olika uppgifter? Namnet på kortet blir en del av den vokabulär, eller det metaspråk som skapas för att kunna resonera kring problem, idéer, behov och lösningar. Det är viktigt att identifera rätt problem. När man tvingas att hålla sig till några få ansvarsområden för varje kort, startas diskussioner om själva problemet, men även om det är rätt namn på kortet, om klassen/objektet verkligen ska ha det omtalade ansvaret, eller om det borde skötas av ett annat objekt. Eller är det inte problem i verkligheten? Eller är det mycket större än vad man först trodde. Hur delas ansvaret?

CRC-korten är inga platshållare för stora dokument. Ett litet kort innebär korta fraser och tydliga ord. Man minimerar automatiskt komplexiteten. Det är inte svårt att skriva massor, det är svårt att hitta essensen och bara skriva det viktigaste, med de bästa möjliga orden, som ger rätt associationer och rätt “energi” i projektet.

Om korten läggs ut på ett stort bord eller sätts upp på en vägg, så är det lätt att flytta dem, och man kan även införa en spatial semantik; kort som ligger högre upp kan tolkas som “superklasser” och kort som lägg så att de delvis överlappar, har en stark koppling. Det viktigaste är att det är lätt att flytta på korten och när man tar ett kort I handen så PRATAR man om hur man tänker och beskriver varför (rationalen) man vill ändra dess position, eller lägga till/ändra texten på kortet. Kanske vill man tillföra ett nytt kort till tavlan. Varför? Hur tänker du då? Hur hänger det ihop? Vilket ansvar har det nya kortet?

CRC-korten lyfter fram ett scenariotänkande.

Man kan dels jobba med korten för att hitta en första fungerande “design” på en hög nivå för ett antal “problem” och för ett antal mer eller mindre komplicerade scenarion som man vill att det automatiska systemet ska kunna klara av att hantera.

Ett annat sätt är att stress-testa en redan existerande design genom att gör en visuell walkthrough där man pratar igenom scenarion och tänker på vad som kan hända (alternativa och exceptionella flöden). Även förändring av identifierade förutsättningar (Assumptions) och “katastrofer” kan spelas igenom och ge effektiv återkoppling. Varje kort bygger upp vokabulären, och alla korten delar tillsammans på det totala ansvaret för att lösa de existerande “problemen”. Det är ett spännande sätt att utveckla på, eftersom man hela tiden adresserar NYTTA, BEHOV och ANSVAR och alternativa lösningar och agerar ut dessa fysiskt och verbalt.

Pröva!

1. IREB®CPRE FL = International Requirements Engineering Board  -  Certified Professional for Requirements Engineering - Foundation Level

Read more about IREB: http://www.certified-re.de/en/board.html 

Om författaren

Stefan Eekenulv är en passionerad seniorkonsult inom kravhantering och förbättringsarbete, kreativ och visuell, alltid med fokus på att se saker med nya ögon och att få det att funka i verkligheten.