Posts Tagged ‘test’

h1

Q: Automatisera tester i samma sprint?

måndag, 2 april, 2012

Att det är kämpigt och utmanande att implementera A-TDD och TDD skriver jag gärna under på. Att göra resan från en process där testning handlar om att kritisera kod efter att den är skriven till att bli ett verktyg för teamet (där testerna primärt tjänar till att stötta utveckling under tiden utveckling sker) kan både var bökig och omtumlande.

Framför allt måste man skruva ner tempot innan man kan skörda hyperproduktivitetens frukter och detta är inte alltid så lätt när trycket är högt att leverera maximalt just denna sprint. Och sprinten efter. Och sprinten efter den.

För en tid sedan fick jag följande mail på ämnet…

.

Hej Jimmy

[…] Jag har på jobbet kommit i liten het diskussion om (Sprintlängd och autotester) […]. Dvs att man måste få tillverkat automatiserade tester i samma sprint som utveckling sker i eller åtminstonde sprinten efter. […] Och då menar jag tester som Test Avd. tillverkar. Unittester antar jag du menade dev gör i sprinten tillsammans med utv. arbetet?

Vilken typ av projekt har du varit involverad i? Det kanske är svårare att applicera detta i avancerade system med få utvecklare, oklara krav och dagliga byggen, än i ett system för en myndighet tex med väldigt klara krav?

Finns det någon bra bok man kan läsa om detta?

Mvh
#####

.

Hej #####,

Min egen starka personliga åsikt är att man ska utveckla automatiserade tester för det man utvecklar i samma sprint som arbetet sker. Det gäller både utvecklarnas enhetstester och testarnas/kravställarnas automatiserade funktions- och acceptanstester.

Jag gillar skarpt David Evans syn på test och kod som summeras i citatet ”[Acceptance] Testing slows down development just as passangers slows down the bus – the speed of the bus is not the point!”. Målet med sprinten är alltid att leverera fungerande värdefull testad mjukvara. Hinner man inte åstadkomma detta under en sprint har teamet tagit på sig för många, alternativt för stora, User Stories.

.

Blir dock lite förvirrad över en sak du skriver. Finns det en separat testavdelning? Ett starkt agilt team består av all kompetens som behövs för att gå från idé till leverans. Detta inkluderar då kompetens som täcker programmering, testning, verksamhet, gränssnittsdesign, databasdesign, teknisk dokumentation, osv.

Jag har erfarenhet från både små och riktigt stora projekt. Jag håller såklart med om att utmaningarna och förutsättningarna är olika men jag tycker ambitionen ska vara densamma. Om ni är få utvecklare och tampas med otydliga krav så kommer tydliga krav ”tvingas” fram om ni försöker skriva automatiserade acceptanstester i samma sprint som jobbet sker. Jag menar, utvecklarna lyckas ju uppenbart klura ut vad de ska programmera, då borde testarna (om det nu är olika personer som kodar respektive skriver de automatiserade testerna) klara av att klura ut hur det ska testas. Om inte så finns det uppenbart diskussioner och informationsloopar som testarna inte är med i.

Genom att skriva de automatiserade testerna först i sprinten efter tappar man halva poängen med dem som jag ser det. Visst, man bygger på en regressionstestsvit som är automatiserad och upprepbar, men styrkan med testautomatisering är att det möjliggör TDD! Att skriva testerna innan och samtidigt som koden (genom TDD) förkortar feedbacklopparna, förenklar koden, gör systemet testvänligt och spar tid totalt (för att räkna upp några fördelar).

.

Jag kan ge tre boktips. Det finns säkert fler bra böcker men dessa har jag läst och tycker är bra:

1) Agile Testing (Lisa Crispin and Janet Gregory) – En riktigt bra bok som berättar på en konkret och praktiskt sätt hur man bygger upp en bra agil test strategi.

2) Lean-Agile Acceptance Test-Driven Development (Ken Pugh) – Också riktigt bra. Den beskriver hur man går tillväga för att driva designen framåt i ett projekt genom testning (istället för genom krav).

3) Test Driven Development: By Example (Kent Beck) – Berättar på ett mer teknisk plan hur man går tillväga och kommer gång med TDD.

.

Hoppas detta svar gav några idéer och upplägg på hur ni går vidare i diskussionerna.

Med Vänlig Hälsning
/Jimmy

.

Annons

Publicerat i Q&A | Taggad , , , , | 2 Comments »

h1

Rapport från TestZonen 2012

tisdag, 20 mars, 2012

I helgen gick TestZonen 2012 av stapeln, en konferans där test stog i focus, arrangerat av gruppen bakom TestZonen.se.

Det blev en eftermiddag och en förmiddag sprängd till bredden med spännande diskussioner, mini-seminarier och debatter kring test, testaren, kvalitet och testautomatisering. Och mycket mera.

Här kommer en rapport och summering av vad som hände och sades. En ganska lång sådan…

.

Bakom arrangemanget stod Bengt Augustsson, Jonas Hermansson och Jagannath Tammeleth, grundarna och drivkrafterna bakom TestZonen.se. Deltagarna var skribenter och inbjudna inom test-branchen från hela Sverige. Konferensen hölls på Högberga Gård på Lidingö strax utanför Stockholm.

.

Välkomstdrink och lunch

Allt inleddes kl 11 med välkomstdrink innan lunchen. Jonas, Bengt och Jagge hälsar alla välkomna. Alla uppmanades twittra med hashtaggen #tz2012 om tankar och kommentarer kring det som pågick runtomkring. Detta ledde till att diskussionerna kring lunchen upptas med av diskussioner kring Twitter och Twitter-appen.

 

.

Invigning

Efter lunchen samlades vi i konferenssalen och TestZonen2012 invigdes med ett pampigt intro i Star Wars anda samt presentationen av eftermiddagens agenda. Deltagarna genomskådade dock ganska snabbt att agendapunkterna ”Mätplan”, ”Fontproblematik för testplaner” och ”Pivottabell = Agilt?!” var bluff.

  

.

Seminarie: Säkerhet ur ett testperspektiv

Första passet hölls av Viktor Laszlo (Prolore). Han berättade om sin erfarenhet av säkerhetstestning  från 4 år på Microsoft. Det kom att mest handla om Microsoft Security Development Lifecycle och STRIDE. Buskapet var att om man tar hänsyn till STRIDE (Spoofing, Tempering, Repudiation, Information Disclosure, Denial of Service och Elevation of Privilige) i sin hotbild behöver man inte förstå de individuella hoten, man har ett gott och tryggt säkerhetsskydd ändå. Det var mycket intressant, konkret och väckte nog mångas intresse och nyfikenhet kring säkerhetstestning.

.

Diskussion: Test i framtiden?

Efter Viktor seminarie var det dags för det första diskussionspasset. TestZonen 2012 kom att genomsyras av just bra, intressanta väldigt givande diskussioner! Första ämnet var: Test i framtiden? När grupperna summerade sina diskussioner tillsammans efter ca 30 minuter var det en ganska varierad framtidsbild som målades upp, även om vissa saker återkom.

Exempel på trender som togs upp: Testare och testyrket tas på allt större allvar. Allt fler tydliga expertis områden inom test växer fram. Marknaden efterfrågar testgenerallister allt mer. Agile ställer allt större tekniska krav på testaren i teamet. Testning kommer allt mer att handla om kvalitetscoachning.

  

.

Diskussion: Dropbox har problem.

Hade man tvivlat på att fokuset för TestZonen 2012 var just diskussion och nätverkande var alla tvivel som bortblåsta vid det här laget. Nästa övning bestod i att vi skulle planera upp testning kring Dropbox som kallat in oss (dvs. The Super Test Squad). Vi delades återigen upp i grupper om vardera fem personer. Jag och Martin Karsberg fann dock att vi var de enda två i vår grupp. Det började bra med en vårt eget förtydligande av uppdraget. Men eftersom vi bara var två kunde vi inte riktigt luta oss tillbaka på gruppens kollektiva intelligens (eller ansvarstagande). Resultatet blev trots det en fin färglagd serie (och varsin öl som belöning).

.

Seminarie: Spotify – How we do QA

Kristian Karl (testchef Spotify) höll i konferensens andra seminarie under vilket han berättade om hur Spotify arbetade med kvalitet. Eller nja… Det blev mest en beskrivning av Model-Based Testing. Mycket bra introduktion till MBT dock! Vidare hann Kristian diskutera testautomatiserare kontra testutvecklare, gorillan i rummet, m.m. Detta blev kanske inte den bästa summeringen av passet men det var mycket inspirerande och ryktet säger att Kristian fick demo MBT i baren långt in på kvällen.

.

Diskussion: Testledarens egenskaper

Första dagen avslutades med ytterligare en diskussion. Denna gång skulle vi klura över vilka de fem viktigaste egenskaperna hos en testledare var. För att jag själv skulle få rätsida på frågeställningen fick jag förenkla det i mitt eget huvud att handla om icke-agila projekt (då det i agila team inte finns någon testledare utan teamet tillsammans tar ansvar för test och kvalitet). Hur som helst, efter att grupperna presenterat sina resultat valdes fem finalister till egenskaper ut: Kommunikativ, Kunnig inom test, Strukturerad, Social kompetens, och på delad femte plats Lyhörd/Frågvis.

.

Middag och Mingel

Efter en energifull eftermiddag fick alla en välbehövd (om än kort) paus på rummet innan kvällen fortlöpte med fördrink, middag och barhäng. Jag hade en fantastisk trevlig kväll där dagens ämnen fortsatte diskuteras och jag många nya kontakter knöts.

.

Tipspromenad i morgondiset

Morgontrött som jag är hoppade jag över frukosten. Hörde dock från alla andra att den var fantastisk. Vad gör man inte för att få snooza…

Well well. Efter utcheckning var det dags för tipspromenad. Frågorna handlade på ett eller annat sätt om TestZonen. Tror Jonas, Bengt och Jagge fick med sig idéer på hur siten kan utökas och förbättras så att de har att göra lång tid framöver.

Efter promenaden fick vi en välförtjänt fika 🙂

  

.

Seminarie: Tolv feta klanterier från ett drygt decennium av testautomatisering

Sista kunskapspasset hölls av Jörgen Damberg (Claremont). Jag vet att Jörgen hållt mycket låda tidigare, och det märktes. Han fick skickligt med pulbiken i en lättsam och skämtsam dragning som ändå var sprängfylld med visdomar och erfarenheter.

Jörgen hade också helt klart den absolut snyggaste agenda-sliden jag sett, go C64!

Top 3 klanterier var hur som helst:

#1 Det är bara att spela in och spela upp
#2 Sänkta servrar på grund av fel fel fel
#3 Vi har tusentals tester automatiserade – det räcker väl?

.

.

Open Space

Näst sist ut på agenden var Open Space. Ämnen samlades och grupperna spred ut sig i konferensanläggningen. Själv föreslog jag ämnet ”Visualisering av testplaner/testscope inkl. progress och status”. Vi blev ett stort gäng som diskuterade Mind Maps, teamets behov kontra rapporter, och mycket mera. En superbra och inspirerande diskussion.

I pausen till andra Open Space passet var jag tyvärr själv tvungen att avvika men jag föreställer mig att andra passet innehöll lika många spännande parallella diskussioner som första.

.

Avrundning & Summering

Bengt, Jonas och Jagge avrundar konferensen och priser till TestZonens skribenter delades ut. Jag var som sagt inte kvar hela resan ut men det tog hela helgen att smälta alla intryck, idéer, tankar och diskussioner, och jag håller nog fortfarande på att reda ut en del tankar som far runt.

Super tack till arrangörerna och super tack till alla deltagare! Detta blev en riktig toppenkonferens och jag hoppas innerligen att Jagge, Jonas och Bengt finner tid och energi att göra om det. Jag vill tillbaka!

Vi ses på TestZonen.se!

.

.

.

Twittrandet

Just ja, det pågick stundtals febrilt twittrande också. Kommentarer, skämt, reflektioner och parallella diskussioner varvades om vartannat. Kan föreställa mig att det måste varit svårt att följa om man inte var där.

Några favoriter från flödet:

‏@BengtAugustsson: Vem faan tog allt varmvatten? Säkert en testledare!!! Blev en kalldusch efter en varm dag. #tz2012

‏@TedLundqvist: Samtliga förväntningar på konferensen är uppfyllda och då är inte ens middagen och puben avklarad. #tz2012

@KristianGMadsen: 4 st av alla testautomatiserare (ca 15?) i lokalen på #TZ2012 säger sig kunna försörja sig som programmerare => annat skillset! #sådeså

Här hittar du alla tweetsen med #tz2012:
https://twitter.com/#!/search/realtime/%23tz2012

.

Publicerat i Konsultliv | Taggad , , , | 4 Comments »

h1

Q: Hur estimera buggrättningar i Scrum?

torsdag, 2 februari, 2012

Titt som tätt får jag frågor från kollegor på Sogeti, kollegor ute hos kund eller från personer ute i vårt avlånga land som på ett eller annat sätt handlar om Scrum och Agile. Jag tänkte jag skulle börja dela med mig av dessa konversationer.

Jag vill också uppmuntra dig att maila mig om du just nu tampas med något problem eller frågeställning i just ditt projekt och önskar input och reflektioner från mitt håll. Jag ska göra mitt bästa för att svara på alla mail som kommer in och kommer att publicera valda frågor och dialoger här på bloggen (eventuellt i förkortad och redigerad form). För att maila mig, leta rätt på mail-ikonen i högerspalten.

Jag börjar på en gång och delar med mig av en fråga från en kollega jag fick i början av veckan 🙂

.

Q: Hur estimera buggrättningar i Scrum?

Hej!

Just nu försöker jag köra mitt första scrum-projekt. Det har då uppstått en del diskussioner i projektet ang estimering och rapportering av tid för bug-rättningar. (—)

Bör man lägga in en task för bug-rättning per User Story, eller bör man ta med tid för bug-rättning i estimatet för utveckling? Om man väljer det senare alternativet så blir ju utvecklingstask inte klara förrän test och rättning är klara.

Finns det någon tum-regel för hur mycket tid man bör estimera för bug-rättning?

Tacksam för goda råd!

Mvh
/###### 

Svar: 

Hej ######,

Angående estimeringar…

Det finns några olika approacher till detta…

  1. Anpassa Velocity – Anpassa velocity för varje sprint (dvs. antalet Story Points teamet committar till under sprint planeringen) så att det finns utrymme (luft) i sprinten att hantera buggrättningar parallellt med att man levererar funktioner och Story Points. Detta betyder att teamet under Sprint Planeringen bara committar till så många Story Points som man historiskt sett faktiskt klarar av att leverera under Sprinten.
  2. Skruva ner ”effektiv” arbetstid – Dra ner ”effektiv” arbetstid vid sprintplanering. Dvs. om man räknar med 6 effektiva timmar om dagen, räkna med fem istället. (Egentligen en version av 1:an.)
  3. Bugg-fix tasks till varje Story – Lägg till en task ”Buggfixning” med ett estimat (i timmar) för varje User Story. Ibland tar det längre tid, ibland blir det färre buggar rapporterade. Förhoppningsvis lär sig dock teamet justera storleken på dessa bugg-tasks allt bättre för varje sprint som går.
  4. Bugg-fix bucket Story – Lägg till en Story (Generell Buggfixning) till vilken man sätter en buffert med timmar att räkna av ifrån när man fixar buggar. När denna hink med timmar är slut lägger man bugg till produktbackloggen eller tar en diskussion med produktägaren om hurvida någon annan User Story ska senareläggas till förmån för buggfixning.

Vilken approach man väljer är egentligen upp till teamet. Välj den taktik som får arbetet och planering att flyta smidigast och som möjliggör snabbast hantering av buggfixning och som hjälper teamet leverera färdig, värdefull och testad mjukvara varje sprint.

Jag tycker inte att man ska betrakta en User Story som färdig förrän den är färdigkodad och färdigtestad i sprinten. Dvs svar ja: en User Story uppfyller inte DONE förrän den är kodad och testad.

Väntar man med testning och buggrättning till sprinten efter så har man naggat rejält i kanten på sin agilitet, introducerat risker och förlängt feedback-looparna samt försämrat insikten i vilken progress projektet faktiskt gör.

Angående rapportering…

Finns det externa krav på teamet (för att t.ex. kunna sortera isär arbetade timmar till olika budgetar) behöver man kanske rapportera och följa upp hur mycket tid som lagts på buggfixning och kanske till och med hur mycket buggfixning det blev för respektive User Story. Generellt finner jag dock inget värde i att logga arbetad tid på sådan detaljnivå då det oftast är svårt att omsätta denna typ av historik till användbar kunskap inför nästa planering. Men självklart, om det faktiskt hjälper teamet att göra bättre och träffsäkrare planering med sådan typ av historisk data – då ska man självklart göra det.

Att redovisa buggfixningstiden (för de User Stories man jobbar i pågående sprint) separat tycker jag är en väldigt dålig idé. Att utveckla betyder att man kodar, testar, fixar, tänker om, planerar nästa steg, kodar, testar, fixar, osv. tills det är klart. Det är så utveckling fungerar. Att fixa buggar på det man håller på med för stunden är en naturlig del av utveckling. Redovisas det separat riskerar man trilla i fällen att uppfinna sub-optimala lösningar för att parera detta. Alla sub-optimala lösningar saboterar alltid helheten.

Bugg-fixningstid som spenderas på features och funktioner som redan levererats tycker jag dock bör loggas separat. Denna tid är att betrakta som Waste då det faktiskt är olyckligt merarbete som beror på att man inte haft en tillräckligt bra teststrategi tidigare sprintar. Teamet ska dessutom hållas ansvariga för att ständigt förbättra sin testprocess och teststrategi så att kvalitén varje sprint blir högre och allt mindre tid behövs spenderas på att städa upp gamla misstag.

Mvh
/Jimmy

Publicerat i Q&A | Taggad , , , , , | 1 Comment »

h1

Press stopp: Nytt Sogeti-team – Agil testning och Testautomatisering

tisdag, 16 november, 2010

Från och med första januari 2011 finns ett nytt Sogeti-team i Stockholm: Agil testning och Testautomatisering. Undertecknad är tillförordnad teamchef. Känns sjukt spännande och utmanande, men också läskigt och nervöst.

Som en del i Sogeti Stockholms omorganisation har några nya team uppstått, ett av dem är teamet ”Agil testning och testautomatisering”. Vi (dvs. Sogeti) upplever ett starkt växande behov av skickliga testare som har erfarenhet av agila testekniker och testautomatisering hos våra kunder. Detta behov har bokstavligt talat exploderat den senaste tiden i takt med att allt fler går över till att driva projekt enligt Scrum, Kanban eller annan agil utvecklings- och leveransprocess. Något de flesta snart upplever är just stora utmaningar kring testning och kvalitet. Det är här Sogeti kan hjälpa till och bidra.

Teamet kommer inledningsvis att bestå av 15 till 25 stycken agila testare och testautomatiseringsexperter. Då det officiella startskottet för teamet är 1:a januari 2011 så kommer inte teamets medlemmar och storlek vara helt bestämt förrän om några veckor.

.

Sökes: Agila testare

Detta hindrar oss dock inte att redan nu söka efter dig som har en brinnande passion för agila utvecklingsmetoder och agil testning och är intresserad av att jobba som konsult i spännande och utmanande uppdrag med test och/eller testautomatisering.

Så om du har universitets- eller högskoleexamen och erfarenhet av agila testmetoder och agila testtekniker, eller test- automatisering, så kolla in jobbannonsen på monster eller www.sogeti.se!

.

Hjälp! Jag är chef…

Undertecknad kommer bli teamchef för detta nya team. Detta känns självklart superskoj att få förtroende och uppdraget att leda denna nya riktade satsning inom agil testning. Samtidigt känns det läskigt och lite nervöst då jag aldrig tidigare haft personalansvar eller resultatansvar för en enhet. Vidare, är branchen redo för en chef med mohikan och som gillar att blåsa i röda saxofoner?

Hur som helst, vissa möjligheter får man bara inte låta passera.

Vidare har jag en ambition att leda och driva teamet med de agila värderingarna som bas. Vad detta betyder konkret eller hur det realiseras har jag faktiskt ingen aning om i skrivande stund. Fast just det ser jag inte som något problem, snarare en möjlighet att praktisera ”Collective Ownership” och bjuda in hela teamet till att forma hur vi ska jobba tillsammans. Nu kommer ju teamet inte agera som ett tight Scrum team i ett och samma projekt, vi blir snarare en grupp individer som tillhör samma organisatoriska resultatenhet inom företaget. Med andra ord kommer inte alla agila principer vara betydelsefulla (eller meningsfull) i vårt kontext men som jag ser det måste man leva som man lär – förekommer ordet ”Agil” i teamets namn ska de agila värderingar också genomsyra hur teamet fungerar och arbetar!

.

2010 har varit mitt mest spännande år hittills genom min yrkeskarriär men nu börjar jag misstänka att 2011 kommer klå det med hästlängder. Jag har bara en sak att säga: Bring it on! 🙂

.

Publicerat i Konsultliv | Taggad , , , , , , , , | Leave a Comment »

h1

Fel, fel, fel!

måndag, 28 juni, 2010

Under Agila Sverige 2010 höll Joakim Ohlrogge från Agical ett mycket uppskattat blixttal som handlar om hur vi ser på fel och hur vi hanterar dem. Titeln för blixttalen var ”Fel, fel, fel!”.

Mot slutet av sin presentation argumenterar han för att vi kanske borde betrakta och hantera fel och testning på ett radikalt annorlunda sätt…

Det hölls många intressanta, insiktsfulla och lärorika blixttal under Agila Sverige 2010. Jag var inte där själv men har fått möjlighet att kika igenom dem alla på video efteråt.

Joakims tal fokuserar kring fel, hur vi betraktar dem och hur vi hanterar dem. Dels har vi antalet fel, dels har varje fel en ”allvarlighetsgrad”. Bilden blir dock inte komplett om vi inte dessutom tar hänsyn till hur lång tid felet existerar. En litet fel som existerar under en lång tid kan göra större skada än ett kortvarigt allvarligt fel. Det riskerar sluta i irritaion, frustration, färre användare, färre sålda produkter, osv. Med andra ord…

Felyta = allvarlighet x tid.
Den totala felytan kan då minskas på tre olika sätt:

  1. ”Släppa igenom” färre fel (minskar antalet fel)
  2. ”Släppa igenom” mindre allvarliga fel (minskar allvarligheten)
  3. Reagera på och hantera fel så fort som möjligt (minskar tiden)

Han argumenterar för att om vi kan agera snabbt och reparera fel fort kanske vi inte behöver vara lika rädda för att ”släppa igenom” fel. Även om felet är allvarligt blir felytan liten om felen bara existerar en kort stund.

Felytan för ett mindre allvarligt fel kan vara större än för ett kritiskt…

.

Konsekvens = Ingen testning?

Om man godtar felyta som vårt mätetal och som en mer sann beskrivning (för systemets kvalité ur ett defekt-perspektiv) fullt ut får det stora konsekvenser för vår testprocess.

Att minska antalet fel som slinker igenom och felens allvarlighet med en allt rigorösare testprocess är både kostsamt och tidskrävande, och gör dessutom inget för att dra ner livslängden på de fel som faktiskt hittas. Det kan till och med vara kontraproduktivt, en tung testprocess kan göra så att våra fel lever längre innan de blir åtgärdade.

Om vi istället fokuserar på processen (dvs. att höja kvalitén genom test driven development, par programmering, continuous integration, m.m.) och att möjliggöra snabba fixar (genom t.ex. defensiv programmering, defect proofing, rigorös loggning, etc.) samt att stöda snabba deployer av nya versioner som metoder för att minska felytan kan detta visa sig vara både betydligt effektivare och betydligt billigare.

Kan det vara så att det absolut effektivaste är att inte ha något testning alls? Hmm…

.


Joakim Ohlrogge är konsult på Agical AB.
Hans blogg heter ”The Point is Missed”.

.

.

Videoupptagningar från Agila Sverige 2010 hittar du här:
http://www.webbtv.nu/5557.htm

För att se ”Fel, fel, fel!” klicka på ”Celsius 20100510”.
När videon väl har laddats klicka på sista passet ”Fel, fel, fel!”.

Publicerat i Scrum metodik | Taggad , , , , | 12 Comments »

h1

”Slack” ger högre kvalitet och effektivitet!

torsdag, 24 juni, 2010

Bakom Agiles princip ”The sponsors, developers, and users should be able to maintain a constant pace indefinitely” döljer sig mycket visdom.

Det kanske mest uppenbara principen säger är ”Sprinta [som i att rusa fort framåt] inte”, se till att ha ett jämt tempo för alla inblandade.

.

Lagom tempo

  • Skapa inte falska förhoppningar om produktivitet (genom att t.ex. jobba för mycket övertid) som leder till att varje sprint blir en stressad kamp för teamet att hinna klart med alla löften.
  • Ha inte för långa Sprintar som tillåter teamet producera mera än verksamheten hinner absorbera och ge feedback på.
  • Ha en bra balans av kompetenser inom teamet så att det inte uppstår trafikstockningar i slutet (för t.ex. testning, integrering, dokumentation, etc).

Blir varje sprint stressad kommer snart vissa bränna ut sig, andra tröttnar på att anstränga sig och troligtvis kommer teamet så småningom att hitta ”hemliga” sätt att hantera detta på för att få en drägligare tillvaro. Detta i sin tur leder till att teamet kommer att prestera olika mycket varje sprint. Förutsägbarheten (och förmågan att planera framåt) och kvalitén undermineras och saboteras.

”Om du alltid spurtar så joggar du i själva verket bara!”

Pauser

Vidare ges ofta rådet att ha en paus mellan två sprintar, så kallad ”Slack Time”, dvs. ha inte Sprint demo på förmiddagen och Sprint planeringen på eftermiddagen. Ge teamet en chans att återhämta sig och vila upp sig. Både produktägare och teamet kan dessutom behöva en liten stund att fundera och smälta feedbacken och tankarna från Sprint demon och Sprint retrospective och för att samla sig för nästa iteration. Se till att åtminstone ha en natt eller en helg emellan.

.

Projekt-fria dagar!

Det kanske mest kontra-intuitiva rådet är att inte enbart ha en naturlig paus (som t.ex. en helg) mellan två sprintar, utan en eller två fria arbetsdagar under vilka teammedlemmarna får ägna sig åt precis vad de vill. Uppmuntra självstudier, laborationer, test av nya verktyg och tekniker osv. men ställ absolut inga krav på resultat! Låt kreativiteten, nyfikenheten och det personliga intresset stå i fokus.

Men, skulle det dock dyka upp buggrapporter på det teamet nyss levererat måsta de släppa det de håller på med och återgå till arbetsbänken till dess att problemen är lösta.

.

Kvalité blir heligt

Dessa projekt-fria dagar blir snart heliga för varje teammedlem. Teamet kommer att göra sitt yttersta för att inte riskera bli bestulna på sin ledighet!

Teamet kommer göra sitt allra bästa för att uppfinna metoder och tekniker för att bättre säkra kvalitén (genom t.ex. automatiserade tester, m.m.) och kommer att föra djupare och bättre dialoger med produktägaren, kund och beställare för att inte missförstå kraven. Ingen vill vara ”orsaken” till att resten av teamet fick avbryta sina projekt-fria dagar för att lösa ett problem man borde fångat upp under sprinten.

Jag låter det vara osagt om teamets arbete att höja kvaliten med detta grepp föds ur höjd teamkänsla eller grupptryck. Det lämnar jag öppet för diskussion…

.

.
Ursprungligen publicerad på sogeti.blogg.se
.

Publicerat i Scrum metodik | Taggad , , , , , | 2 Comments »

h1

Teknisk Skuld är mera än bara ful-kod

måndag, 10 maj, 2010

Medvetenheten kring Teknisk Skuld och dess betydelse för ett projekts agilitet sprider sig till snabbt. Detta är såklart en önskvärd trend, och troligen en livsavgörande insikt för vissa företag. Men om du förringar Teknisk Skuld till att enbart handla om kodens kvalitet så lurar du dig själv och risken blir stor att du kommer att ta beslut på felaktiga grunder.

Jag brukar påstå att Teknisk Skuld är den största fienden mot ett agilit projekt, dvs. förmågan att varje sprint ta sig an nya krav, lika många som förra sprinten, och känna tillit till att det man nyss levererat uppfyller DONE kriterierna och är av hög kvalitet. Ju högre Teknisk Skuld, desto dyrare att förändra och bygga vidare på koden och underhålla produkten.

Teknisk Skuld är ryggsäcken av ogjort, slarvigt eller dåligt utfört arbete, en ryggsäck vars tyngd gör att utvecklingen av en produkt går allt långsammare. Teknisk Skuld kan introduceras oavsiktligt (arkitekturen visade sig vara fel och svår att skala, den överarbetade programmeraren introducerar många buggar pga slarv), eller avsiktlig (genvägar tas och delar av arbete, såsom t.ex. dokumentation och test, skjuts upp för att hinna klart med releasen).

Oavsett orsak och härkomst så är teknisk skuld som ett kreditkort, förr eller senare måste du betala tillbaka din skuld om du vill göra nya stora inköp med kortet. Betalar du inte tillbaka utan väljer att ta ett sms-lån för att finansiera nästa utbyggnad sitter du snart fast i ränte-fällan.

.

Teknisk Skuld kan grupperas i följande kategorier:

Programmerings skuld
Dålig kod kvalitet. Slarvigt skriven. Samma kod förekommer på flera ställen. Skör kod (dvs. svår att ändra på utan att något går sönder). Obegriplig för någon annan än utvecklaren själv. Krånglig och besvärlig att bygga vidare på.

Design skuld
Dålig eller ingen design. Stel arkitektur. Avsaknad av (eller felaktigt skurna) lager. En snårskog av klasser och moduler. Det är enklare att bygga den nya funktionen som ett plåster utanpå istället för att utnyttja arkitekturen som tänkt.

Test skuld
Delar av systemet har inte testats, testats dåligt eller på fel sätt. Okänd testtäckning. Fallerar ett gammalt automatiserat test är det svårt att veta om testet är fel eller om koden gömmer en defekt.

Kunskapsskuld – Det finns isolerad och odokumenterad kunskap. Kod är svår att förstå pga av avsaknad av kommentarer. Samma fel upprepas pga att lessons learned inte sprids. Isolerad kunskap skapar resurs-flaskhalsar. Nya teammedlemmar har svårt att komma upp till ett produktivt tempo. Förvaltning står handfallen när något går galet pga avsaknad av rätt teknisk dokumentation.

.

Farliga och fördummande förenklingar

Dessvärre verkar vissa ”agila experter” enbart rikta in sig på kod-aspekten av teknisk skuld. En farlig och fördummande förenkling. Vissa försöker till och med göra pengar på detta. Bara för att programmeringsskulden är enklare att mäta (med hjälp av olika  analytiska verktyg) än de andra aspekterna betyder det inte att man får glömma bort test-, design- och kunskapsskulden, aspekter som tillsammans kan gömma betydligt högre kostnader än programmeringsskulden.

För att ta ett exempel; ”The Agile Executive” är en blogg jag följer. Den tar bland annat upp teknisk skuld från en mängd olika och spännande vinklar och har skrivit en radda mycket bra artiklar om ämnet. Grytan bubblade dock över för mig när de häromdagen annonserade ut och hyllade Cutter Consortiums nya tjänst, ”New service boils down technical debt to $$; ties it to cost and value”, i en artikel. Tjänsten fokuserar enbart kring kodens kvalitet och genom att förenkla ner detta till några mätetal extraherar Cutter sedan priset på den tekniska skulden i pengar eller man-dagar.

Här är ett annat exempel på när den tekniska skulden reduceras till kod-kvalitet:
http://www.infoq.com/news/2010/03/monetizing-technical-debt

.

Nödvändiga förenklingar?

Missförstå mig dock rätt, jag tycker det är en vacker och eftersträvansvärde tanke att kunna åskådliggöra teknisk skuld med ett konkret pris. Kanske t.o.m. nödvändig för att få förståelse och mandat från Produktägare och beställare för att adressera och förebygga tillväxten av Teknisk Skuld.

Jag anser dock att förenkla det till några enstaka kod-tekniska faktorer är dock farligt förenklande, till snudd på fördummande, och svaret blir inget annat än en delmängd av sanningen.

Publicerat i Konsultliv | Taggad , , , , , , | 4 Comments »

h1

I gränslandet mellan Scrum och Vattenfall

tisdag, 13 april, 2010

Nu så har dedikerad testare vaknat till och engagerat sig i ett av projektet jag är engagerade i just nu. Arbetsmetoder börjar ta form, ansvarsgränser målas upp men det tighta schemat genomsyrar hela tiden diskussioner, taktik-snack och projektgruppsmöten.

Test Planen ska diskuteras nästa vecka men jag gissar att jag kommer ha mycket åsikter och synpunkter då den tagits fram med en stor kappsäck av vattenfallsmentalitet trots att projektets testcoach vet om att vi angriper utvecklingsfasen i projektet med Scrum. Min egen roll i projektet är Technical Lead och Scrum Master.

En annan utmaning jag tampas med på daglig basis är kommunikationen med projektledaren. Hon gör ett fantastiskt jobb att koordinera alla parter (stort integrationsprojekt) men hennes angreppssätt är att strikt rada upp allting sekvensiellt och mäta progress i %, oavsett vad det rör sig om. Allt eller inget.  Antingen är det inte påbörjat, X% klart eller helt klart. Inget utrymme för förändring i målbild eller utförande. Dvs. vattenfall. Tilläggas kan att programmeringen och test tar upp ca 10 rader i hennes 120 rader långa detaljplanering. ”Do not touch my perfect plan” får vara dagens citat. (Levererades när jag försökte påpeka att planen kanske borde uppdateras med hänsyn till vår nya kunskap).

Det kommer att bli några spännande sprintar framöver för utvecklingsteamet och mig själv när vi ska försöka leva, leverera och överleva i gränslandet mellan Scrum och Vattenfall. Den uppenbara risken är såklart att eventuella förseningar och/eller problem skylls på den nya kompisen i gänget (Scrum) istället för de sanna grundorskarna (som t.ex. skulle kunna vara dåliga estimat, dåliga förustättningar eller yttre störningsmoment för att nämna några) och att den nyväckta glöden till Scrum i utvecklingsteamet släcks.

Men det är också såklart väldigt utmande och spännande att få vara med att påverka en organisation till att jobba mera agilt och att lära sig fokusera mer på det levererade affärsvärdet, eliminera arbete som är tidsslöseri samt  maximera kontaktytan mellan utveckling och beställare för att bygga så bra lösningar som möjligt. Speciellt roligt är det såklart när stakeholders och teammedlemmar själva kommer med förslag som gör processen och arbetssättet mera agil.

Skulle det börja regna för mycket i vattenfalls-land är det bara göra som man brukar, ta på sig regnjackan och kavla upp ärmarna och jobba på så gott man kan tills man kommer i mål.

För eller senare så tror jag att alla företag som är intresserade av att överleva i en hårt konkurransutsatt marknad måste övergå till en lean organisation som utvecklar agilt.

Jag kommer med stor säkerhet få anledning att återkomma med fler reflektioner, kommentarer och summeringar hur det går för oss att leverera mjukvaran enligt Scrum till ett projekt som i övrigt drivs enligt vattenfall.

Fram tills dess tänker jag falla tillbaka på mantrat:
”Fake it until you make it”!

Publicerat i Konsultliv | Taggad , , , | Leave a Comment »