Progressiv planering - hur du undviker schweizerost-estimat 🧀

Förutsägbara resultat kommer inte från rigorös analys och precisa estimat. Planering och estimering i komplexa domäner kräver progressiv planering, eller så slutar det med planer fulla av hål - som schweizerost.

I den förra artikeln beskrev jag skillnaden mellan precision och korrekthet, och varför korrekthet alltid är viktigare. Att ta hänsyn till detta och agera därefter - att kontinuerligt förbättra precision utan att göra avkall på korrekthet - är vad jag kallar progressiv planering.

Att planera progressivt betyder att man måste ta till sig nya sätt att tänka kring planering och estimering, men låt inte det hindra dig. Dom potentiella vinsterna är enorma.

I den här guiden får du lära dig:

• Hur för precisa estimat för tidigt leder till schweizerost-estimat.

• Hur du förbättrar precisionen över tid.

• Vad man ska göra och vad man inte ska göra när man planerar progressivt.

• Hur en progressiv plan ser ut i olika faser av ett projekt.

• Hur man kan hantera scenarion med låst innehåll och låst pris.

Låt oss först titta på vad schweizerost-estimat leder till.

Varför schweizerost-estimat har betydelse

Att försöka få ut för precist data från organisationen, oavsett hur viktigt det verkar vara eller vem som ber om det ("kunderna kräver det") leder oundvikligen till schweizerost-planer. Misstro, missade deadlines och dålig kvalitet följer som ett brev på posten. Det behövs en organisationen med ryggrad, och disciplin från stakeholders, för att inte gå i den här fällan.

Vad orsakar schweizerost-estimat?

Planering behövs. Man bör definitivt planera i förväg. Problemen börjar i samma stund som man tror att tillräckligt noggrann planering i början är tillräckligt, och ger hög precision-hög korrekthet estimat - och att skälet till att det inte lyckades förra gången säkerligen är att man inte var tillräckligt rigorös, eller att teamen saknar någon analys- eller estimeringskunskap.

När man gör en detaljplan i förväg försöker man bryta ner och identifiera allt arbete. Cirklarna nedan illustrerar identifierat scope och relaterade estimat (möjligen story points). Teamet har försökt identifiera allt "jobb" dom behöver göra.

Den här typen av djuplodande detaljplanering leder oundvikligen till missat scope (det gula området nedan). Det här är en inneboende egenskap i mjukvaruutvecklings komplexa natur, som inte går att analysera eller planera bort.

Så hur undviker man schweizerost? Det är bättre att i början nöja sig med grövre högnivå-estimat (den stora cirkeln till höger). Med andra ord: vid varje given tidpunkt måste precision och storlek på det man estimerar matcha osäkerheten.

Så hur förbättrar man precisionen och åstadkommer bättre prognoser? Progressiv planering till räddningen! (Lägg till din favoritsuperhjälte här.)

Progressiv planering

Progressiv planering innebär att hela tiden medvetet förbättra estimat och prognoser under ett projekts livstid.

Det finns tre regler att följa:

1. Tappa inte korrekthet ur sikte

2. Beakta hela tiden allt scope

3. Använd empiriskt data för att förbättra prognoser

Dom här reglerna har implikationer på planering - både när det gäller vad man ska göra och vad man inte ska göra.

Tappa inte korrekthet ur sikte

Att inte släppa fokus på korrekthet innebär att man måste göra avkall på precision initialt. Se också till att kommunicera precisionsnivån på rätt sätt.

​Gör 👍🏼	Låt bli 🤚🏼
Använd enheter och storlekar som matchar precisionen (t.ex. veckor).	Dela estimat i enheter som ger en falsk känsla av precision (t.ex. timmar).
Utnyttja intervall.	Kommunicera enpunkts-estimat.
Estimera med rätt storlek på objekt.	Försök bryta ner och estimera allting i detalj från början.

Beakta hela tiden allt scope

För att kunna hålla allt scope i huvudet måste man fundera på storleken på saker. Siktar man på för mycket detaljer för tidigt så kommer man - medvetet eller ofrivilligt - ignorera delar av innehållet.

Att fokusera på en delmängd och lägga resten i en blandad hög med "framtida arbete" skapar en stor hink med låg precision-låg korrekthet estimat. Försöker man å andra sidan inkludera allt men på en för hög detaljnivå så missar man saker, och får ett mentalt sammanbrott när man försöker hålla koll på alltför många saker samtidigt.

Gör 👍🏼	Låt bli 🤚🏼
Dela hela tiden saker så att varje ny del representerar något värde eller funktionalitet.	Skapa generella hinkar i backlogen (till exempel "återstående job" eller "framtida arbete").
Dela upp hela projektet i områden/teman.	Strunta i att estimera eller fånga upp delar av scope.
Dela kontinuerligt upp arbetet i mindre och mindre delar som representerar verkligt arbete.	Dela upp arbetet i "del 1", "del 2" osv.

Använd empiriskt data för att förbättra prognoser

Att använda empiriskt data för att förbättra prognoser över tid förbättrar precisionen, så att få fram empiriskt data måste vara en prioritet. Det betyder börja jobba - helst med teamen som kommer implementera hela projektet - så snart som möjligt.

Om teamen har historik av liknande jobb, så borde man vara i en fördelaktig position att ta fram bra estimat fort. Det blir svårare och svårare ju mer arbetet och/eller teamuppsättningen ändras.

När man ändrar på team - exempelvis lägga till eller ta bort medlemmar - skapar man en ny kontext och ogiltigförklarar eventuellt empiriskt data man hade. Det här är ett skäl till att stabila team diskuteras inom mjukvaruutveckling. Det betyder inte att man aldrig ska ändra på teamen, men gör det avsiktligt och fundera på hur det påverkar prognoser och effektivitet.

Att om-estimera arbete när man uppdaterar prognoser skulle vara omständligt och bortkastad tid. Relativa estimat gör det möjligt att förfina prognoser utan att estimera om. Man behöver bara omberäkna hastigheten vilken härleds från estimaten - den estimeras inte direkt.

Jämför med etapperna på en resa. Det går att estimera storleken på etapperna relativt varandra utan att veta hur snabbt du åker - kanske har du inte ens bestämt fordon - men när du börjar åka kan du beräkna hastigheten och göra en prognos hur lång tid resan kommer ta. Etappernas relativa storleken ändras inte.

Empiriskt data och relativa estimat antyder också att arbeta inkrementellt och iterativt, och att leverera fungerande mjukvara kontinuerligt. Det är dessa inkrement som låter dig beräkna hastighet.

​Gör 👍🏼	Låt bli 🤚🏼
Börja arbeta så snart som möjligt.	Spendera mycket tid på förplanering med lite värde.
Kommunicera uppdateringar allt eftersom prognosen ändras.	Låtsas om att den initiala planeringen håller.
Håll teamen stabila, och nyttja befintliga team om möjligt.	Omorganisera och ändra teamuppsättning slumpmässigt.
Estimera relativt - härled kalendertid.	Estimera direkt i kalendertid.

Ett exempel

Så hur ser progressiv planering ut under olika delar av ett projekt?

Uppstart

I början måste man offra precision till fördel för korrekthet. För att kunna ta allt scope i beaktande så bryts arbetet ner till stora områden (kanske "teman" eller "epics") och estimeras relativt varandra.

Om man bygger ett ärendehanteringssystem så skulle områden kunna vara:

• Ärendehantering

• Dashboards

• Rapporter

• Import och export av data

• Sökning och filtrering

• Projektadministration

I bilden nedan representerar varje cirkel ett område tillsammans med dess initiala högnivå estimat (möjligen "epic points").

Identifiera ett eller två områden där det är lämpligt att börja. Till exempel baserat på risk, genomförbarhet eller prioritet. De valda områdena bryts ner till mindre delar, där varje ny del representerar faktiskt arbete.

Ärendehantering skulle kunna brytas ner till:

• Visa ärende

• Skapa ärende

• Uppdatera ärende

Så småningom är arbetet uppdelat så att det kan implementeras av team. Illustrerat nedan av mörkare gröna cirklar. "Visa ärende" skulle exempelvis kunna delas upp i:

• Lista ärenden

• Visa ett ärende

• Skriv ut ärende

Mellanspel

Allt eftersom arbetet fortskrider blir saker färdiga, illustrerat med gråa cirklar nedan. När områden börjar bli klara bryts nya områden ner och förbereds för att implementeras.

Så här fortsätter det genom projektets livstid. Alla färdiga delar genererar empiriskt data som kan användas för att uppdatera hastigheten och förbättra prognoser.

Slutspel

I slutet är antagligen det mesta klart. Eftersom saker har utvecklats iterativt och inkrementellt är det lätt att fatta affärsbeslut om att avsluta projektet och strunta i saker som inte längre behövs. Nya krav kan även ha upptäckts längs vägen. I bilden nedan representerar de två blå cirklarna arbete som inte slutfördes. Notera att de aldrig bröts ner i detalj eller påbörjades.

Fast scope - fastpris

Kunder föredrar ofta fastpris-kontrakt. Det ger illusionen av trygghet ("Jag vet exakt vad jag får och när") men sanningen är att det oftast är sämre för kunden och leder till:

• Dålig kvalitet

• Höga kostnader

• Skillnad mellan målbild och faktiskt leverans

En utmaning med fastpris-kontrakt är att leverantören vanligtvis ombeds göra ett väldigt precist estimat från början. Leverantörer hanterar detta på två sätt:

• En buffert läggs till på estimaten

• En Change Control Board (CCB) inrättas för att hantera och förhandla ändringar

Dessa nödvändigheter förhindrar dock inte progressiv planering.

Det är oavsett fördelaktigt att jobba inkrementellt och iterativt. Att inte ha allting pågående samtidigt underlättar affärsbeslut. När kunden ber om ändringar (även om det är via byråkratiska förändringsprocesser) så hjälper det om inte allting rör på sig, och att veta vad som är färdigt - och vilket arbete som inte har påbörjats ännu (vilket gör det enklare att byta ut).

Det minskande värdet från rigorös förplanering betyder att man vill hålla den lättviktig och i stället fokusera på att påbörja arbetet.

Använd olika tekniker parallellt för att få bättre prognoser från start. Till exempel:

• Estimera stora områden relativt varandra, till exempel med "epic points".

• Gör prototyper och genomlysningar för att verifiera genomförbarhet.

• Titta på t.ex. antalet UI-vyer eller API:er - estimera kostnaden för en och multiplicera.

• Utnyttja eventuellt empiriskt data som finns.

• Gör en konfidens-omröstning med teamen.

Se också till att separera estimat och affärsbeslut. Som affärsägare vill du kanske ta en kalkylerad risk, men påverka inte organisationen att ta fram fantasiplaner och lägre estimat. Det är ok att ställa frågor som "Vad händer om vi tar bort det här?" osv, men ifrågasätt inte estimaten.

Avslutningsvis

Progressiv planering och att starta arbetet tidigt har fördelar jämfört med rigorös förplanering:

• Man får ett försprång på implementationen.

• Man får empiriskt data snabbare vilket möjliggör mer pålitliga prognoser tidigare.

• Teamen involveras tidigt och kommer upp i fart snabbare.

Into desto mindre verkar det vara förvånansvärt svårt att göra det här i praktiken. Tryck från stakeholders, ett fixerat tankesätt kring hur man planerar, och organisatoriska begränsningar kommer i vägen. Ingen hjälps av orealistiska planer dock: inte utvecklingsteam, inte affärsägare, och definitivt inte kunder.

Hur planerar ni? Vad hindrar er från att planera progressivt?