Tag: coding dojo

Agila Sverige 2013

Sitter på tåget på väg hem från Agila Sverige 2013. Det har varit två underbara och uttröttande dagar, med mängder med trevligt, kompetent folk, bra blixttal och öppna, givande diskussioner och dialoger.

Egna insatsen

Fredrik Wendt: Coding Dojos för företag
Jag var först ut, hade inte presentatörsanteckningarna framför mig vilket var tvärtemot vad jag fick mail om dagen innan, men bortsett att det blev lite mindre fokuserat och tydlig röd tråd så tror jag att det viktigaste sades.

Open space-session på temat “Hur lär man ut TDD?”

(Kallas också rundabords-diskussioner, ofta utan bord.) Jag deltog i ett par open space (kallades open X)-sessioner men förde bara anteckningar från en där frågeställningen var Hur lär man ut TDD? Det var inte jag som som föreslog ämnet men deltog och försökte erbjuda så konkreta tips på idéer till den/de som sökte svar och inspiration eller bara nya (eller gamla) tankar.

  • + training, education
  • ? how do I get colleagues to see the benefit of it?
  • ! forced for a short period where you see the end of the period, one sprint/2 weeks
  • ! re-allocate some of the devs to a team where TDD is heavily used
  • ! move away from too simplistic katas, people have a too hard time transfering what they’ve seen/learned to production (Emily: this was NOT me saying this, brought up by someone else based on experiences from other teams and devs! :-)
  • ? hard to start when what you’re starting your journey from/off of/on/what you have is untestable legacy code
  • ! book: M Feather’s Working With Legacy Code
  • ? more on what’s the benefit of TDD in your view?
    I answered that almost everyone agree that pre-production tests, such as a unit test suite, is of great value.
    If you use TDD as means to get more readable, usable, understandable, maintainable code – then that’s your benefit. But it’s not the only way to get there, TDD is not the silver bullet solution to everything.
  • ? what are the arguments against TDD?
    Can’t use it blindly, might be hard transition/initially. Should/may not be used for spikes.
  • ! book: Kent Beck’s Test-Driven Development by Example

Övriga personliga diverse anteckningar och doodles

Ann-Louise Ulfsparre och Fredrik Josliden: Kommunikation mellan team, javisst! Men, hur då?
Story points samma mellan team? Grooming utan O? Slå ip team fungerade bra. Skall prövas!

Johan Dewe: Så fick vi alla att räcka upp handen
Om att rulla ut agil utvecklingsprocess utan att kalla den agil. “Roll your own vs try what’s been known to work”?
Rubrik “att få alla att räcka upp handen”, efter en egen introduktionskurs (liknande CSM dag 1, PSF, …) med folk från blandade verksamhetsfunktioner så fick alla frågan “Vilka håller på med systemutveckling?”. (Alla förstod sin del och att det var en del av det hela.)

Jonas Hermansson: Acceptanstest är töntigt
Acceptanstestare är ofta för välbekanta med testobjektet – fundera över vem som gör acceptanstestet och konsekvenser av det. Mycket humor, kul presenterat! En klar topp 3 för mig.

Kajsa Goffrich: RTFM – varför är vi så snåla med kunskap?
Vi håller inne med kunskap som Joakim von Anka håller sina pengar i sin pengabinge, varför? Agil metodik leder till att vi jobbar öppet och talar ut om “jag har kört fast, tar tid, har problem”, men hur bemöts det? Vilken inställningar har vi till detta? “Jag har blockering – skall givetvis ses som att det teamet som har en blockering, inte en individ”. “Jag är inte korkad, jag har bara inte lärt mig det än”.

Inga-Lill Holmqvist: Servant Leadership – passar bra ihop med Agile och Lean?
Att tänka “du är viktigare än jag”, som chef. Mät: “Växer personen som jag servar?”
Aktivt lyssnande; Empati; Läkande; Awareness (self, organizational); Bygga konsesus vs auktoritativ beslutsfattande; Foresight; Stewardship (översattes till förvaltarskap :-P); Bygga gemenskap (community).
(Ja, allt detta passar mycket bra ihop med Lean och Agile.)

Matti Klasson: DevOps – ett sätt att samverka inte en jobbtitel!
Mixade team, praktisera i annan roll. Automatisering och verktyg är inte lösningen – lösningen är samverkande människor.

Annica Söder och Anna Forss: Hur vi undvek att bygga Dödsstjärnan
Jämförde Star wars- och Star Trek-stil, dvs magi, hjältar och ikoner med vetenskapliga teorier, samverkan och team.
10000 stormtroopers vs teamet “on the bridge”; Yoda vs Spock (mer vetenskapligt); dödsstjärnan vs enterprise (doable scope); mötet där Darth nästan stryper en amiral vs star trek-öl i restaurangen på skeppet (refletion meetings)
Seldon plan.

Thomas Nilsson: 13 steg mot Kanban Kaizen
Kändes lite för basic, men passade säkert många andra. Bra take away: se till att välja ord – det är lättare att “genomföra ett litet experiment under 2 veckor” vs “nu skall vi förändra våra arbetsmetoder”.

Annika Widmark: Om att lösa komplexa problem med enkla bilder
Storytelling, visualisera förändringsarbetet. Gather facts, group facts, imagine goal, show/visualize/draw. En av flera presentationer som tycker att tre kugghjul visar på något som snurrar (tre kugghjul som rör varandra kan aldrig snurra).
Glömde fråga om de foldrar som tagits fram hos Arbetsförmedlingen om erfarenheter om bra metoder/framgångar från projekt har lämnats ut publikt (tillbaka till skattebetalarna).
Bok: Back of the napkin, Dan Roam

Daniel Fröding: Continuous Delivery – On the road to a true agile company
itrevolution.com. Bra budskap. Använde karaktären Mr Business som gav beståeende men/intryck ;-)

Labbet – Continuous Delivery Pipeline

Andra halvan av dag ett var open X och jag valde att spendera tid i “labbet” med bl a Mattias Karlsson, Mikael Sennerholm och Johan Elmström från Avega Group (Enzo). De hade med ett par saker in, dvs förberett ett par saker såsom CI-, test- och prod-VM:ar, (Jenkins, Tomcat, Puppet, GitHub) men framför allt härlig öppenhet och vilja att lyckas utan att ta för mycket fula genvägar.

I korthet så fick vi något som fungerade, men ingen av oss helt “färdiga” (uppstädning) och ej heller helt nöjda med teknikstacken. Jag skall kanske inte tala för de andra men Jenkins och sina plugins (jag läste källkod också för att fixa en bugg) lyste inte direkt upp tillvaron, erhöll glada tillrop eller större uppskattning. Inte direkt någon överraskning för någon av oss, men nu är det iaf gjort en gång så det kommer från erfarenhet! :-)

Dag 2

Andra dagen förde jag inte anteckningar då jag hoppade fram och tillbaka mellan blixttal och labbet där vi fick den enkla Continuous Delivery-pipeline att snurra (Spring Petclinic, Puppet, Fabric, Razor, VMware, Python/bash, Jenkins). Bamboo, Go och Team City plus en mindre hög andra saker att kika på eller göra bättre fanns på ena kylskåpsdörren (bra yta för statisk plast = mobil whiteboard).

Gabriel Falkenberg: Jakrakning på rätt sätt
Mycket underhållande och träffsäkert. Om du skall raka jak, raka rätt jak, raka den rätt, … Klart topp 3 även denna.

Adam Killander: Fundamentalistisk förvaltning
Bra teatralisk berättandestil om förvirringen kring nyproduktion vs förvaltning. (Nyproduktion kanske finns första sprinten på ett nytt projekt, men inte efter det.)

Någon gång under dagarna gjordes en jämförelse mellan Legacy inom och utanför mjukvaruvärlden – i det ena en tillgång med värde, i det andra ses det mer som en belastning och kostnad.

Återkoppling från en Coding Dojo

Det är otroligt kul och inspirerande att se Coding Dojos tas emot så väl ute bland de företag jag besöker. Att det är väl mottaget bland utvecklare är uppenbart och kan bl a förklaras med “Code wins arguments”. I “gamla” inkörda team där diskussioner gått i stå och nötts länge kan helt plötsligt helt ny dynamik uppstå. De “gamla” argumenten som gått fram och tillbaka men bara varit abstrakta och teoretiska skall helt plötsligt omsättas i kod, med/inför kollegorna och “helt plötsligt” går det från abstrakt till konkret och inte bara fåtalet engagerar sig och har en uppfattning, utan flertalet.

De Coding Dojos jag driver hos kunder är just detta – praktiska övningar med ett mål eller en poäng. Ingen föreläsningsserie man sitter och nickar igenom och sedan släpper vind för våg. Med riktiga övningar, där alla deltar och skriver kod själva ökar deltagandet, engagemanget och det kritiska granskandet.

Eftersom det ofta uppstår diskussioner med uttryck som “jag brukar göra såhär”, “oj, så har jag aldrig gjort, eller tänkt” så är det viktigt att det inte finns lönesättande chef(er) på plats. Om deltagarna är rädda för att säga fel och börjar väga sin ord så försvinner en stor poäng med dojon. Jag försöker få alla att vara spontana med hur de tänker, att exponera hur de jobbar utanför dojon så att de kan få konstruktiv feedback på sitt arbetssätt. Lönesättande chef och/eller beställer behöver givetvis återkoppling också. Här följer ett exempel från förra veckan.

Hej Kund!

Efter lite hackiga, trevande steg med första övningen tyckte jag mig se en enorm skillnad till tillfälle två. Det märks att flera utvecklare försökt sig på det vi övade i vardagen! Jag tror mig se att så gott som alla utvecklare har fått en ny infallsvinkel till hur de ser på sin kodskrivning och den synen utvecklade vi med en mer realistisk övning ihop med mockning. Det var mycket bra frågor som dök upp, vilket tyder på att de är engagerade, intresserade, verkligen försöker anamma en annan kodordning och har en sund kritisk inställning till vad de gör själva (det är ju inte jag som skriver koden under övningen – jag bara guidar och ger tips)!

Övning 1:

Vi tog en enkel basövning (String calculator).
Vi introducerade red-green-refactor, Arrange/Act/Assert, bottom-up.
Vi tog baby steps bokstavligen med 1 minut som tidkrav att gå från röd till grön.
Vi såg triangulering som ett sätt att driva fram funktionalitet.
Grå zon: “täcker testen all funktionalitet? om inte, har vi använt test-driven utveckling?”

Övning 2:

Vi tog in en ny, ganska stor uppgift som är mycket mer realistisk (tagen från produktionskod).
Vi lade på ett nytt moment/tanke i form av en “testbacklog”. (Verkade vara en ny idé – diskuterade VAB-scenariot och vikten av att kunna dela kod ofta.)
Vi lade på mockning med Mockito. (En del var redan bekanta med Mockito.)
Grå zon: “ett par antydningar till att ändra kod utan att testen uttrycker den funktionella ändringen i koden”.
Vi refaktorerade kod lite oortodoxt (utan test, utan undo/bortkommentering).

Det var mycket motiverande för min del att se utvecklingen i teamet, det var en helt annan “mognad” i TDD-tänket och ett bra driv/bra dialoger. Parprogrammeringen såg bitvis fullständigt klanderfri ut – mycket kul att se! Nästan all kod drevs fram från test (två, tre tillfällen fanns antydan till att skriva kod som inte var testdriven/täckt av test).

Utvärderingen i slutet bjöd mer på kod- och designdiskussioner (jag vill aldrig avbryta sådant) så vi hann inte “utvärdera” så mycket, men på tavlan skrev jag upp:

+ bra frågor
+ bra övning
! refactoring gjorde koden mycket mer läsbar
! smidigt med @Mock
? Använda TestNG nästa gång

Mitt förslag är att vi nästa gång utvecklar i flera par parallellt (en dator per par med Eclipse är vad som behövs), lägger på Clean Code-aspekter och använder samma uppgift och ser hur vi kan få koden att se ut på olika sätt.

Agile Testing Days 2010 coming up

Speaker at Agile Testing Days 2010
I'll Be There

In about six weeks I’ll give a talk at Agile Testing Days together with Emily Bache. The talk’s title is set to “The Coding Dojo
as a forum for teaching TDD” and we are last to speak on Wednesday before the final key note of the day (and the “chill out” event). I’m looking forward to the conference which I’m sure will be full of insights and rewarding in many ways.