Posts Tagged ‘kvalitet’

h1

Det är dyrt att vara riktigt agil. Eller?

onsdag, 2 november, 2011

Att vara agil när man jobbar i Scrum betyder (bland annat) att man efter varje iteration har lyckats bygga en ny fungerande och värdefull version av produkten (eller systemet) som går att leverera till kund eller butik om man så önskar. Men att vara riktigt agil kostar. Eller?

För att varje sprint ska resultera i en nytt levererbart inkrement ställs det stora krav. Först måste vi ha lyckats bryta ner våra features så att de är tillräckligt små så att flera får plats i sprinten. Och med ”få plats” menar jag att man hinner med allt för att gå från idé till leverans, dvs. varje enskild feature ska designas, kodas, testas, dokumenteras och sammanfogas med helheten (allt enligt vår Definition of DONE for User Stories). Vi behöver dessutom känna oss trygga i att resten av systemet fortfarande fungerar och att vi inte har introducerat nya buggar.

Om vi förutsätter att vi har kontroll över våra IT-system och inte har några externa beroenden vad gäller testmiljöer och servar (vi är inte beroende av externa köer för att få något jobb gjort) så är det ändå inte helt trivialt att få till en leverans varje sprint.

Låt oss titta på ett exempel på hur en treveckorssprint skulle kunna se ut.

.

Först och främst har vi våra Scrum möten. Syftet med dessa är att planera (läs analysera) vad vi ska göra härnäst (Sprint Planning), hur vi på bästa sätt koordinerar oss inom teamet (Daily Scrum), fånga upp feedback så att vi kan förbättra processen (Sprint Retrospective) samt lära oss vad som kan göra produkten ännu bättre (Sprint Demo). Sista fredagen är dessutom en sprint-fri dag där teamet kan hämta andan och samla ny energi till nästa sprint.

.

För att vi med trygghet ska vilja lämna ifrån oss den nya versionen (som innehåller våra nya features) vill vi dessutom känna oss trygga i kvalitén. Detta gör vi med att arbeta med att fixa buggar och verifiera buggfixar (Hardening). Vi vill också testa igenom systemet i sin helhet för att försäkra oss om att vår nya kod inte saboterat någon annan funktionalitet eller försämrat någon egenskap (såsom t.ex. prestanda). Denna testning inleds typiskt med en uppgradering av acceptancetestmiljön. Hela teamet hjälps åt att testa. Vad man fokuserar på klurar man ut som team genom att göra en riskanalys. Det kan t.ex. innebära en balans mellan körning av delar av regressionstestsviten plus identifierade Exploratory Testing sessioner. Var man lägger sin testfokus beror på var man ser att riskerna finns, vilka moduler som utsatts för förändring etc. När så slutgiltig paketering är gjord och en sista hand har lagts på dokumentationen är teamet redo att leverera den nya versionen till kund eller förvaltning. Tada!

.

Det som återstår är vårt utrymme för utveckling. Det är alltså denna tid som finns tillgänglig för design, kodning, testning och dokumentation av nya features. Det vi påbörjar ska hinna slutföras innan ”Code-freeez-mode” slår till.

.

Sådärja. Då har vi lyckats visualisera de olika typerna av arbete som pågår under en sprint. Låt oss visualisera hur de olika formerna av arbeta står i proportion till varandra…

.

Nu ska man ställa sig två frågor:

Vilket arbete tillför värde?
Vilket arbete är waste?

.

Eftersom exemplet inte förtäljer hela historien så kan vi bara spekulera. ”Development” och ”Scrum Meetings” tillför såklart värde, det är här vi skapar, analyserar, planerar, designar och koordinerar oss. Sedan bör vi ställa oss frågan – kan Scrum mötena (såsom sprint planeringen) göras effektivare och kortare?

”Hardening” borde inte behövas om vi byggde kvalitet från början. Detta är tydlig waste. Packaging, miljöuppgraderingar etc. döljer också troligtvis en hel del waste – detta borde gå att automatisera.

Den gemensamma testinsatsen som sker i slutet av sprinten… är den waste? Jag skulle argumentera för att den inte är det – här bygger vi kunskap om hur systemet som helhet mår efter att vi infört våra förändringar och bygger beslutsunderlag till frågan – ska denna release gå till kund?

.

.

Det som blir uppenbart av att titta på bilden är dock att själva utvecklingen av nya features som mest utgör hälften av arbetet. Mycket tid går åt till ”annat”. Man skulle kunna påstå att Velocityn blir ”lidande” (antal features eller Story Points per sprint) eftersom vi anstränger oss för att vara helt agila. Från ett leveransperspektiv är det så att varje sprint levererar ett färdigt och komplett increment, dvs. Definition of DONE för User Stories är komplett och lämnar inget till senare. Vi VET att vi hela tiden är redo för leverans till kund. I exemplet ovan ”vet” vi att vi har levererat 24 features när deadline närmar sig.

.

Att vara helt agil i Scrum kostar så det är enkelt att lockas till att flytta ut vissa kriterier från Definition of DONE for User Stories till Definition of DONE for Release. Dvs. vi skjuter viss testning, viss dokumentation, etc. till en ”release sprint”. Detta ökar vår Velocity (antalet features per sprint), men vi är å andra sidan inte leveransredo varje sprint eftersom vi har skjutit arbete och risk framför oss. Faktum är att release sprinten troligtvis inte alls blir en strikt timeboxad sprint eftersom vi inte vet hur mycket arbete och risk vi skjutit framför oss förrän vi sitter ner och planerar (och exekverar) den sprinten. Med detta upplägg kanske vi levererat 30 features när deadline kommer, men det troliga är att vi kämpar med testning, buggfixningar och refactoring av tekniska svagheter långt förbi deadline. Vad ännu värre är att vi har skapat en rejäl fördröjning i feedbacken mellan test och kodning då vissa tester inte körs förrän så mycket som fem sprintar senare.

.

Att inte vara DONE utan att först uppnå DONE i release sprinten öppnar upp för följande:

Vi riskerar missa deadline
Vi introducerar waste genom långa feedbackcyckler (både vad gäller test och kvalitet men även kundens feedback om funktions värde)
Vi skjuter på tekniska risk och missar chansen att hantera problem tidigt
Vi tappar den sanna insynen i hur vi faktiskt ligger till (vi vet inte vad som är klart och vad som är ”work in progress” eftersom vi inte testat klart)
Vi förlorar styrförmåga. Innan vi helt kan styra om fokus måste vi genomföra release ”sprinten”.

.

Så är det dyrt att vara agil, eller är det kostsamt att inte vara det?

.

Annonser
h1

SAST Q2 – Tema Agil Testning

torsdag, 21 april, 2011

Förra veckan gick konferensen SAST av stapeln. Temat för Q2 mötet var Agil Testning och det lockade fullt hus. Seminarierna var på en kanske all-time-high nivå, och SASTs provskott på Open Space blev en succé!

Frukostmingel på SAST Q2 2011

.

SAST Q2 var slutsålt flera veckor i förväg och likaså högg sponsorerna som hajar på de tillgängliga monterplatserna. Tyvärr lyckades inte Sogeti norpa sig en plats denna gång vilket jag såklart tycker var olyckligt eftersom jag är teamchef för ett nytt team på Sogeti med konsulter som är experter inom just agil testing och test automatisering. Jag gjorde hursomhelst mitt bästa för att delta i diskussioner och hålla Sogeti fanan högt.

Som jag nämnde var kvalitén på seminarier bättre än någonsin denna gång. Dels berodde det såklart på duktiga talare, men jag tror också det nya konceptet med att begränsa varje presentation till 20 minuter också gjorde att varje talare ansträngde sig lite extra för att göra sitt budskap så tydligt och kompakt som möjligt. Arrangörerna hade gjort ett riktigt bra jobb med logistik, mat och planering och ska också ha en rejäl eloge för att de vågade prova konceptet Open Space på SAST. Jag återkommer till detta lite längre ned.

Närvarande arrangörer presenterar sig.

.

Mini-seminarierna

Nästan alla 20 minuters mini-seminarier höll riktigt hög kvalitet. Som alltid är det något man är mindre intresserad av men jag vill fokusera på några som fångade min uppmärksamhet till fullo.

Måns Sandberg (bild ovan) från Adaptiv öppnar med att berätta om de agila värderingarna, om vad det betyder att vara agil, om samarbete och om faran med dogmer. Han var också den första talare som provocerat påstod att det finns utrymme i vissa branscher att i några år till fortsätta jobba långsamt och icke-agilt men vill man vara en del av framtiden och kunna matcha konkurrenter måste man lära sig att bemästra agil utveckling och agil testning. Själv tycker jag inte det finns något kontroversiellt i detta men jag tror nog att det fanns en del personer i publiken som kanske kände sig en smula provocerade och kritiserade av ett sådant påstående.

Ola Sundin från Ongame berättade om hur de jobbat med Modellbaserad testning, ett nytt angreppssätt för min del. Mycket intressant att höra på hur de jobbade med att genom modeller automatgenerera testfall och hitta nya infallsvinklar till testscenarier.

David Evans från SQS Nordic (bild höger) höll dock den presentation som jag tyckte var självklart bäst, sprängfylld med skarpa observationer och spännande insikter. Rubriken var ”Agility & Risk Challenges for your Agile QA Strategy” vilket han gjorde ett fantastisk jobb att leverera på 20 minuter. Titta gärna på hela hans seminarie (se länk nedan), men det var framförallt en slide jag föll för speciellt, och som jag flitigt kommer citera framöver – ”Agile Acceptance Testing slows down deveploment just as passangers slows down the bus. The speed of the bus is not the point.” Tycker dock inte alls att man behöver begränsa sig till acceptanstestning utan denna liknelse borde genomsyra synsättet på test generellt!

.

Open Space

Med start klockan 14 och fram till och med dagen avslutades med utvärderingar (a lá Sprint Retrospectives) provad SAST för första gången Open Space konceptet. I sju diskussions hörnor utspridda i lokalen pågick diskussioner och debatter. Varje hörna hade sitt i förväg bestämda ämne. Det diskuterades Definition of DONE, agila testverktyg, testautomatisering, agil kravhantering och mycket mycket mera. Vissa diskussioner slutade någon helt annan stans än där de började, vilket såklart är en bra sak när man kör OpenSpace. Vidare uppmanades alla att följa ”de två fötternas lag”, dvs. tappar du intresset för en diskussion sök dig till någon annan som intresserar dig mera. Detta ledde ytterligare till att höja kvalitén och intensiteten på de debatter som pågick.

Open Space pågår för fullt.

Dessa avslutande timmar blev min höjdpunkt av dagen och jag kan bara hoppas att arrangörerna gör detta till en stående punkt i agendan och kanske t.o.m. kör konceptet fullt ut framöver, dvs. låter deltagarna själva forma innehåll och rubriker för diskussionspassen.

Allt som allt, en riktig toppendag 🙂

.

Twitter och video

Under SAST Q2 twittrades det flitigt.
Läs twitterflödet här: http://sastq2.blogspot.com/

Mini-seminarierna sändes även live över bambuser.
Se inspelningarna här: http://bambuser.com/channel/SAST

.

Glad Påsk!

.

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!”.

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

.

h1

Om att mäta det agila projektets framgång (2/6) – Resultat

tisdag, 15 juni, 2010

Hur vet man att investeringen i utvecklingen matchar förväntningarna? Hur håller man koll på att projektet levererar ”i tid”? Hur mäter vi att mottagarna och beställarna är nöjda? Scrum påstår sig leverera mera funktionalitet av högre kvalitet som bättre matchar förväntningar och behov. Men hur mäter man och följer upp detta? Detta är andra delen av min artikelserie om tips, trix och verktyg för att mäta det agila projekts framgång och status.

Nedan listar jag några verktyg och mätvärden användbara för projektets produktägare och styrgrupp (Meta-Scrum) för bland annat release- och resursplanering. Men som alltid ska man ställa sig frågan varför man mäter något? Vad ska statistiken användas till? För vem är mätvärdet värdefullt? Historisk statistik på ett mätvärde i sig har inget värde, det är först när vi omsätter det till kunskap, insikt och handling som det ger oss något tillbaka. Fram tills dess är insamlandet och sammanställandet waste och kanske t.o.m. kontraproduktivt. Vi riskerar att belysa fel saker och kanske luras försöka bota symptom istället för det bakomliggandet problemet.

.

Release Plan vs. Effektmål

Vilka effektmål/affärsmål har vi satt upp med nästa Release? Vilka verksamhetsproblem hoppas vi lösa? Kommer nästa Release nå dessa mål? Ser prognostiserad tidplan ut att hålla?

Med en Release Burndown kan man enkelt prognostisera när scoopet för releasen är klar. Release Burndownen är också ett enkelt verktyg för att anpassa release-scoopet för att nå önskat release datum. Finns tydliga mätbara effektmål kan Produktägaren också avgöra om tillräckligt många av dessa blir uppfyllda.

Release Burndownen ger en tidig indikation på hur projektet går. Produktägare och styrgrupp kan avgöra om release-scoopet ska justeras, deadline flyttas fram eller om teamet behöver förstärkas med ytterligare resurser.

.

ROI kontra Kostnad

Får vi valuta för pengarna? Är förväntad Return Of Investment (ROI) högre än sprintens kostnad? När ROI/Sprint sjunker under en viss gräns är det kanske dags att vara nöjd och avrunda projektet… eller se över Produktbackloggen, dvs. ta ett kreativt omtag och  klura ut nya funktioner som kan skapa högre affärsvärde än de som ligger i produktbackloggen just nu.

Att leverera enligt Scrum ger oss möjlighet att kontinuerligt försäkra oss om att teamet jobbar på just de saker som ger mest affärsvärde. Men det är inte bara en möjlighet utan även produktägarens skyldighet att se till att just så är fallet.

Utöver själva sprintens kostnad växer förvaltnings- och driftkostnader desto större och komplexare systemet blir. Denna aspekt återspeglas inte i illustrationen intill men bör finnas med som beslutsunderlag vid releaseplanering.

.

Rest/Släp

Hög rest-ratio (dvs. ration rest-tasks från föregående sprint/sprintar kontra ny funktionalitet) kan signalera många olika saker men framförallt en oförmåga att avsluta features och efter sprint demo ha en produkt som är ”klar”, dvs. redo för paketering och leverans. Ju fler features som är  ”work in progress” mellan sprintar desto mindre flexibilitet får produktägaren i sitt arbete med att prioritera produktbackloggen och desto mindre frihet över release-planeringen och större osäkerhet kring release-prognoser.

Vidare, om det alltid följer med rester från tidigare sprintar in i nästa sprint finns det en risk att man missa eventuella underliggande tekniska problem eller andra typer av hinder som gör att teamet har svårt att avsluta features. Inte nog med att produktägaren får allt mindre ”nytt” levererat per sprint, projektets sanna status blir allt svårare att utläsa.

.

Driftsättnings-/Packeteringsinsats

Hur stor är den faktiska insatsen att driftsätta (alt. paketera produkten) efter nästa Sprint Demo? Har projektet skjutit upp tasks rörande överlämning till förvaltning, dokumentation, acceptanstest, installationsscript, etc. betyder det inte att man är redo för leverans bara för att Release Burndownen närmar sig noll.

Så länge Scrum-projektet inte levererar en potentiellt installerbar/levererbar ny version av systemet/produkten varje sprint förlorar man den kontroll och flexibilitet som Scrum utlovar.

Skjuts vissa saker upp tills det ”är dags” måste detta förankras med produktägaren (och eventuellt styrgruppen) eftersom Release Burndownen inte längre berättar hela historien. (Alternativt lyfts dessa arbetsuppgifter in i produktbackloggen och görs till en del av releasen.)
.

Risk Burndown

Agila utvecklingsmetoder hanterar risk på daglig basis naturligt genom korta feedback-cykler, dagliga möten, öppen insyn i teamets progress, ärlighet, tät dialog osv. Trots detta kan det vara en god idé att synliggöra de risker som finns och hur de förändras och hanteras under projektets gång. När projektet närmar sig release ska självklart denna risk helst nått noll.

Läs mer om Risk Burndown Chart i ett tidigare inlägg.

.

Project Success Sliders

Project Success Sliders är ett enkelt men kraftfullt sätt för stakeholders och produktägaren att förmedla sina förväntningar till teamet. I projektets inledande fas defineras ett antal ”sliders” som var och en ger uttryck för hur projektets framgång kommer betygsättas och bedömas.

Hur bra (eller dåligt) stakeholders och produktägare upplever att projektet går i jämförelse med uppsatta ”kriterier” bör följas upp löpande så att projektet så ofta som möjligt får en chans till feedback och möjlighet att agera och reagera om så krävs.

.

Project Success Sliders beskrevs först av Rob Thomsett i sin bok ”Radical Project Managment”. Nyligen släppte Mountain Goat Software ett snyggt och enkelt webb-verktyg för att skapa och ställa in project sliders – ”Project Success Calculator”.

.

Detta är del 2 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)

h1

Om att mäta det agila projektets framgång (1/6)

fredag, 11 juni, 2010

På den gamla goda tiden gick det enkelt att ta reda på om det går bra eller dåligt för ett projekt. Hur många procent av kravlistan har vi bockat av? Hur stora (eller små) är avvikelserna från budget och deadlines? Samma frågeställningar fungerar inte tillfredställande i det agila projektet.

Vilka verktyg och mätvärden finns till hands när man jobbar agilt?

.

I ett agilt projekt finns det såklart oftast budget och deadlines men ingen detaljerad plan eller detaljerad kravlista att mäta avvikelser från. En av anledningarna till att man jobbar agilt är för att man insett att dessa måttstockar inte berättar något om hur bra produkt eller system man har byggt. Samt kommit till insikt om att planer bara är prognoser och inte något facit.

Detta betyder dock inte att vi ska sluta bry oss om hur bra eller dåligt ett Scrum-projekt går. En agil process som välkomnar förändringar och bygger på att skapar kunskap verkar dock slingra sig från att mätas. Vi måste ta till andra metoder och mätvärden än de vi kanske är vana med för att få en bra insyn i hur projektets sanna status är.

Först och främst borde vi förtydliga vad det är vi egentligen undrar när vi ställer oss frågan om ett projekt går bra? Kanske kan frågan styckas upp i följande, mer konkreta, frågeställningar:

  1. Är alla stakeholders nöjda? Tycker beställaren han/hon fått valuta för sina pengar?
  2. Upplever användaren att produkten/systemet är användbart och värdefullt?
  3. Håller produkten/systemet hög teknisk kvalitet och är fritt från buggar?
  4. Är systemet enkelt att förvalta/vidareutveckla?

.

Nedan listas förslag på mätvärden som kan användas för löpande utvärdering av ett projekts framgång och status och som beslutsunderlag under den löpande planeringen. I kommande artiklar (del 2-6) kommer jag beskriva var och en djupare och förklara vad dom syftar till och vad mätvärdet kan berätta om.

.

Agila mätvärden

.

Resultat
Projektets förmåga att göra stakeholders glada och leverera värdefull mjukvara enligt plan och prognoser…

  • Release Plan vs. Effektmål / ROI
  • Rest/Släp
  • Driftsättnings-/Packeteringsinsats
  • Risk Burndown
  • Project Success Factors

.

Produktivitet
Teamets förmåga att produktivt bygga och leverera funktioner…

  • Velocity – Trend
  • Velocity – Förutsägbarhet
  • Work In Progress
  • Focus Factor/DRAG
  • Time To Market

.

Kvalitet
Teamets förmåga att bygga kvalitativ mjukvara…

  • Buggar i produktion
  • Teknisk Skuld
  • Rest/Släp

.

Teamets nivå
Mår man bra och är motiverad gör man ett bättre jobb…

  • Agile/Scrum Mognadsgrad
  • Teamets välbefinnande

.

”You want the truth? You can’t handle the truth!”

Man får dock inte luras att tro att det finns egenvärde i något av ovanstående mätvärden! Eller än värre, ge sig i kast med att försöka sub-optimera med hänsyn till ett enskilt värde.

Alla former av suboptimeringar har en tendens att slå tillbaka och försök att belöna (eller bestraffa) team eller individer baserat på valfritt mätvärde riskerar sabotera projektet och kommer med tiden undergräva teamets effektivitet, moral och förmåga att bygga kvalitativ mjukvara.

Innan ni i ert projekt börjar föra statistik och historik fråga er varför ni mäter X, vilket problem hoppas ni kunna lösa och hur resultatet ska användas.

.

Detta är del 1 av 6. Läs vidare:

Om att mäta det agila projektets framgång (1/6) – Introduktion

Om att mäta det agila projektets framgång (2/6) – Resultat

Om att mäta det agila projektets framgång (3/6) – Produktivitet

Om att mäta det agila projektets framgång (4/6) – Kvalitet

Om att mäta det agila projektets framgång (5/6) – Teamets nivå

Om att mäta det agila projektets framgång (6/6) – Agera på kunskap

(Länkarna uppdateras allteftersom artiklarna publiseras.)

h1

Stress, trötthet, rädsla och klantighet

fredag, 4 juni, 2010

Test Driven Utveckling och par programmering är de kraftfullaste tekniker jag känner till för att höja kvaliten och minska antalet fel i koden.

Men hur kommer det sig att det smyger sig in galenskaper och fel i koden över huvud taget? Varför kan vi inte ”bara” koda rätt från början?

Som jag ser på det finns det två övergripande kategorier av fel-källor:

.

1) Intellektuella

Tolkning
I alla steg när man tvingas tolka eller minnas vad det var man skulle bygga finns alltid risken att man missförstår kravet, user storyn eller problembilder. Vissa detaljer kanske man glömmer bort, andra introducerar man i felaktig krav-extrapolering.

Tankevurpor
Man tror att ett problem går att lösa på ett visst sätt, kodar utan vare sig introducera buggar, minnes läckage eller andra svagheter. När man sedan börjar testa visar det sig att man tänkt galet och att skriven kod inte alls klarar av att lösa problemet eller beter sig inte som man föreställde sig när koden skrevs.

.

2) Mänskliga

Okunskap
När man anropar funktioner och integrerar mot moduler som andra har skrivit gör man det ofta utan att förstå den koden ordentligt, dess krav på input-parametrar, etc.

Stress
Press och stress kan ibland kortsiktigt höja fokus och prestation, men efter en stund vänds effekten och man börjar missa detaljer och introducera slarvfel, eller helt missa koda vitala delar i sin flykt undan piskan.

Tristess
Är du uttråkad och totalt oinspirerad är det till och med ansträngande att göra ett hyffsat jobb. Man lockas till genvägar och snabb-hack.

Trötthet
Jobbat för mycket övertid? Svårt att sova? Är man trött går allt lite långsammare och ibland känns det som om kablarna i huvudet inte riktigt når hela vägen fram…

Repetition
Som människa är man inte speciellt duktig på att upprepa något monotomt många gånger utan variation.

Avbrott
Avbrott gör att man tappar fokus och kanske tar upp arbetet lite vid sidan av där man slutade.

Rädsla
Är vi rädda för att få skäll, blotta vår okunskap eller förmedla dåliga nyheter har vi en tendens att prata mindre, skydda oss från dålig feedback och slutar ställa frågor. I värsta fall börjar vi trevande gissa sig fram på egen hand utan att egentligen veta om vi gör rätt eller fel.

Klantigheter
Copy’N Paste slarv. Syntaxfel. Tangent-glidningar.

.

Felsäker kod?

Finns det metoder och tekniker som fullständigt eliminerar ovanstående källor och orsaker? Antagligen inte. Men som jag skrev inledningsvis är TDD och par programmering de kraftfullaste teknikerna jag känner till.

Sedan har jag idéer, synpunkter och erfarenhet kring andra tekniska tekniker och mjuka  metoder för att förebygga och skydda sig mot fel. Dessa finns det dock inte utrymme att skriva om här idag, och jag känner dessutom att de förtjänar en egen artikel.

.

Äldre relaterade inlägg: