11.30.07
Vår nästa bok
Snart blir det bokcirkel igen. Efter vår första succé (ja, jag kallar det så) med ”Implementing Lean Software Development”, vad skulle kunna toppa det?
Vad söker vi? Helst ska boken kunna läsas av hela teamet (programmerare, användbarhetsexpert, ScrumMaster och produktägare). Helst ska boken vara lagom tjock och trevligt indelad i lagom stora delar. Helst ska boken vara lärande och tankeväckande. Helst ska vi kunna använda det vi lärt oss i projektet.
Här är våra nuvarande kandidater:
- ”User Stories Applied”, av Mike Cohn. En tung spik i kravhanteringskistan. En nackdel är väl att vi redan gör det mesta av vad boken föreslår. Har själv dock läst denna några gånger.
- ”Agile Estimating and Planning”, av Mike Cohn (igen). Mikes uppföljare är lysande. Han känns mer säker på vad han vill säga. Återigen, mycket av det gör vi redan. Har läst den en gång varpå jag prompt glömde den i ett flygplanssäte. Behöver ett nytt ex…
- ”Managing the Design Factory”, av Donald G Reinertsen. På rekommendation av Marcus Ahnve (tack!). Ska vara bättre än Poppendieckarnas böcker, vilket lovar gott.
- ”Agile Software Development”, 2nd ed, av Alistair Cockburn. Första utgåvan var tung, har inte läst den andra. Alistair är en tänkare, om än ganska abstrakt ibland. Här finns bl.a. den underbara utredningen om ”bandbredd” i olika kommunikationssätt.
- ”Agile Software Development – Principles, Patterns and Practices”, av Robert C Martin. Plus från mig är att jag inte har läst den (skäms!). Kanske är väl programmeringsnära för en del av teamet?
- ”Pragmatic Programmer”, av Dave Thomas and Andy Hunt. En underbart handsnickrad pärla. Också rätt teknisk i sammanhanget. Läst den två gånger.
- ”Extreme Programming Explained”, 2nd ed, av Kent Beck. Fortfarande mycket tankvärt i denna. Givetvis har jag läst denna några gånger.
Jag har skrivit ut lite information om böckerna från Amazon. Dessutom har jag skapat en liten matris på en av våra vita tavlor (se bilden). Ska bli spännande att se resultatet!
Har du någon bokrekommendation till teamet får du gärna kommentera (av de ovan nämnda eller andra).
11.25.07
Generalister och specialister
En av många aspekter vi måste tänka på när vi ska sätta ihop högpresterande, agila utvecklingsteam är om vi vill ha generalister eller specialister i dem.
Spontant tror jag att många säger: specialister! Fördelar med specialister är förstås att de har specialistkunskaper, till exempel på ett ramverk eller en metodik, som gör att teamet snabbare kan komma fram till en stilig och adekvat lösning. Problemet är att systemutvecklingsprojekt idag är så komplexa att du skulle behöva 20-30 personer med specialistkompetens för en webbapplikation av standardkomplexitet. Tror du mig inte? Ok, här en snabb lista (det finns säkert fler):
- politiker (för att hantera särintressen inom organisationen)
- marknadsförare (för systemet, produkten, projektet)
- domänexperter
- användare i olika roller (sällananvändare, läsare, administratör, rapportläsare, redaktör, …)
- marknadsexpert (produktägare)
- kravanalytiker
- systemtestare (storytestning, prestandatestning m m)
- säkerhetsexpert
- användbarhetsexpert (från behov till nytta)
- interaktionsdesigner
- webbprogrammerare
- grafisk designer
- tillgänglighetsexpert
- systemarkitekt (dvs minst en erfaren utvecklare)
- programmerare
- databasdesigner
- databasadministratör
- driftsansvarig
- processcoach
- verktygsexpert
- byggchef (CM)
- ramverksexperter (på valda ramverk, t.ex. Spring, Hibernate, Rails, Seam)
Att detta skulle vara olika personer har man givetvis inte råd med. Följden blir att vissa kompetensområden gapar tomma i team med utpräglade experter.
En annan nackdel med utpräglade specialister är att de har en tendens att inte vilja gå utanför sitt område – och inte heller släppa in någon annan på sitt område. Det blir lätt ”inte mitt bord”-mentalitet. Enbart en specialist kan säga: ”Ok, teamet hann inte med alla sina uppgifter, men jag blev i alla fall klar i förrgår”. Specialister är sällan lagspelare och kan vara svåra att leda och arbeta med.
Men generalister då? En generalist kännetecknas av ett stort intresse för många olika områden, men som sällan förkovrar sig inom samma ämne en längre tid. Fördelar med generalister är förstås att de är breda. De kan det mesta. Generalister har ofta en härligt attityd av ”hur svårt kan det vara” som gör dem relativt enkla att leda och samarbete med. Vad du än slänger åt dem så har de ett hum om hur de kan lösa problemet. Och de är vanligen inte rädda för att försöka! Den stora nackdelen är att de inte är utsökt bra på något. Utan specialister blir team långsamma och designen ofta allt annat än vacker (eller förvaltningsbar).
Men nästan ingen människa är total generalist eller specialist. De flesta är en blandning av båda, med läggning åt endera håll. Men det finns också två specialformer som jag vill ta upp: Specialiserade generalister och generaliserade specialister. Och båda dessa typer passar utmärkt i utvecklingsteam!
En specialiserad generalist är en generalist som har specialstuderat ett ämne att bli specialist inom. De är ovanliga men förekommer. Det kan till exempel röra sig om en projektledare som tvingats bli duktig på kravanalys i ett projekt och som sedan hittat en ovanlig niche som hon vill bevara. De måste ständigt arbeta vidare med sitt ämne för att behålla spetsen, vilket egentligen inte ligger i deras natur. Dock kompenseras detta av att de ofta mycket ambitiösa.
En generaliserad specialist är en specialist som även lärt sig att tänka som en lagmedlem och är öppen för att lära sig nya saker. Kan en testexpert lära sig grunderna i programmering? Kan en interaktionsdesigner bidra vid testningen? Kan en pythonprogrammerare hjälpa till med att analysera krav? Självklart!
Möjligheterna att bygga högpresterande team är stora med denna typ, då de både kan bidra med specialistkompetensen, men samtidigt kan se helheten och stötta varandra. Agila projekt strävar efter att ha merparten av teamen befolkade med dessa guldkorn. Och du som individuell specialist gör gott i att sträva efter att även kunna grunderna i områden utanför ditt eget.
11.24.07
Ny kurs: TDD – Inte bara enhetstestning
Observera: Detta inlägg består till största del av reklam för vår nya kurs. Sluta läs här om du inte gillar sånt.
Testdriven utveckling (TDD) och relaterade arbetssätt är en teknisk grundpelare inom agila metoder. TDD är nyckeln till att skapa högre produktivitet och ändå få högre kvalitet på resultatet (det är ingen motsättning). Men det är inte så lätt som det ser ut och det påverkar även personerna runt utvecklingsteamen.
Är du eller din organisation nyfikna på TDD? Eller vill ni komma igång, men vet inte exakt hur? Eller har ni redan kommit igång men får inte ut de fördelar som ni hade hoppats på? I så fall kanske vi har vad ni behöver.
Terrier Software och Dynabyte har tillsammans utvecklat ett modulärt system av utbildningsmoment inom TDD, från 1 timmes introduktion till tre dagars kurs. Målgruppen är systemutvecklare, testare, kravanalytiker och ledare för utvecklingsarbete. Utbudet är iterativt upplagt och består av moduler som enkelt kan anpassas till era behov.
Nyckelord vid utvecklingen har varit helhetssyn, praktik och attityd. Helhetssyn i betydelsen att vi täcker in många sätt att se på TDD, från mikrotester till storytester. Vi berättar också om hur TDD påverkar personer i olika roller, från programutvecklare till kravanalytiker och projektledare. Praktik har varit ett ledord och vi hoppas att det ska märkas i våra otaliga praktiska tips samt alla övningar och laborationer. Till sist, attityd, både att vi vågar säga det vi står för och stå för det vi säger, men också att TDD till sist handlar om ett ödmjukt sätt att utveckla. Vi hoppas att denna ödmjukhet inför våra egna begränsningar ska genomsyra kursen.
Är du intresserad av kursen, kontakta mig på info@terriersoftware.se.
11.01.07
En cirkel av böcker
Sedan 7 veckor tillbaka kör vi bokcirkel med projektgruppen (ett blandat team av konsulter och anställda). Varje fredag träffas vi 30 minuter och diskuterar ett kapitel ur boken ”Implementing Lean Software Development”, av Mary och Tom Poppendieck. Boken är indelad i 10 kapitel om ca 20-30 sidor så det är inget större problem för de flesta att hinna läsa det på en vecka.
Beställarna är vänliga nog att ge oss 30 min betald konsulttid för detta. Det är generöst, men jag tror att de har resonerat så här: Konsulterna har hjälpt våra anställda att vilja utvecklas och vilja bli bättre. De har pekat ut en väg (Agile och Lean) och föreslagit en bok att studera. Utan dem hade de anställda aldrig gjort detta. När konsulterna är borta kommer de anställda att kunna sprida detta till övriga. Merparten av arbetet sker på fritiden (själva läsningen). Om dessutom boken är högst relevant och kan hjälpa oss att bli bättre och effektivare borde denna lilla investering ha goda möjligheter att betala sig.
Jag och ScrumMastern resonerade så här. Vi visste sedan tidigare att de flesta i gruppen har ett intresse av att lära sig mer. Om vi stimulerar detta behov hos folk kommer de att bli mer motiverade och utföra ett bättre arbete i projektet. Vi valde just denna bok för att vi nu arbetat mycket lättrörligt sedan i våras och hoppades att boken skulle fördjupa allas förståelse för lättrörlig systemutveckling och ge oss nya idéer om vart vi ska gå.
Efter 7 veckor kan jag säga att det verkar det fungera över förväntan. De ovan nämnda fördelarna stämmer, men det bästa är nog att vi har fått ett gemensamt språk och sätt att tänka om saker. För första gången verkar folk inse att till exempel vår lista med buggar som vi inte betar av faktiskt är en form av slöseri som vi bör ta tag i. Först nu kan vi diskutera testningen, produktägarrollen, överlämningar och iterationslängd på ett givande sätt. Vi börjar så smått fundera på ett upplägg med skiktade leveranser. Vår produktägare blev nyfiken, köpte boken, och tyckte att det var helt rätt. Nyligen hörde jag honom nämna ”kanban”-kort (signalkort) för en kollega.
Det här är något jag kan rekommendera alla team att titta på. Att boken sedan består av avancerad, koncis och praktisk visdom om systemutveckling gör ju definitivt inte saken sämre.
