osana ohjelmistojen estimointisarjaamme selvitimme odotusten hallinnan merkitystä osana mitä tahansa ohjelmistoprojektia. Tässä artikkelissa keskitytään epävarmuuden kartio, tehokas väline riskien lieventämiseksi scoping ja estimointi prosessi. Sen ytimessä on kuvaus epävarmuudesta projektin loppuun saattamiseen tarvittavasta ajasta, joka perustuu tiedon määrään (tai sen puutteeseen) projektin alussa. Se lopulta selittää riskin hankkeen puhaltaa ulos, koska tuntemattomia, ja se, että pidemmälle tulevaisuuteen yrität arvioida, sitä todennäköisemmin olet väärässä. Se on mielenkiintoinen paradoksi, jossa haluamme ennustaa tulevaisuutta tarkasti, mutta emme voi todella olla tarkkoja, koska se on vain arvio.

Jos et ole jo tehnyt, suosittelen, että tutustut aiempaan kokeeseen, jonka teimme täällä Koodeboteissa selvittääksemme, miten voisimme parhaiten hallita riskejä ohjelmistoissa. Motivaationa tähän harjoitukseen oli ohjelmistotiimiemme toistuva ylioptimismi, kun oli kyse arviointien suorittamisesta.

kun olimme varustautuneet parhaaseen menettelyyn kokeen ehdottamiseksi, havaitsimme ongelman kiinteissä laajuusarvioissamme. Jokainen tarjous sisälsi vähintään 80% vaihtelua tehdystä työstä riippumatta projektin kestosta. Koska emme soveltaneet epävarmuuden kartiota, kykymme tarjota asiakkaillemme realistisia arvioita ja hallita heidän odotuksiaan vaikeutui merkittävästi.

Vaihe 1: Ymmärrä ongelma

kuten edellä mainittiin, kohtasimme estimoinneissamme ongelman, joka ilmenee, kun tarjoamme kiinteän kattavuuden hinnan lainausvaiheessa. (Kiinteä soveltamisala eli täsmällisten vaatimusten toimittaminen, mutta joustavasti). Riippumatta projektin pituudesta, menimme aina yli, koska meillä on paljon vaihtelua.

perussyy – meillä ei ollut epävarmuuden kartiota. Emme ottaneet huomioon sitä tosiasiaa, että mitä pidemmälle tulevaisuuteen yrität ennustaa, sitä suurempi on aikavarianssin kasvu. Tämä johtuu useista erityisriskeistä, joista vakavimpia ovat epätarkat arviot, soveltamisalan vaihtelut ja loppukäyttäjien sitoutuminen. Koska kaikki oli arvioitu alussa, estimaattia ei ollut mahdollista muuttaa näiden havaittujen riskien huomioon ottamiseksi. Sen sijaan näiden riskien vaikutus korostuu projektin elinaikana, eli mitä pidempi projekti, sitä enemmän yrität ennustaa, joten sitä todennäköisemmin olet väärässä.

Vaihe 2: Kehittää hypoteesi

kun sulanut ongelma, me seuraavaksi työskennellyt kehittää hypoteesi testata, miten kartio epävarmuutta voitaisiin tarkasti soveltaa meidän kiinteän soveltamisalan estimoinnit.

tästä arveltiin, että kaavalla voitaisiin laskea epävarmuuden kartion koko, kun otetaan huomioon projektin pituus.

Vaihe 3: Suunnittele koe

hypoteesillamme varustettuna etenimme suunnittelemaan koetta testaamaan epävarmuuden kartion propositiotamme. Voit tehdä tämän, loimme quadratic funktio simuloida meidän kartio, jossa parametri edustaa useita ennustettuja viikkoja kehityksen. Voisimme sitten soveltaa tätä kerrointa arvioihimme huomioidaksemme aikavaihtelun, joka perustuu siihen, kuinka pitkälle tulevaisuuteen yritimme ennustaa.

Jos sovellamme tätä aiempien projektien estimointitietoihin, voisimme sitten määrittää, olisiko kiinteä scope-hinta vaihteluineen ollut tarkempi.

Vaihe 4: Kerää tiedot

keräsimme tietoa eri projekteista, mukaan lukien tiedot varatusta ja otetusta ajasta, toteutetuista tarinoista, valmistumisajasta, mukaan lukien lisätiedot projektista ja kohdatuista riskeistä.

arvioinneista laskimme kullekin projektille hypoteettisen kiinteän soveltamisalan arvon käyttäen epävarmuuden kartiota. Näiden tietojen avulla pystyimme tutkimaan, oliko aika, jonka todella otimme kehittääksemme, viimeistelemällä sekä alkuperäisen työn että lisämuunnokset, verrattavissa uusiin estimointiarvoihin, jotka saatiin käyttämällä epävarmuuden kartiota. Kävi ilmi, että parannettu arvio ja todellisuudessa käytetty aika olivat hyvin samanlaisia!

Vaihe 5: Tee päätös

lopulta aineisto osoitti, että jos sovellamme epävarmuuden kartiota määrättyyn laajuuteen käyttäen kaavaa, joka ottaa huomioon projektin pituuden, päädymme estimointiin, jossa otetaan huomioon varianssi, joka tapahtuu projektin kehityksen aikana.

loppujen lopuksi suosittelemme, että sen sijaan, että kehitystiimi yrittäisi arvioida koko projektia, se keskittyy ja arvioi vain pienen työmäärän. Tämä auttaa vähentämään vaikutusta tuntemattomia, ja siten koko kartion epävarmuutta. Tämä tarkoittaa myös sitä, että kun tiimi työskentelee projektissa, he oppivat lisää siitä, ja kun se tulee arvioida seuraavan kimpale työtä, he voivat vähentää epävarmuutta ja tehdä tarkempia arvioita.