Planering. Planning. Hur planerar vi? Hur planerar vi? XP Bill of Rights. XP Bill of Rights

Transkript

1 Planning Extreme programming Planering In preparing for battle I have always found that plans are useless, but planning is indispensable - Eisenhower Vi planerar för att försäkra oss om att vi alltid gör det som är viktigast att vi kommunicerar effektivt med andra att vi kan reagera snabb på oförutsedda händelser (se de två ovanstående punkterna) Martin Karlsson marka@itn.liu.se K Martin Karlsson - XP 2 Hur planerar vi? För det första behöver vi ha koll på hur långt fram i tiden det är vettigt att planera Därav är det bra med tydliga milstolpar Att planera för detaljerat för långt fram innebär att det kommer bli dyrt om en förändring krävs Därav planerar vi noga i den närstående framtiden och översiktligt längre fram Planering påverkar många människor Därmed behöver vår kommunikation vara effektiv och enkel Hur planerar vi? Planer kan inte användas för att kontrollera händelser Man kan inte kontrollera händelser, man kan endast kontrollera reaktioner Planer måste vara ärliga, och inkludera all information som finns till dags dato Om planer går åt skogen så är det vanligt att planeraren försöker dölja detta Detta görs på grund av rädsla Vi känner oss säkra i ett samhälle med fungerande lagar och rättsystem Därför behöver vi det även för mjukvaruutveckling Martin Karlsson - XP Martin Karlsson - XP 4 XP Bill of Rights Kundens rättigheter Kunden har rätt att planera kostnader och alternativ över hela projektet Kunden har rätt att bestämma veckoliga utvecklingsprioriteter Kunden har rätt att se hur långt systemet har kommit i form av ett fungerande system i slutet på första veckan, och att se mer funktionalitet varje vecka Kunden har rätt till bra och dåliga uppdateringar av planeringen, så fort som informationen är tillgänglig Kunden har rätt att ändra sig utan att betala orimligt mycket mer XP Bill of Rights Programmerarens rättigheter Programmeraren har rätt att skatta arbetstid och få de uppskattningarna respekterade av alla deltagande Programmeraren har rätt att ärligt rapportera fortgång Programmeraren har rätt att producera högkvalitativt arbete hela tiden Programmeraren har rätt att veta vad som är viktigaste att jobba med härnäst. Programmeraren har rätt att ställa affärsmässiga frågor närhelst de dyker upp Martin Karlsson - XP Martin Karlsson - XP 6 1

2 XP Bill of Rights Chefens rättigheter Chefen har rätt till en total uppskattning av kostnader och resultat, medgett att verkligheten kommer att se annorlunda ut Chefen har rätt att flytta folk mellan projekt utan orimliga kostnader Chefen har rätt att se månatliga uppdateringar av utvecklingen, och hjälpa kunden med att prioritera Chefen har rätt att lägga ned projektet och ändå erhålla ett system som fungerar enligt investeringen fram till det datumet Det projekt som inte följer dessa rättigheter är inte ett Extreme Programming-projekt Martin Karlsson - XP 7 De fyra variablerna Kostnad Att lägga in mer pengar brukar innebära att hyra in mer folk i projektet Då kan man dock få kommunikationsproblem Och det blir en introduktionsfas för de nyanställda Lägga pengar på verktyg Ger också en försening, på grund av inlärningskurvor Men kan öka motivationen (en ny dator är alltid trevligt, särskilt om den är vit) Att lägga pengar på övertid Brukar göra utvecklarna omotiverade Martin Karlsson - XP 8 De fyra variablerna Kvalitet Intern kvalitet Hur bra är mjukvaruarkitekturen. hur väldesignade är testen, m.m. Tiden ökar omedelbums vid dålig intern kvalitet Extern kvalitet Upplevd kvalitet ur kundens synvinkel Omfattningen ökar vid dålig extern kvalitet Så försök skapa stories i omfattningen som tar hand om bra sådan här extern kvalitet (ex. användbarhetsmål och andra icke-funktionella krav) De fyra variablerna Tid och omfattning De två enklaste variablerna att justera Men resultaten av justeringarna är mycket svåra att se Så vi måste synliggöra dessa Då kostnad och kvalitet kommer att påverkas direkt av justeringar av tid och omfattning, fokusera planeringsspelet på de två senare variablerna Martin Karlsson - XP Martin Karlsson - XP 10 The Driving Metaphor Mjukvaruutveckling är en process Som kan gå bra Som kan gå dåligt För att få det att gå hyggligt, så behöver vi styra, kontinuerligt, hela tiden - "Driving is not about getting the car pointed in the right direction." I was ready to listen now. "Driving is about constant adjustment. A little this way, a little that way, forever. You always pay attention. You are always prepared to change things. Kent Beck citerar sin mor Målet Målet är att maximera värdet av systemet som produceras. Strategin Strategin är att investera så lite som möjligt för att sätta den viktigaste funktionaliteten i produktion så fort som möjligt. Verktyget Små lappar CRC cards / story cards. Spelarna Affärsfolket och utvecklingsteamet, samt användarna Martin Karlsson - XP Martin Karlsson - XP 12 2

3 Stories Kravet på en Story är att den är oberoende, testbar och att den tillför ett tydligt värde. Stories skall göras så pass små och lättbegripliga att ett flertal kan utvecklas och testas inom varje iteration. Stories Stories måste vara lätta att förstå för kunden Stories är bara en överenskommelse mellan kund och utvecklare att de ska diskutera en feature tillsammans Varje story måste ge värde för kunden Stories får inte vara större än att man kan bygga några stycken under en iteration Stories ska vara fristående ifrån varandra Varje story måste vara mätbar/testbar Martin Karlsson - XP Martin Karlsson - XP 14 Exempelstory (CRC-card) Ansvarsområden Affärsfolket bestämmer Tider Omfattning Prioritet Utvecklarna bestämmer Hur lång tid saker tar Tillsammans bestämmer man Hastigheten Antal Stories man kan uppfylla under en iteration Martin Karlsson - XP Martin Karlsson - XP 16 Estimeringar Yesterday s weather Ett visst lands meteorologiska institut köpte en spå-vädermaskin för en gazillion pengar. Den förutspådde väder med 70% korrekthet. De som betalade notan var imponerade. Sedan kom någon på att man får samma korrekthet om man förutsätter att morgondagens väder är samma som idag. Som bas för planeringen, förutsätt att du gör lika mycket denna veckan som du gjorde förra veckan Basera din estimering på liknande stories Keep it simple, silly! Om du säger ja till för mycket, för lång tid framöver, så kommer utvecklingen vara dolt i en dimma Estimeringar Det är vanligt att en story inte går att estimera Det ska vara enkelt för en användare att diagnosticera symptom Vi behöver fråga beställaren/användaren vad som menas för att göra ett korrekt estimat enkelt = enkelt att starta diagnosprocessen Användaren kanske ser typiska ikoner på skärmen att klicka på snabbt och enkelt? Utvecklare behöver inte jättedetaljerade stories, bara möjligheten att få en del stories förtydligade Använd spikes för att lättare estimera Martin Karlsson - XP Martin Karlsson - XP 18 3

4 Spelets gång Spelet har tre faser: Exploration, Commitment, Steering Exploration Skriv en story (Affärsfolk) Estimera den (Utvecklingsteamet) Dela upp den i delar om det behövs (Tillsammans) Commitment Sortera på affärsvärde (Affärsfolk) Sortering i tre högar. (1) De som gör att systemet fungerar. (2) De som inte är livsnödvändiga. (3) De som skulle vara trevliga att ha. Sortera på risk (Utveckling) Sortering i tre högar. (1) De som är lätta att estimera. (2) De som är lite svårare att estimera. (3) De som inte går att estimera. Sätt hastigheten (Tillsammans) Hur snabbt kan vi bygga systemet? Bestäm omfattning (Affärsfolk) Ett antal kort väljs ut för första releasen Martin Karlsson - XP Martin Karlsson - XP 20 Steering Iteration (1-3 veckor) Affärsfolket väljer en mängd värdefulla stories som fyller en iteration. De måste garantera att systemet kan köras end-toend. Recovery b Om Utvecklingsteamet inser att de har överskattat hastigheten, kan en omvärdering ske med Affärsfolket. New story Affärsfolket kan lägga till en ny story, men måste då plocka bort en som har lika stort estimat. Reestimate Om Utvecklingsteamet känner att tidsplanen inte håller, kan en omestimering ske tillsammans med Affärsfolket Martin Karlsson - XP 21 Shopping for Stories Hur skulle det se ut om planering av mjukvaruutveckling såg likadan ut som om man planerar för att handla matvaror? Stories = Matvaror Estimeringar = Priser Hastighet = Budget Vi kan se följande analogier Rabatter - Hallå mjukvaruhandlare, nu får ni två stories för en! Inflation - På grund av omständigheter utanför vår kontroll så är nu priset på snygg grafik det dubbla! Veckohandlande - Iterationsplanering Martin Karlsson - XP 22 Den första planen Den första planen har ingen historik att stödja sig på Två huvudproblem Storleken på varje story Teamets hastighet Mät hastigheten när ni skriver stories från början, låt story-skrivarna estimera hur lång tid de tror att det tar och använd den relationen i hastighetsplaneringen Iterationsplanering Iterationsplaneringen ägs av utvecklingsgruppen, dock i samförstånd med kunden naturligtvis Iterationsplaneringen synkas till programmeringsrytmen Någon vecka är tillräckligt för att Utveckla lite ny funktionalitet Göra en rejäl refaktorisering Prova lite nya och avancerade saker (spikes) Återhämta projektet från smärre misslyckanden Martin Karlsson - XP Martin Karlsson - XP 24 4

5 Iterationsplanering Vanliga programmeringsuppgifter tar ungefär tre ideala dagar Uppgifterna består av nedbrutna stories Görs eftersom det är enklare att mäta uppgifter än hela stories En person håller reda på hur mycket som har gjorts, hur mycket som är kvar och eventuella problem som kan uppstå (Spåraren) Det viktigaste inom planering för extreme programming är att deadlines är hårda, och att det är omfattningen man ändrar på Iterationsplanering Hitta billigaste resan Olika resesätt - MK 2 Olika datum - MK 3 Specialerbjudanden - SG 3 Alternativa resvägar - SG 3 Boka hotell Interface för hotellbokning - SG 2 Adapter för Best Western - NR 2 Adapter för Holiday Inn - NR Martin Karlsson - XP Martin Karlsson - XP 26 Tracking Trackern / Spåraren frågar programmerarna hur de ligger till ungefär två gånger i veckan Trackern besöker varje programmerare enskilt, inga gruppmöten, inga rapporter! Två frågor ställs Hur många ideala dagar har du arbetat på det här? Hur många fler ideala dagar behöver du tills du är klar? Be aldrig om ett procentuellt svar. Det ger ingenting. Jämför med antal kalenderdagar kvar och se om iterationen behöver planeras om Tracking En en-veckas iteration slutar när en vecka har gått Stories som är klara, är klara Stories som inte är klara, planeras om på nästa iterationsplaneringsmöte En story är klar när dess funktionalitet har visats för kunden och kunden har gett tumme upp till att funktionaliteten fyller det som efterfrågades Martin Karlsson - XP Martin Karlsson - XP 28 Tracking Uppgift Vem Klart Kvar Olika resesätt MK 2 0 Olika datum MK 2 0 Specialerbjudanden SG 2 1 Alternativa resvägar SG 3 0 Interface för hotellbokning SG 1 1 Adapter för Best Western NR 2 0 Adapter för Holiday Inn NR Totalt för teamet Synlighet Använd inte föregående tracking som bevis på att ni mäter och visa upp hur det går för enskilda medlemmar Visa grafer tydligt på väggen i utvecklingsrummet eller liknande Visa exempelvis följande grafer Sammanlagt fullföljda stories per dag Antal integrationer per vecka Antal större test per vecka Antal buggar (den här är trevlig att se!) Antal optimala parprogrammeringstimmar Martin Karlsson - XP Martin Karlsson - XP 30 5

6 Synlighet Aktiviteter Martin Karlsson - XP Martin Karlsson - XP 32 Aktiviteter Martin Karlsson - XP 33 6