h1

Blixttalar på Agila Sverige 2012

torsdag, 12 april, 2012

Den 23-24 april är det dags igen för femte året i rad – Agila Sverige 2012 slår upp dörrarna. Jag ser verkligen fram emot att få delta i alla spännande diskussioner, lyssna till alla blixttalen och knyta nya kontakter. Jag ska också leverera ett eget blixttal; ”Krav är en flyktig version av målet”.

Sista datum för anmälan var tyvärr i söndags men det brukar vara möjligt att ta del av blixttal efteråt då de åtminstone tidigare har spelats in på video. Håll utkik på hemsidan för Agila Sverige efter dessa.

Själv förbereder jag mig inför mitt eget blixttal jag ska hålla. Jag är inte på långa vägar färdig med presentationen men jag vet vad jag vill berätta och har idéer på hur jag ska kunna förmedla mina tankar och mitt budskap i ett engagerande 10-minuters blixttal. Länk till eventuell video kommer såklart efter konferensen.

Hoppas vi ses där!

.
Mer info om Agila Sverige 2012 hittar du här.
.
Följ diskussionerna kring #agilasverige på Twitter här.
.
Läs mitt blogginlägg om Agile Sverige 2011 här.
.

.

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

.

h1

Morgonhälsning

onsdag, 28 mars, 2012

Imorse när jag kom till kunden möttes jag av följande syn. Nästan allt på mitt skrivbord var märkt med Post-its. Till och med Post-its bunten. Försöker mitt team säga mig något?


(Klicka på bilden för en större version)

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

.

h1

Övning: Agile Values

onsdag, 29 februari, 2012

Nu har jag lagt upp ytterligare material under ”Verktyg och Mallar”. Denna gång blir det en övning som jag själv kört flera gånger med fantastiskt resultat.

”Agile Values” är en diskussionsövning under vilken teamet eller projektet får en chans att fördjupa sin förståelse kring agiles och leans principer, men framförallt en möjlighet att diskutera dem!

Under övningens gång (som tar cirka 90-120 minuter att genomföra) får teamet (alternativt projektet eller avdelningen) en chans att diskutera agiles och leans principer och värderingar. Inte nog med det, grupperna får också en chans att diskutera hurvida man tror att principerna och värderingarna är sanna – dvs. är de viktiga att följa och värna om för att projektet ska nå maximal framgång?

.

.

Du hittar övningen genom att klicka här, eller på ”Verktyg och mallar” i högerspalten.

.

h1

Q: Om Chief Product Owner, Managers och Kravägare?

fredag, 24 februari, 2012

Många företag och organisationer kämpar med att få till en bra dialog kring prioriteringar och kravdetaljer med beställare och verksamhet.

I större organisationer som inte i mål med att forma om sig för att stötta agila projekten i sina leveranser blir ofta just produktägaren (och verksamhets- experter) en flaskhals.

För några dagar sedan fick jag detta mail:

.


Hej Jimmy!

Tack för en bra blogg. Såg att du gärna mottog frågor om Scrum så tänkte maila om det jag funderar på.

Vår nuvarande Product Owner har inte varit närvarande och han har haft massa sidouppgifter. Tanken är nu att han ska blir Chief Product Owner med underordnade Product Owner för olka delar av vårt system då det är stort och komplext. Till detta så kommer det även för stories att finnas kravägare som man får för sig att varje team ska vända sig till med frågor. Mina funderingar om detta:

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det? För som jag förstått det så ska produkägaren/ägarna har väldigt god koll på alla stories?

Mvh #####



Hej #####,

Roligt att du tycker om bloggen! Och tack också för din fråga. 

Såhär tänker jag…

1. Om vi har en huvud produktägare, visst borde denna kallas Chief Product Owner istället för Product Manager?

Jag håller med om att Chief Product Owner är ett lämpligare namn. Det är vedertaget och har en betydelse inom den agila litteraturen och inom Scrum-metodiken. Viktigare än namnet är dock såklart rollens syfte och förväntad roll i projektet.

.

2. De under ordnade produktägarna bord väl kallas Product Owner of Function A och inte Functional managers vilket ger associationer till något helt annat?

Personligen gillar jag beteckningen ”Area Product Owner <Functional Area>” fast ”Product Owner of Function A” tror jag säkert fungerar lika bra. Dock blir jag lite fundersam över begreppet ”Function” här. Det låter som om risken finns att det blir ett för smalt område, men å andra sidan har jag ju ingen insikt i ert system.

Men jag håller med om att ”manager” ger helt fel associationer. Att vara produktägare handlar inte om ”management”, det handlar om att representera kunden och förmedla en vision, roadmap och kunskap kring features och funktioner till teamet. Produktägaren är en del av teamet, inte en av teamets managers.

Vidare, om man har en hierarki med produktägare (vilket man bör ha när man skalar upp Scrum till flera team) så är det viktigt att definiera och farankra vilket mandat produktägarna har över sin egen produktbacklogg. På sätt och vis utgör produktägarna ett virtuellt team vars förmåga och vilja att samarbeta kring roadmaps och prioriteringar är centralt. Varje team ska inkludera en produktägare som bistår teamet i diskussioner kring vision, roadmaps och prioriteringar – på daglig basis, aktivt och proaktivt. Vidare ska varje team ha sin egen produktbacklogg. Om flera team delar samma produktbacklogg anser jag att man hamnar man i flera trassliga situationer.

I detta virtuella ”Product Owner Team” är det viktigt att diskutera och enas kring vilket mandat Chief Product Owner förväntas besitta? Vilket mandat och ansvar blir över till Area Product Owner?

.

3. Ska verkligen kravägare vara den som teamet pratar med? Bör det inte vara produkägarna som teamet kommunicerar med i det?

Jag kan ju bara gissa vad ”kravägare” betyder hos er.

Alt 1. Kravägaren är personen som beställt en viss funktion av produktägaren (alt. produktägarteamet). Personen har ingen detaljerad åsikt kring exakt hur funktionen ska implementeras men är väldigt mån om att få funktionen levererad.

Alt 2. Kravägaren har på uppdrag av produktägaren ett ansvar att konkretisera funktionen och har mandat att utforma detaljerna i kravet.

Alt 3. ?

Oavsett vad – om det finns någon utanför teamet som har speciell verksamhetsexpertis eller kunskap om vad användarna vill ha som inte produktägaren besitter ska denna person vara en del av teamet, åtminstone under den period man jobbar med det kravet.

Han eller hon ska stötta produktägaren i att konkretisera kravet till PBI:er (Product Backlog Items/User Stories), splittra upp det i flera beståndsdelar och sedan förklara affärsvärdet för var och en av de mindre delarna så att produktägaren kan göra en bra prioritering av produktbackloggen.

Vidare, när det är dags att förvandla kravet till värdefull fungerande mjukvara ska personen göras till en teammedlem som på deltar på det dagliga mötet, designworkshoppar och diskussioner samt kan vara med och diskutera de sista detaljerna med testare och utvecklare när kravet faktiskt överstätts till fungerande kod. Teamet (med eller utan ”kravställare”) har inte mandat att utöka/minska omfattningen av funktionen utan att rådgöra med produktägaren – teamets uppgift är att förvandla tydligt definierade och avgränsade krav (User Stories) till fungerande värdefull mjukvara efter produktägarens prioriteringar.

Har inte produktägaren tid till detta (dvs formedla kunskap eller ha åsikt kring kravdetaljerna), eller inte sitter inne med den verksamhetsexpertis eller kundkunskap som behövs, ja då ska teamet utökas med en person som faktiskt har det. Återigen, titeln är inte det viktiga – fokusera på syftet och samarbetsformen.

.

Jag hoppas dessa kommentarer och reflektioner ger dig något av värde och kan hjälpa er i ert arbete och diskussioner.

Jag kan också rekommendera en bra bok som bland annat adresserar dessa frågeställningar och utmaningarna när man skalar upp till flera Scrum team som tillsammans bygger en produkt/ett system.

Den heter ”Scaling Lean & Agile Development – Thinking and Organizational Tools for Large-Scale Scrum” och är skriven av Craig Larman och Bas Vodde.

h1

Ikon-mani på Scrum-väggen

torsdag, 23 februari, 2012

I projektet jag är Agile projektledare och Scrum Master i just nu har vi tapetserat 8 meter vägg med allehanda Backlogs, Burndowns, grafer, prognoser och information. Det har också skett en mindre explosion i antalet ikoner vi använder oss av för att tydligare visualisera vad som pågår och vilken status arbetet är i.

Väggen som helhet ser ut såhär:


(Klicka för att se en större bild. Sprint Backloggen är ytan i mitten som är tjock med Post-Its.)

.

Sprint Backloggen

Sprint Backloggen är enkelt strukturerad:

Task-lapparna beskriver saker som ”Implementera X”, ”Koda Y”, ”Fixa Z”, ”Skriva testfall”, ”Systemtesta”, ”Skriva systemdok”, ”Fixa browserkompatibilitet”, ”Acc Test”, m.m. m.m.

Jobbar man med en task så placerar man en av sina egna avatar ikoner på eller bredvid Task-lappen. I projektet blev temat av någon anledning superhjältar i olika skepnader. Vi har ”The Governator”, ”The Iron Lady”, ”Chuck Norrs”, ”Yoda”, m.fl. som var och en representerar en person i teamet. Varje person har max tre avatarer, dvs. man tillåts inte jobba med mer än tre saker samtidigt. Oftast används dock bara en eller två samtidigt, vilket är bra.

Varje task i ”In work” kolumnen uppdateras dagligen dessutom med ett estimat på återstående effektivt arbete i timmar. (Dessa summeras dagligen i Sprint Burndown charten.) För varje dag som en task sitter i ”In Work” kolumnen får den dessutom en prick på sig så att vi kan se hur många dagar den suttit där. De flesta tasks är så små att de ska vara möjliga att slutföra under en dag så om antalet prickar växer vet vi att något skumt pågår.

Denna uppbrytning har dock inte visat sig vara en tillräcklig visualisering av nuläget. Så, för att komplettera status och vad som händer använder vi oss av en stor skara laminerade ikoner som vi fäster med häftmassa på Feature-lapparna eller Task-lapparna.

Förhoppningsvis ger det någon inspiration så håll till godo, här kommer ikonerna 🙂

.

Status ikoner

Topic för morgondagens Daily Standup
Om det är något vi känner att vi vill diskutera tillsammans i teamet på nästa morgonmöte markeras Feature- eller Task-lappen med denna ikon. Varje morgon scannar vi Backloggen det sista vi gör efter dessa Daily-ikoner, diskuterar dem, och tar sedan bort ikonen.
Top Prio!
Denna ikon signalerar att denna Feature eller Task är något som vi verkligen behöver fokusera på tillsammans!
Tar konstigt lång tid
Om en task fortsätter sitta i ”In Work” kolumnen dag ut och dag in gör vi alla uppmärksamma på detta med denna ikon. Uppenbart så pågår något underligt. Antingen så är personen störd av andra åtaganden, eller så behöver han/hon hjälp. Oavsett vad, något lurt pågår.
Pausat
Av någon anledning kan vi för tillfället inte jobba vidare med denna task. Antingen väntar vi på svar eller information från någon utanför teamet, eller så kanske personen som jobbade på uppgiften gått och blivit sjuk.
Frustration!
Med denna ikon delar vi med oss av den frustration vi upplever. Häromdagen hade en om samma task tre stycken frustrationsikoner. Så jobbigt var det att få ordning på den.
Defekter spökar
Denna ikon har vi använt lite olika men nu verkar det som om vi börjat använda den för att signalera att systemtesterna inte nått i mål på grund av funna buggar.
Färdig 🙂
För att komma ihåg vad man gjorde dagen innan så placerar man denna ikon på tasken när man flyttar in den i ”Finished” kolumnen. Då blir det mycket enklare att summera gårdagen på nästa Daily Stand-Up.
.För att tydligare visualisera vilka funktioner som är redo för systemtest och vilka som är redo för acceptanstest har vi nyligen skapat ytterligare några ikoner. Det visade sig att det inte var uppenbart enbart genom att kolla av i vilken kolumn våra Task-lappar satt för att avgöra i vilken miljö featuren fanns i.
Awaiting ST Deploy
När utvecklaren känner sig färdig och redo med funktionen och har gjort grundläggande testning i sin egen utvecklingsmiljö är koden redo att läggas upp i Systemtest (ST) miljön. Detta markerar vi genom att placera denna ikon på den stora Feature-lappen.
System test Ready
När funktionens kod har hamnat i ST-miljön (efter ett sk ”lyft”) markeras Feature-lappen med denna ikon. Det betyder att Systemtest-fall är skrivna och att vem som helst (förutom personen som utvecklade funktionen) kan påbörja systemtestning.
Awaiting AT Deploy
När systemtest är genomförd och teamet känner att funktionen är av tillräckligt hög kvalitet för att lyftas till acceptanstest (AT) miljön placeras denna ikon på Feature-lappen.
Acceptance test Ready
Denna ikon signalerar att funktionen finns i acceptanstest miljön. Dvs. när uppgradering sker av AT-miljön byts ”Awaiting AT Deploy” ut mot denna ikon. Det kan finnas kända problem, men den håller tillräckligt hög kvalitet för att teamet ska vara redo att ta emot feedback från acceptanstestning.
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

h1

SKIP Scrum Seminar (22:a Feb i Göteborg)

tisdag, 31 januari, 2012

Den 22:a februari bär det iväg ner till sveriges framsida. Anna-Lisa Gustavsson, en vän från Göteborg, har bjudit in mig att föreläsa om Scrum och om vad det betyder att jobba agilt under ett seminarie på IT-Universitetet i Göteborg. Det är studentorganisationen SKIP (Systemvetarklubben för informatik och programmering) som står för arrangemanget.

.


(Klicka för större bild)

.

Ska bli jätteroligt att ta en tur ner till Götet för att föreläsa för studenterna på Chalmers. Förhoppningsvis hinner jag också träffa några gamla vänner och kollegor därnere samtidigt.

Om du inte är student på Chalmers men är intresserad av att komma ändå vet jag inte riktigt hur du går tillväga. Kanske kan du hitta mera information på facebook-sidan för eventet eller på SKIPs hemsida.

.

Vi kanske se! 🙂

.

h1

Filminspelning – 1 minut om Sogeti och Agile

fredag, 2 december, 2011

Nu på morgonen fick jag förmånen att delta i en marknadsföringsinsats på Sogeti. 1 minut film om min passion för Scrum, varför agilt är den enda vettiga vägen att gå och att Sogeti är experter på agile och scrum, skulle spelas in.

Men det är konstigt. Jag kan utan problem och utan nervösitet och stamningar hålla låda i 2 timmar på seminarier om agil utveckling och Scrum, men när det skulle konkretiseras på en minut blev det kämpigt. Nåväl, hoppas resultatet blir ok. Den som lever till januari får se…

Sogetis Therese Sinter hade arrangerat en studio tillsammans med Conventus Media House i Stockholm. Det blev snabbt varmt framför lamporna… Men skoj var det 🙂

.