Arvo ensin ja #NoEstimates – kaksi s > Äskettäin tapasin kaksi lähestymistapaa, jotka väittävät ratkaisevan ongelman "kuinka menestyä projektiisi aina toimittamalla aina oikeaan aikaan, budjetilla tai alirakennuksella"Kai Gilb’s Value First ja Vasco Duarte #NoEstimates.

Kun olen tutkinut näitä lähestymistapoja hieman syvemmälle (Minulla on muistiinpano Vasco’sin NovaTec-työpajassa ja osallistuin web-seminaariin Kaiin kanssa heidän kirjaa ja muuta asiaan liittyvää lukemisen lisäksi) yhteinen, mutta keskity projektityön eri osa-alueisiin.

Osa 1 tästä pienestä blogisarjoista, Arvo ensin ja #NoEstimates – kolikon kaksi puolta? Osa 1: Arvo ensin tarjosi katsauksen Kai Gilbin avainkysymyksiin Arvo ensin. Osa 2 selittää Vasco Duarten #NoEstimates. Osa 3 vertaa molempia lähestymistapoja.

Vasco Duarte: #NoEstimates

Vasco Duarte perustaa #NoEstimates Lean-säätiöille: Arviot ovat luonnostaan tuhlaa. Ne eivät tuo lisäarvoa asiakkaalle. 25% todellisista tuloksista 75% ajasta. Nämä keinot eivät ole tarkkoja, ja niiden luottamustaso on hyvin pieni. Tämä johtaa suureen variaatioon, jonka näemme ketterissä ja perinteisissä (vesiputousmaisissa) projekteissa. Vasco duarten tavoitteena on vähentää jätteitä samalla tavalla kuin vähärasvaisen tuotantoliikkeen kanssa. Lean Production laski varastoja vain aikataulun mukaiseen tuotantoon menneisyydessä. Joten poistetaan arviointiponnistukset ja keskitytään todellisen arvon määrittämiseen.

Miksi arviot ovat niin huonoja??

Tärkeimmät syyt teorioiden ja todellisuuden välisiin eroihin Vasco Duarten mukaan ovat:

Hofstadterin laki: Se vie aina kauemmin kuin odotat, jopa kun otat huomioon Hofstadterin lain. (Douglas Hofstadter – julkaisussa Gödel, Escher, Bach: ikuinen kultainen punos, 20. vuosipäivä, toim., 1999, s. 152. ISBN 0-465-02656-7.)
Parkinsonin laki: Työ laajenee niin, että sen suorittamiseen käytettävissä oleva aika täyttyy.
Vahingossa tapahtunut komplikaatio (Ordev 2013): organisaatiorakenteet (ja kuinka kauan kestää uuden testausympäristön hyväksynnän saaminen?) Ja siihen tehdyt muutokset. Tästä vahingossa ilmenevän ongelman yleinen komplikaatio h (a) ja ratkaistavan ongelman luontaista monimutkaisuutta, jota kutsutaan välttämättömäksi komplikaatioksi g (e) voidaan ilmaista toiminto f (g (e), h (a)). B(A) on yleensä paljon suurempi vaikutusvalta kuin g (e) kun kyse on ohjelmistokehityksestä. Tämä johtaa siihen, että laitteen toiminnallisuus ei ole ominaisuuden kustannus. Mutta tällä tavalla arvio tehdään useimmissa aloitteissa.
Ohjelmistoprojektin luontainen monimutkaisuus ei ole ennustettavissa, koska se on yleensä oppimistavoite. Se muistuttaa jotain aloittamista "Rakentamalla teltta, sitten muuttuu hattuksi, sitten perävaunuksi ja myöhemmin luovuttaa linna" (Vasco Duarte). Pidän linnan kuvasta – ajattele keskiaikaista linnaa, joka on rakennettu vuosien varrella. Se muistuttaa minua isoista järjestelmistä, jotka tapasin – ei kaikkia vanhoja järjestelmiä ….

Mihin arvioimme??

Joten miksi käytämme arvioita? Vasco esittelee kolme päätöstä tai toimintaa, joita on tarkoitus tukea arvioilla:

Hankkeen koko ja budjetointi
Kuinka monta ihmistä joukkue koostuu? Kuinka kauan se vie? Kuinka paljon minun on maksettava?
Ennustetaan projektin etenemistä kohti toimitusta: laajuus ja aika vapauttamisen välitavoitteen saavuttamisessa
Aiommeko toimittaa ajoissa? Mitä me toimitamme annetussa julkaisuvaiheessa?
Epäonnistumisriskin poistaminen
Mitä valmiussuunnitelmia tarvitsemme? Mitä puskureita (aika ja budjetti) meidän on tehtävä ajoissa (niin suuruuden ja budjetoinnin budjetti)?

Kuinka voimme ratkaista tämän?

Tämä kaikki johtuu seuraavista ongelmista, jotka ovat parempia paremmilla menetelmillä kuin estimointi:

nopeus & etäisyys– ilman arvioita
Kuinka nopeasti etenemme? Milloin olemme valmiita toimittamaan tietyn laajuuden? #NoEstimates mittaa nopeutta laskemalla sprintti / iteraatio. Kuten Vasco ja muut oppivat empiirisesti lisää miten tämä tehdään. Etäisyys etäisyyteen on kertomusten lukumäärä. Käyttämällä aikaisempia tietoja viimeisistä 3 – 5 iteraatiosta, sinun ei tarvitse arvioida. Voit tarkkailla ja ennustaa järjestelmää "Kehitysaloite" Järjestelmäteoriassa ja prosessien laadunhallinnassa on joitain työkaluja, jotka auttavat sinua havainnoinnissa ja ennustamisessa, esim. valvontakartat ja niihin liittyvät laadunvalvontasäännöt. On todella yllättävää, kuinka hyvät nämä ennusteet ovat.
Tämän nopeusennusteen avulla voit todennäköisesti saavuttaa virstanpylvään. Ohjauskartan ylä- ja alarajoja käyttämällä (yhden sigman käyttö on parasta kehitysprosesseissa vasco-kokemuksena) saat erilaisia tarinoita. Nyt voit aloittaa keskustelun aiheista ja tarinoista, jotka sinun tulisi sisällyttää.
Poista epäonnistumisriski – viettämättä koko ajan suunnittelua
Kuinka torjua epäonnistumisen riski? Vasco suosittelee suunnitelmaa selviytyäkseen eikä suunnittelematta epäonnistumista, kuten monissa tosielämän hankkeissa tehdään. Rakentaa vankka järjestelmä – sekä kehittämäsi tekninen järjestelmä että kehitysprosessi – selviytymään vikaantumisen varalta. Käytä pieniä jaksoja ja takaisinkytkentäsilmukoita vähentääksesi hukkaantumisriskiä vian sattuessa. Hajauta työ poistamalla riski eikä koko! Vasco käyttää mielenkiintoista päätösmatriisia tarinan murtamiseen (katso kuva).
Suorita liiketoiminnan tavoitteet – odottamatta projektin loppua tietääksesi, saammeko tarvitsemme
Kuinka tiedät keskittymisen oikeisiin toimituksiin? Mistä tiedämme aikaisin, jos olemme oikealla tiellä? Vasco ehdottaa päivittäistavoitetta liiketoimintatavoitteiden pohjalta työskentelemään vain näiden kokeiden parissa >

Vasco Duarten päätösmatriisi

Kuinka koota joukkue ja miten asettaa budjetti

Projektin mitoituksessa Vasco ehdottaa korkean tason analogista arviointia joukkueen koon asettamiseksi projektin alkaessa. Käytä sitten tavallista PDCA-sykliä (suunnittele, tee, tarkista, toimi – Deming-sykli). Koska budjetti on sijoitus kehitykseen, sinun ei pitäisi perustaa sitä kustannuksiin >

# NoEstimaten tärkeimmät ruudut

minun tärkeimmät noutot Vascon työpajasta ovat:

Projekti on järjestelmä ja seuraa seuraavasti systeemiteoriaa. Suorituskyky määritellään järjestelmässä suurelta osin. Et voi ennustaa riittävän monimutkaisen järjestelmän, kuten esimerkiksi kehityshanke. Voit vain kokeilla ja seurata tulosta.
Koko projektiryhmä käyttämällä analogista arviointia – tai aloita pienellä joukkueella. Käytä sitten PDCA-sykliä säätääksesi projektitiimiä tarvittaessa.
Aseta budjetti sijoituspäätöksellä saavutettavan arvon perusteella. Tarkista tämä päätös ja tulos toistaiseksi muutaman iteraation välein.
Keskity tärkeimpiin ratkaistaviin asioihin – priorisointi on avain menestykseen, ei arviointi
Käytä ennustamiseen #NoEstimates-ennustetta

Mitä luulet? Sovelletaanko Vascon lähestymistapaa omassa paikassa? Kerro meille ajatuksesi.

Arvo ensin ja #noestimaatit – kolikon kaksi puolta? Osa 1: arvo ensin

Arvo ensin ja #NoEstimates – kaksi s > Äskettäin tapasin kaksi lähestymistapaa, jotka väittävät ratkaisevan ongelman Menesty projektiisi aina…
Arvo ensin ja #noestimaatit – kolikon kaksi puolta? Osa 3: arvon keskittyminen

Arvo ensin ja #NoEstimates – kaksi s > Äskettäin tapasin kaksi lähestymistapaa, jotka väittävät ratkaisevan ongelman Menesty projektiisi aina…
Uutiset – abu dhabi-matkavinkit, rehellinen – yksityiskohtainen matkaopas

Abu Dhabin matkavinkit | Sinun rehellinen yksityiskohtainen matkaopas Vinkkejä lomailijoista lomailijoille, jotka etsivät Abu Dhabia? Matkablogissani…
Opera ei toimi kuten dsds “, kulttuuri

Site: www.merkur.de Jotta voimme antaa sinulle paremman käyttökokemuksen, käytämme evästeitä. Käyttämällä palveluitamme hyväksyt evästeiden käytön….