Planview-bloggen

Din väg till smidighet i affärsverksamheten

Hantering av produktutbud

Portföljförvaltning och agil programmering

Publicerad Av Robert L. Read
Portföljförvaltning och agil programmering

När Kent Beck först formulerade principerna för agil programmering, ledde han den största förändringen av programvarumetodiken under de senaste tjugo åren, och därmed kanske den största förändringen någonsin i en så ung konstart. Eftersom jag inte kan förbättra hans redogörelse för de synergetiska principerna i Extreme Programming, vill jag förklara hur agil programmering förhåller sig till portföljhantering och i synnerhet till det kritiska behovet av att ge chefer insyn i ett mjukvaruprojekts status. Här finns mer information om portföljhantering och agil programmering.

Som Pat Durbin och Terry Doerscher skriver i kapitel 2 i sin nya bok Taming Change with Portfolio Management under rubriken "The Elusive Nature of Knowledge Work":

Kunskapsarbete är svårt att planera, uppskatta och slutföra. Till skillnad från fysiskt arbete, t.ex. byggnation eller montering av komponenter, är kunskapsbaserad verksamhet ofta unik och saknar direkta historiska jämförelser för uppskattning. Kunskapsbaserat arbete saknar också tydliga indikatorer för framsteg.

Begreppet Velocity i Extreme Programming eller Agile Programming är ett försök att tillhandahålla en tydlig indikator på framstegen för programvaruprojekt.  Den besvarar en enkel men viktig fråga för en chef på ett programvaruföretag:

Hur nära är vi att vara klara?

Det gör det därför möjligt att besvara den mer intressanta frågan:

Vilken är den bästa kompromissen mellan vad vi vill ha (vår efterfrågan) och vad vi kan göra under en viss tidsperiod (vår kapacitet)?

Hastighet är den mängd arbete som ett team utför under en fast, men återkommande, tidsperiod, som kallas Sprint. På Planview använder vi två veckors sprintar. Programmeringsuppgifternas komplexitet, som kallas Stories, varierar dock kraftigt, så det går inte att räkna upp uppgifterna. Du mäter snarare komplexiteten hos en avslutad uppgift på ett abstrakt sätt. På Planview kallar vi detta mått för Story Points, men du kan också kalla dem "complexitrons" eller vad du vill. Varje uppgift måste konsekvent uppskattas i dessa Story Points.

Om du mäter antalet Story Points som ett visst team har slutfört under flera sprintar, har du det bästa måttet som hittills har utarbetats för att förutsäga hur mycket arbete som kommer att slutföras framgångsrikt under nästa sprint av det teamet. Om du har alla uppgifter beräknade i Story Points kan du med rimlig noggrannhet förutsäga när projektet kommer att vara klart. För en chef, portfölj- eller projektledare möjliggör denna öppenhet ett bra beslutsfattande.

Det finns dock några subtila nycklar till uppskattning, story points och hastighet som erfarenheten har lärt oss:

  • Hela teamet deltar i uppskattningen.
  • När en berättelse väl är bestämd får den aldrig ändras. Tiden kan visa att uppskattningen är felaktig, men att ändra uppskattningen är som att säga till en gäldenär att han är skyldig dubbelt så mycket som tidigare överenskommet utan anledning.
  • En berättelse kan delas upp i mindre berättelser, men berättelsepunkterna, som pengar, energi och dynamik, måste bevaras.
  • Snabba uppskattningar som bygger på en skicklig programmerares obeskrivliga tankar är ungefär lika bra som detaljerade uppskattningar.
  • Räkna med att hastigheten i en viss sprint varierar med ungefär 40 % i förhållande till genomsnittet för flera sprintar.
  • Att skriva en berättelse är en konst, men det är ingen svart konst. Ett team och deras produktchef bör kunna skriva 15 rimliga berättelser på en timme. Perfektion är inte bättre än "tillräckligt bra". Låt inte det perfekta bli det godas fiende.
  • När programmerare är oense om uppskattningar, lös tvisten genom konsensus och diskussion.
  • "Done" betyder "Releasable". En uppgift är inte klar förrän den kan släppas. Du kanske inte är villig att leverera en enda berättelse, men om den berättelsen inte håller den kvalitet som dina kunder kräver, räknas den inte.

Relaterade inlägg

Skrivet av Robert L. Read

Robert L. Read studerade vid Rice University och University of Texas, där han disputerade i datavetenskap. Rob har varit huvudingenjör på Hire.com och är nu chef för produktutveckling på Planview. Han är uppfinnare av två patent och författare till uppsatsen How to be a Programmer. Han har suttit i styrelsen för Esperanto USA och talar flytande esperanto. Han försöker mycket långsamt bygga en anordning som gör det möjligt för människor att simma i tunnform.