Værdi først og #NoEstimates – to sek > For nylig stødte jeg på to tilgange, der hævder at løse problemet "hvordan du altid lykkes med dine projekter ved at levere altid til tiden, på eller under-budgettet"Kai Gilbs værdi først og Vasco Duartes #NoEstimates.

Da jeg har studeret disse tilgange lidt dybere (jeg har en note på et værksted hos Vasco på NovaTec, og jeg deltog i et webinar med Kai, ud over at læse deres respektive bøger og andre relaterede ting) til fælles, men fokuser forskellige områder i projektarbejdet.

Del 1 af denne lille serie blogindlæg, Værdi først og #NoEstimates – to sider af en mønt? Del 1: Værdi først gav et kig på de vigtigste punkter i Kai Gilbs Værdi først. Del 2 forklarer Vasco Duarte’s #NoEstimates. Del 3 sammenligner begge tilgange.

Vasco Duarte: #NoEstimates

Vasco Duarte baserer #NoEstimates on Lean foundation: Estimater er i sagens natur affald. De tilføjer ikke værdi til kunden. 25% af de faktiske resultater 75% af tiden. Disse midler er ikke nøjagtige og har et meget lille tillidsniveau. Dette resulterer i den store variation, vi ser i smidige og traditionelle (vandfaldslignende) projekter. Vasco duarte sigter mod at reducere affald på en lignende måde som den magre produktionsbevægelse. Lean Production reducerede lagrene til netop i tidsproduktionen i fortiden. Så lad os eliminere anstrengelser for estimering og fokusere på aktiviteter, der indstiller reelle værdier.

Hvorfor er skøn så dårlige?

Hovedårsagerne til forskellene mellem teorier og virkelighed ifølge Vasco Duarte er:

Hofstadter’s Law: Det tager altid længere tid, end du forventer, også når du tager højde for Hofstadter’s Law. (Douglas Hofstadter – i Gödel, Escher, Bach: En evig gylden fletning, 20. års jubilæum, 1999, s. 152. ISBN 0-465-02656-7.)
Parkinsons lov: Arbejdet udvides for at udfylde den disponible tid til dets afslutning.
Accidental Complication (Ordev 2013): organisatoriske strukturer (og hvor lang tid tager det for at få godkendelsen af et nyt testmiljø?) Og de ændringer, der er foretaget. Den samlede komplikation af et problem som følge af denne utilsigtede komplikation h (a) og den iboende kompleksitet af problemet, der skal løses, kaldet essentiel komplikation g (e), kan udtrykkes ved en funktion f (g (e), h (a)). B(A) har normalt en meget højere indflydelse end g (e) når det kommer til softwareudvikling. Disse resulterer i det faktum, at enhedens funktionalitet ikke er prisen for en funktion. Men det er sådan, estimeringen er gjort i de fleste initiativer.
Inherent Kompleksitet i softwareprojekt er ikke forudsigelig, da det normalt er en læringsindsats. Det ligner noget som at starte "Ved at bygge et telt, så udvikle sig til en hat og derefter til en trailer og senere levere et slot" (Vasco Duarte). Jeg kan godt lide billedet af et slot – tænk på en middelalderlig borg, bygget gennem år. Det minder mig om nogle store systemer, jeg stødte på – ikke alle ældre systemer ….

Hvad estimerer vi for?

Så hvorfor bruger vi estimater? Vasco kommer med tre beslutninger eller aktiviteter, der skal understøttes af estimater:

Projektstørrelse og budgettering
Hvor mange mennesker består holdet af? Hvor lang tid tager det? Hvor meget skal jeg betale?
Prognoseprojektets fremskridt mod levering: omfang og tid i møde på en frigørelsesmilepæl
Vil vi levere til tiden? Hvad leverer vi ved en given milepæl for frigivelse?
Fjernelse af risiko for fiasko
Hvilke beredskabsplaner har vi brug for? Hvilke buffere (tid og budget) skal vi gøre til tiden (så et budget med størrelse og budgettering)?

Hvordan løser vi dette?

Det hele kommer ned på følgende problemer, der er bedre med bedre metoder end estimering:

hastighed & Afstand– uden skøn
Hvor hurtigt gør vi fremskridt? Hvornår er vi klar til at levere et bestemt omfang? #NoEstimates måler hastighed ved at tælle en sprint / iteration. Efterhånden som Vasco og andre empirisk finder ud af mere om, hvordan man gør dette. Afstanden til at gå er antallet af historier i din efterslæb. Brug af tidligere data fra de sidste 3 til 5 iterationer, behøver du ikke at estimere. Du kan observere og forudsige systemet "Udviklingsinitiativ" Systemteori og proceskvalitetsstyring har nogle værktøjer, der hjælper dig med observation og prognoser, f.eks. kontroldiagrammer og de ledsagende regler for kvalitetskontrol. Det er virkelig overraskende, hvor gode disse prognoser er.
Ved hjælp af denne hastighedsprognose kan du sandsynligvis levere milepæl. Brug af øvre og nedre grænser for kontrolkortet (ved hjælp af en sigma er bedst til udviklingsprocesser, som vasco oplevet) får du en række historier. Nu kan du starte en diskussion om de emner og historier, du skal inkludere.
Fjern risiko for svigt – uden at bruge hele tiden på planlægningen
Hvordan takler vi risikoen for fiasko? Vasco anbefaler en plan for at overleve og ikke at planlægge for fraværet af fiasko, ligesom det er gjort i mange projekter i det virkelige liv. At opbygge et robust system – det tekniske system, du udvikler såvel som udviklingsprocessen – for at overleve i tilfælde af en fiasko. Brug små cykler og tilbagekoblingssløjfer for at reducere risikoen for at fortabes i tilfælde af en fiasko. Nedbryd arbejdet for at fjerne risiko ikke størrelse! Vasco bruger en interessant beslutningsmatrix til historieforstyrrelse (se billede).
Lever på forretningsmæssige mål – uden at vente på projektets afslutning for at vide, om vi får det, vi har brug for
Hvordan ved du, at du fokuserer på de rigtige ting at levere? Hvordan ved vi tidligt, hvis vi er på banen? Vasco foreslår daglige mål baseret på forretningsmæssige mål, kun at arbejde på disse eksperimenter >

Vasco Duarte’s beslutningsmatrix

Hvordan man størrelsesgruppe team og hvordan man indstiller budget

Ved projektstørrelse foreslår Vasco analog estimering på et højt niveau for at indstille teamstørrelse ved projektstart. Brug derefter den sædvanlige PDCA-cyklus (planlægge, gøre, kontrollere, handle – Deming-cyklen). Da et budget er en investering i udvikling, bør du ikke basere det på omkostningerne >

# NoEstimate’s vigtigste takeaways

min vigtigste takeaways af Vascos værksted er:

Et projekt er et system, og som følger følger systemteori. Ydeevne er i høj grad defineret af systemet. Du kan ikke forudsige systemadfærd for et tilstrækkeligt komplekst system, f.eks. et udviklingsprojekt. Du kan kun eksperimentere og observere resultatet.
Størrelse af et projekthold ved hjælp af en analog estimering – eller start med et lille team. Brug derefter PDCA-cyklus til at foretage justeringer af projektgruppen efter behov.
Angiv budget ved en investeringsbeslutning baseret på den værdi, du vil opnå. Kontroller denne beslutning og resultatet indtil videre hvert par iterationer eller deromkring.
Fokus på den vigtigste ting at løse – prioritering er nøglen til succes, ikke estimering
Brug #NoEstimates prognose til prognose

Hvad synes du? Er Vascos tilgang anvendelig på dit sted? Fortæl os dine tanker.

Værdi først og #anestimerer – to sider af en mønt? Del 3: værdifokus

Værdi først og #NoEstimates – to sek > For nylig stødte jeg på to tilgange, der hævder at løse problemet Altid at lykkes med dine projekter ved at…
Værdi først og #anestimerer – to sider af en mønt? Del 1: værdi først

Værdi først og #NoEstimates – to sek > For nylig stødte jeg på to tilgange, der hævder at løse problemet Altid at lykkes med dine projekter ved at…
Filmene – film på Hamburgs engelske sider

Site: www.englishpages.de Mere i vores grupper og fora. Tilmeld dig nu og anmeld film. Fortæl os det, hvis du hører om film, der vises Biografer kan…
Panteberegner & amortiseringsplan for din økonomi

Panteberegner: Finansiel planlægning gjort let Du har spørgsmål? Hjælpeprogrammeregner: Sådan planlægges korrekt En enebolig med en stor have på landet,…