Johdanto

Yksi ohjelmistokehityksen vaikeimmista asioista on uuden ohjelmistoprojektin toimittamiseen kuluva aika ja vaivannäkö. Pitäisikö sen olla niin vaikeaa? Vastaus ei ole niin yksinkertainen.

Ohjelmistokustannusten arviointi on pohjimmiltaan vaikeaa, ja ihmiset ennustavat melko huonosti absoluuttisia tuloksia. Ei ole kahta samanlaista hanketta; kukin niistä on ainutlaatuinen sen suhteen, mitä se aikoo saavuttaa, ja sen olemassaolon muodostavien parametrien lukumäärän suhteen. Usein se, mikä näyttää olevan yksinkertainen ongelma pinnalla, on paljon vaikeampaa tai teknisesti ongelmallisempaa, kun se toteutetaan todellisuudessa. Ja epäilemättä projektissa on 'muukalaisia', jotka tunnistetaan vasta, kun he tulevat esiin.

Lisäksi kaksi ihmistä eivät ole samanlaisia, olitpa asiakas, kehittäjä tai käyttäjä. Tulemme ohjelmoitu omalla tietämyksellämme, kokemuksillamme, arvoillamme, odotuksillamme, suhtautumisellamme riskeihin ja kyvyllä sopeutua.

Laadukkaiden ohjelmistojen kirjoittaminen on leipää ja voita vanhemmille insinööreille; Ylimääräisten ohjelmistotuotteiden luominen voi olla vieläkin vaikeampi tehtävä kaikille asianosaisille.

Vaikuttava ohjelmistotoimitus on myös tasapainottava teko.

Ohjelmistojen osalta avain on ymmärtää strategisten liiketoimintapäätösten kesto ja kustannukset, ja tämä on totta riippumatta siitä, perustatko uuden yrityksen, toteutatko uuden liiketoimintamahdollisuuden vai annatko yrityksellesi parempia tuloksia. Ajoitus, sijoitetun pääoman tuotto ja toimitettu voitto voivat luoda, ravistaa tai pilata yritystäsi. Löydät itsesi kysyvän itseltäsi: Mitä saamme rahoillemme? Voimmeko ennustaa kustannukset? Kuinka paljon haluamasi tuotteen luominen maksaa? Milloin voimme käynnistää sen? Saammeko laadukkaan tuotteen investointeihimme? Aikooko se kasvaa liiketoimintamme kanssa? Tarjoaako se liiketoiminnalle arvoa?

Joten miten voit arvioida projektin koon, keston ja kustannukset? Tutkitaan ohjelmistokehityskustannusten arviointia ketterässä projektinhallinnassa ja miten teemme sen ApeeScapessa.

Perinteinen sopimushinta ja arvio

Perinteisesti ei-ketteriä käytäntöjä käyttämällä ohjelmistoprojektit ovat pyrkineet korjaamaan toiminnallisuuden tai laajuuden ja jättämään ajan ja kustannukset muuttujina. Tämä aiheuttaa ongelmia:

1. Mistä tiedät, että toiminnot, joihin keskityt projektin alusta alkaen, ovat oikeastaan ​​se, joka palvelee parhaiten yritystäsi tai asiakkaitasi? Useammin kuin koskaan, toiminnallisuus tai laajuus muuttuu, minkä vuoksi kuulemme usein 'laajuuden korruptiosta', joka johtuu siitä, että halutut tarpeet tunnistetaan projektin koko elinkaaren aikana ja määritetään tarpeen mukaan. tai pakollinen.

2. Kun kustannuksista tulee muuttuja, menetämme hallinnan sijoitetun pääoman tuottoprosentista (ROI), jonka yritämme saavuttaa. Kustannusten nousu on usein tunnistamattomien riskien tai muuttuvien vaatimusten tulos, mikä tarkoittaa, että meidän on lisättävä tiimin jäseniä, jotta saisimme enemmän työtä samassa ajassa, tai jätettävä tiimin jäsenet pidempään. Kumpikaan ei ole toivottavaa.

3. Kun aika on vaihteleva, menetämme hallinnan markkina-asemassamme. Saatamme menettää tärkeän läpimenoajan tai kilpailijat saavat tuotteensa ulos ennen meitä, mikä menettää tuotteellamme mahdollisesti olevan kilpailuedun.

Aika- ja kustannusmuuttujilla on erilaisia ​​tuloksia, jotka ovat usein ei-toivottuja ja negatiivisia.

Tietysti monet asiakkaat ja organisaatiot pyrkivät ratkaisemaan tämän 'taikakolmion' kaikki kolme osaa. Valitettavasti on lähes mahdotonta saavuttaa tämä realistisesti. Liian monta elementtiä salaliitossa häiritsee tätä ihannetta, mikä johtaa tuotteisiin, jotka eivät täytä tarpeita, vievät liikaa asiakkaiden hyödyksi tai maksavat liian korkealla liiketoiminnan arvojen toteuttamiseksi.

Ketterät sopimukset ohjelmistoprojekteille

Kustannukset ovat aika ja ihmiset (tiimin jäsenet) syntyvä tuote. Lisää enemmän aikaa ja kustannukset ihmisten palkkaamiseksi pidempään sisällytetään. Kun lisäät tiimin jäseniä, korotat saman liiketoiminnan arvon tuottamista, mitä haluamme välttää. Siksi ketterät periaatteet uskovat ajan ja tiimin jäsenten ratkaisemiseen ja liikkumavaran sallimiseen muuttuvana komponenttina.

Mikä kuulostaa paremmalta ja lisää sidosryhmien luottamusta, kiinteitä kustannuksia tai muuttuvia kustannuksia?

On tietenkin tärkeää, että tuote täyttää lupauksen ja asiakkaan tarpeet. Ei ole hyvä sijoittaa tiukka määrä aikaa ja rahaa, jos päädyt tuotteeseen, jota kukaan ei halua tai voi käyttää tehokkaasti.

Ketterät sopimukset keskittyvät seuraaviin:

• Kiinteähintaiset työpaketit: Koko projekti on jaoteltu 'pieniksi' loogisiksi versioiksi, jotka vaikuttavat tuotteen kokonaistulokseen. Jokainen julkaisu on työpaketti, joka hinnoitellaan vastaavasti. Kun työpaketit valmistuvat, tulevat työpaketit arvioidaan uudelleen sen perusteella, mitä olemme oppineet edellisestä. Tämä välttää tarpeetonta ennakoimattomuutta ja antaa asiakkaalle mahdollisuuden määritellä prioriteettien ja uusien / uudelleen harkittujen ominaisuuksien uudelleenjärjestelytaso.

• Odotettu irtisanominen: Tämä antaa asiakkaalle mahdollisuuden saada projekti päätökseen aikaisemmin, jos suuri osa tuotteesta on toimitettu, eikä enää ole mahdollista saavuttaa tuottoprosenttia säilyttämällä joukkue, joka tuottaa vain marginaalisia voittoja. Tämä lauseke on yleensä sallittu milloin tahansa ja on voimassa niin kauan kuin projektitiimillä ja asiakkaalla on ollut vahva, vilpitön ja läheinen yhteistyösuhde. Asiakkaan etu on, että projekti valmistuu nopeammin, kun se on toimittanut kaikki tuotteen toteuttamiseen tarvittavat edulliset ominaisuudet. Vastineeksi toimittajalle maksetaan 20 prosenttia jäljellä olevasta sopimuksen arvosta, ja henkilöstön pysymisen riski on tasattu.

• Joustavat muutokset: Muutos on aihe, joka kulkee ketterän ohjelmiston toimituksen suonissa. Toivomme, ettemme tiedä kaikkea, kun joudumme tekemään onnistuneen tuotteen tyhjästä. Joten edistämme muutosta luottamalla asiaan liittyviin tietoihin ja tuotepalautteisiin varmistaaksemme, että oikea toimitetaan. Toiston lopussa muutokset voidaan vaihtaa vanhoihin ominaisuuksiin, joita ei enää pidetä tarpeellisina tai prioriteeteina, kunhan uusi muutos on samanarvoinen eikä siitä aiheudu lisäkustannuksia. Jos muutos on vähäisempää, lisätyö voidaan tunnistaa tai se voidaan tehdä tilauskannasta. Tämä lauseke on voimassa niin kauan kuin projektitiimi ja asiakas ovat pitäneet vilpittömää, vahvaa ja läheistä yhteistyösuhdetta koko projektin ajan.

• Lisätyö: Koko projektin elinkaaren aikana voidaan tunnistaa enemmän ominaisuuksia, joita ei voida saavuttaa jo arvioidun projektin puitteissa. Tässä skenaariossa kaikki uudet työpaketit voidaan lisätä projektin loppuun tai keskittyä aikaan ja materiaaleihin.

• Etäisyysarviot: Ketterässä projektisopimuksessa arviot voivat olla kaukana kahdella tavalla: kestoalue tai ominaisuusalue. Kestävälin avulla arvio voi määrittää, kestääkö projektipaketti lopullisen saavuttamisen 12-16 viikkoa. Keston lisääminen lisää kuitenkin kustannuksia pitäen projektiryhmän jäsenet pidempään, tai tarkoittaa, että he eivät voi työskennellä muiden kehityshankkeiden parissa. ApeeScape-ohjelmassa mieluummin mitataan ominaisuuksia pistehistoriasta pitäen laajuus muuttujana, mutta lupaamalla tuottaa asiakkaan vähimmäistason työpaketille tai koko projektille asetetussa aikataulussa.

On syytä muistaa, että voit aina lisätä tavoittavuutta tulevaisuudessa. Ehkä sinulla on tuloja, olet lisännyt käyttäjien määrää ja pienentänyt kustannuksia. Kummassakin tapauksessa on paljon helpompaa pyytää enemmän rahaa ja aikaa, jos olet jo osoittanut hyödyn tai parannuksen ja tuottavat liiketoiminnalle arvoa.

Keskitymme ohjelmistokustannuksiin ja hinnoitteluun

Teemme läheistä yhteistyötä ApeeScapessa asiakkaiden ja insinöörien kanssa tekniikoiden kanssa, jotka lisäävät sidosryhmien luottamusta projektin kestoon ja kustannuksiin. Työskentelemme jatkuvasti suunnittelun kehittämisessä ja mukauttamisessa korkealta lähtötasolta yksityiskohtaisimpiin yksityiskohtiin, kun se on tarkoituksenmukaista ja tarpeen jätteiden välttämiseksi ja hallittujen muutosten mahdollistamiseksi.

Seuraavat vaiheet tehdään arvioiden ja kiinteän hinnan valmistamiseksi projekteille:

yksi. Korkean tason alkuperäinen ulottuvuus

Projektin alussa tiedetään vähän sen mahdollisista tuloksista. On hullua kuvitella varhaisessa vaiheessa, mitä ominaisuuksia asiakas ja käyttäjät saattavat haluta, joten aloitamme projektikaaviosta ja korkean tason joukosta 'eeppisiä' ominaisuuksia, jotka ohjaavat projektin suuntaa visioon ja ytimekkäisiin tavoitteisiin perustuen .

. Vision ja tavoitteiden säätö - Mitä meidän on rakennettava? Mitä meidän on saavutettava ja mitkä ovat liiketoimintatavoitteesi? Näiden kysymysten ymmärtäminen antaa meille mahdollisuuden selvittää projektin laajuus. Tarvitsetko prototyypin alkuperäisen idean, konseptin tai tekniikan testaamiseen? Oletko tunnistanut selkeän ehdotuksen, joka on testattu markkinoillasi, ja oletko valmis rakentamaan ensimmäisen Pienin kannattava tuote MVP )? Vai vahvistatko nykyistä yritystäsi tai tuotetta siirtyäksesi seuraavalle tasolle?

b. 'Eeppiset' ominaisuudet - Korkea taso menemättä yksityiskohtiin, sinun on määriteltävä ominaisuudet, jotka tuotteesi on täytettävä asiakkaasi tarpeiden mukaan. Tätä kutsutaan strukturoiduksi 'ostoslistaksi', joka kuvaa tuotteesi luurankoa; Näitä kutsutaan yleensä 'Käyttäjän tarinoiksi' tai eepoksiksi.

c. MoSCow-analyysi (MoSCoW-analyysi) - Se on tekniikka, joka yksinkertaisesti auttaa tunnistamaan, mitä todella tarvitaan tuotteen toteuttamiseksi ja mikä on hyvä olla. Pakolliseksi tunnistettu käsittää sen, mikä kannustaa käyttäjiä sitoutumaan tuotteeseen. 'Pitäisi' -ominaisuudeksi määritetyt ominaisuudet yllättävät ja ilahduttavat asiakkaitasi, mutta niihin voidaan myöhemmin liittyä. Niin sanotut 'voisi' -kohteet eivät usein tuota merkittävää liiketoiminnallista arvoa, eivät välttämättä lisää voittoa ja ovat alhaalla prioriteettiluettelossasi. 'Älä' tai 'ei' -ominaisuudet saattavat olla tärkeitä jonain päivänä, mutta eivät ole projektien toistamisen ulottuvilla. Kaikkien näiden tuotteiden tai ominaisuuksien tunnistaminen voi kuitenkin auttaa määrittämään tuotteen potentiaalisen mittakaavan ja koon tulevaisuutta varten.

Pitäisikö, pitäisikö, voisiko, ei

2. Ehdotus

Päätöksen tekemiseksi hankkeen jatkamisesta on perustuttava vakiintuneisiin tietoihin: kustannuksiin ja kestoon. Tämä on vähiten mitä sinun tulisi kysyä itseltäsi: Mitä tarvitaan luomaan haluamasi tuote? Milloin voimme käynnistää sen? Yhdistetäänkö se liike- ja rahoitusstrategiamme kanssa?

Mainittujen yksityiskohtien avulla voimme esittää ehdotuksen. Suunnittelijamme valitaan huolellisesti projektin erityisvaatimusten mukaan ja työskentelevät yhdessä projektipäällikön kanssa saadakseen ainakin teknisen ratkaisun, kestoarvion, joka kertoo meille tunnetun laajuuden ja kustannusarvion projektin loppuun saattamiseksi.

Kuten aiemmin mainitsimme, projektin alkuvaiheessa tiedämme vähiten siitä, mitä toimitetaan. Säilytämme tarkoituksenmukaisesti ominaisuudet ja laajuuden epämääräisesti, sillä muuten se osoittaisi, että tiedämme tarkalleen mitä vaaditaan. Arvio tässä vaiheessa olisi epätarkka, mutta se olisi opas siitä, jatketaanko hanketta vai ei.

Ehdotus on ensimmäinen työkalu hankkeen keston ja kustannusten määrittämiseen. Kun ehdotus on hyväksytty, voimme jatkaa ja tarjota kiinteän hintatarjouksen.

3. Käynnistä suunnittelu

Seuraava vaihe arvioinnissa on luoda a julkaisusuunnitelma joka antaa joukon ominaisuuksia tietyn ajan kuluessa. Tämä johtuu ominaisuuksien luettelosta, projektin koosta ja siitä, kuinka nopeasti tiimimme pystyi kehittämään laadukkaita ohjelmistoja asiakkaiden odotusten ja epävarmuusriskien hallinnan tekniikoiden mukaisesti.

. Tuotteet: tuotekannan se on yksinkertaisesti järjestetty luettelo 'eepoksista' tai 'käyttäjäkertomuksista', joka edustaa tuotteen vaadittuja ominaisuuksia. Tämä luettelo alkaa kuten edellä luetellut eepokset, mutta projektitiimille, projektipäällikölle ja asiakkaalle määritetyn ryhmän välillä jaamme ne nyt merkityksellisempiin kohteisiin. Jokainen näistä tuotteista edustaa osan asiakkaan liiketoiminnan arvosta. Emme käsittele tarkempia yksityiskohtia tässä vaiheessa, meidän ei tarvitse tietää hyväksymiskriteerejä, meidän ei tarvitse tietää, onko painike sininen tai vihreä, meidän on vain tiedettävä, että on painike, jonka avulla jokin tehtävä voidaan suorittaa suoritettava.

b. Arvio - Nyt kun meillä on luettelo ominaisuuksista, joita käyttäjäkertomukset hahmottavat, joukkue arvioi nämä erilliset ominaisuuselementit käyttämällä 'Poker Planning' -tekniikkaa. Tämä on hyödyllinen tekniikka, joka takaa nopeat ja luotettavat tulokset, jotka perustuvat asiantuntijalausuntoon ja vastaavaan mitoitukseen. Pokerin aikataulu antaa jokaiselle tuotteelle sovitun numeron, joka edustaa sen kokoa ja monimutkaisuutta. Tätä kutsutaan tarinapisteeksi. Muut tekniikat Ketterä arvio ja mitoitus, kuten 'Ihanteelliset päivät' (ihanteelliset päivät) ovat myös saatavilla.

Tämän prosessin lopussa määritetään projektin koko ja ominaisuuksien väliset riippuvuudet. Koko tai ulottuvuus määritetään lisäämällä kaikki tarinapisteet tuotekannan kohteista. Jos tämä luku on 120, projektissamme on 120 tarinapistettä.

c. Prioriteetti - Kun meillä on projektin tilanne ja koko, voimme priorisoida sen asiakkaan kanssa. Kyse on asiakkaalle arvokkaimman tunnistamisesta haluttujen tulosten saavuttamiseksi. Luettelon yläosassa olevaa kohdetta pidetään tärkeimpänä, toinen on vähemmän tärkeä kuin ensimmäinen ja niin edelleen koko luettelossa. Kaksi kohdetta ei voi olla yhtä tärkeä toisilleen, jokaisella nimikkeen prioriteetilla on suhteellinen merkityksensä tai arvonsa muihin kohteisiin nähden.

Tämä lähestymistapa priorisointiin on tärkeä virstanpylväs ohjelmistoprojektin suunnittelussa. Tiedämme, mikä on asiakkaalle tärkeää ja mikä on järjestys työn valmistamiseksi, riippuvuudet huomioon ottaen, toimittaa odotuksia vastaava tuote.

d. Käynnistyssuunnittelu - Tähän mennessä olemme määrittäneet, miltä tuote näyttäisi ja kuinka suuri se olisi.

Nyt on määritetty, kuinka kauan kestää toteutettavissa olevan tuotteen toimittaminen. Asiakas ja tiimi, mukaan lukien suunnittelijat, insinöörit, testaajat, scrum master ja projektipäällikkö, selvittävät yhdessä, mitä voidaan saavuttaa ja kuinka nopeasti ne voisivat työskennellä julkaisusuunnitelman luomiseksi.

Lanseeraussuunnitelma tarjoaa myös visio siitä, miten projekti sovitetaan asiakkaan strategisiin suunnitelmiin.

Lopuksi tämä suunnitelma varmistaa, että projektiryhmällä on ohjaava valo, joka valaisee polun ja määrittelee loogisen loppupisteen kehitettäväksi.

Ennen kuin aloitamme, varmistamme, että ymmärrämme sovitun määritelmän 'valmis'. Kyse on tietyistä kriteereistä, jotka asiakas hyväksyy valmiiksi ja jotka myös täyttävät kaikki insinöörien vaatimukset, jotta niitä voidaan pitää valmiina ja toteutettavissa olevina.

Perusskenaarion suorittamiseksi otimme kertomuspisteistä saamamme kokonaispistemäärän ja jaoimme sen tiimillemme nopeus odotettavissa. (NB-nopeus ilmaistaan ​​normaalisti alueena, mutta yksinkertaisuuden vuoksi käytämme lukua). Työskentelemme kahden viikon iteraatioissa, jotta nopeutemme heijastuu siihen, mitä kahden viikon jaksolla voidaan saavuttaa tiimin käytettävissä.

Jos tarinamme pisteet ovat yhteensä 120 ja odotamme 20 pisteen suorittamista iteraatiota kohden, projektin kehittämisen kokonaiskesto olisi 12 viikkoa tai kuusi iteraatiota. Tähän lisätään 0–2 viikon sprintti ja 2 viikon laukaisun valmistelusprintti. Projektimme kesto on yhteensä 16 viikkoa. Voimme käyttää tekniikoita, jotka auttaisivat rakentamaan suunnittelumme kannalta sopivan väliriskisäätimen, josta keskustellaan myöhemmin. Yhteenvetona voidaan todeta, että puskuria tai sääntelyviranomaista käytetään hallitsemaan epävarmuusriskiä ja pääsemään sopimukseen odotettavissa olevista tarinapisteistä. Tuloksena voi olla alue, joka on 90-150 tarinapistettä, 90 on vähimmäismäärä, joka olisi hyväksyttävä toimivan tuotteen luomiseksi.

Vaihtoehtoisesti, jos projekti on tarkoitus saada päätökseen tiettyyn päivämäärään, esimerkiksi 10 viikkoon, tiimi päättää, kuinka suuri osa tilauskannasta voidaan suorittaa tuolloin. Jos ennakoimme 20 tarinapistettä sprinttiä kohti, plus sprintti 0 ja sprintti julkistetaan, pyrimme saavuttamaan 60 pistettä projektin loppuun mennessä. Tietysti riskiä pyritään hallitsemaan lisäämällä sopiva puskuri, mikä voi johtaa 45-75 tarinapisteen valmistumiseen ja valmiina julkaisemaan yleisölle. 45 tarinapistettä sopisivat yhteen hyväksyttävän vähimmäismäärän kanssa toimivan ja arvokkaan tuotteen toimittamiseksi. Tämä on tilanne, jossa voit ennakoida joukkueen jäsenen lisäämisen nopeuden lisäämiseksi tarvittaessa.

Tietysti kaikkea edellä mainittua tukee laadukas viestintä ja yhteistyö kaikkien osapuolten välillä, jotta voidaan saada asiakkaalle toteutettavissa oleva, realistinen ja uskottava käynnistyssuunnitelma.

1. Kiinteän hinnan sopimus

Kun laukaisusuunnitelma on sovittu, voimme luoda budjetin kiinteähintaiselle sopimushankkeelle. Kuten edellä mainittiin, on suositeltavaa pitää projektin kesto ja tiimi kiinteänä ja laajuus muuttujana.

Tarjous kiinteän hinnan sopimuksesta toimitetaan yhdessä työilmoituksen ja maksuaikataulun kanssa.

Niin kauan kuin on luottamusta, viestintää, yhteistyötä ja halukkuutta päästä ketterän ohjelmistoprojektin henkeen, kaikkien mainittujen vaiheiden avulla voimme antaa kiintiön realistisella varmuudella siitä, että tuote toimitetaan ajoissa ja budjetista. Tietysti on aikoja, jolloin projekti toimitetaan sovittua aikaisemmin tai myöhemmin, joten käsittelemme näitä muunnelmia suurimmalla avoimuudella.

Arviointitekniikat

Ketterä suunnittelu ja arviointi perustuvat useisiin tekniikoihin, joita kehitystiimi voi käyttää saadakseen enemmän luottamusta sen kokoon, ponnisteluihin, kestoon ja kustannuksiin. Alla on joitain tekniikoita, joita tiimimme käyttävät arvioidakseen ohjelmistoprojektin koon ja kustannukset.

Arvioi koko

Projektin koko on itse asiassa arvio sen laajuudesta, monimutkaisuudesta, ulottuvuuksista, riskistä ja laajuudesta. Analogia tästä olisi tietää, rakennammeko Eiffel-tornia vai Kiinan suurta muuria. Eiffel-torni on pitkä, raskas ja monimutkainen rakenne, joka rakennettiin pienessä kaupunkimaisemassa. Kiinan muuri on suhteellisen yksinkertainen, mutta pitkä ja kestävä rakenne, joka ulottuu monta kilometriä mutkaisella maastolla.

Vaikka molemmat olisivatkin toteutettavia suuria hankkeita, niiden laajuus, monimutkaisuus, mitat, laajuus ja siten niiden koko ovat erilaiset.

On tärkeää hallita odotuksia arvioilla. Ne eivät ole koskaan ennusteita, sitoumuksia tai takauksia. Kun keskustelet koosta, kestosta ja kokonaiskustannuksista, työskentelet aina rajojen sisällä riskien, epävarmuuden ja tuntemattomuuden vähentämiseksi.

Tuotteen ominaisuuksia kuvaavilla tarinoilla on yksilölliset koot ja arviot tarinapisteiden tai ihanteellisten päivien avulla. Näiden yksiköiden kokonaismäärä määrittelee projektin koko.

Historiapisteet

Tarinapisteet ovat metrinen yksikkö, joka edustaa käyttäjäkertomuksen kokoa. Tarinan koko voi arvioidessaan sisältää kaikki suunnittelun, suunnittelun, testauksen, koodin tarkistuksen, integraation jne. Näkökohdat.

Jokainen tarinan koko on suhteessa toiseen tarinaan. Esimerkiksi tarina A voidaan mitata yhdellä pisteellä, tarina B 2 pisteellä ja tarina C 3 pisteellä. Joten tarina C on vähintään kolme kertaa tarinan A kokoinen ja vähintään puolet tarinan B kokoinen.

Jos seuraaviin tuotekannan tarinoihin liittyy samankokoisia kokoja:

Historia	Koko
TO	yksi
B	5
C	3
D	yksi
ON	2

Projektin koko on 12 tarinapistettä.

Ihanteelliset päivät

Se on päivinä ilmaistun koon mitta. Poista yleiskustannukset, kuten keskeytykset, ketterä suunnittelutoiminta, sähköpostien lukeminen ja muut projektin ulkopuoliset toiminnot. Se keskittyy vain siihen, kuinka kauan sen valmistuminen kestää, jos työskentelet jatkuvasti jossakin keskeytyksettä alusta loppuun kuluneen ajan sijaan.

Normaalisti, kun sen arvioidaan olevan korkealla tasolla, josta tiedämme vähän projektista, se arvioitaisiin ihanteellisina päivinä, koska se on yksinkertaisempi käsite korreloida aikaisempien kokemusten ja historian kanssa kuin abstrakti luku, kuten historian kohta. Kun tarinat ovat korkealla tasolla, ne ovat eeppisempiä, yksityiskohtia vähäisempiä ja mahdollisesti myös muita elementtejä, kun ne myöhemmin jaetaan.

Kun arvioidaan tarkemmin, esimerkiksi tarina vakiintuneessa tuotevirrassa, voidaan käyttää mitä tahansa lähestymistapaa ja suunnittelutiimi päättää tarkalleen, mitä käyttää. Molemmilla lähestymistavoilla on etuja, ja jokaisella joukkueella on omat mieltymyksensä.

Arviointitekniikat

Jaetut arviot - Arviot eivät ole erillisiä. Ne toteutetaan koko suunnittelutiimin yhteistyössä, ja ne sisältävät suunnittelun, tietokannan, palvelimen, käyttöliittymän (käyttöliittymän), laadunvarmistuksen (QA) ja muut asiantuntijat. Näin vältetään ongelmat, joita ei tule ottaa huomioon kaikkia toiminnon suorittamiseen tarvittavia työn näkökohtia, sekä varmistaa, ettei kenelläkään ole velvollisuutta tai epäonnea aliarvioida toiminnon kokoa tai olla sen ulkopuolella. Yhdistetyllä tiimillä on visio, josta voidaan keskustella ja hyväksyä sitten päätös.

Vastaavat arviot - Näiden kahden erillisen ominaisuuden perusteella otetaan huomioon ja toinen päätetään olevan suhteellisen pienempi tai suurempi kuin toinen. Voisimme tarkastella tarinaa ja sopia, että se ei ole suuri, ja jos tarinapisteitä käytetään, se voisi olla kaksi. Seuraavaa tarinaa voidaan pitää yhtä suurena kuin ensimmäistä, ja annamme sille viiden koon. Tämä viittaa siihen, että suuri ominaisuus voi olla kaksinkertainen pienempään.

Tämä harjoitus suoritettaisiin kaikkien tarinoiden kanssa. Ja kun se on valmis, meillä voi olla kaikki tarinamme, olivatpa ne pieniä, keskikokoisia, pitkiä ja erittäin pitkiä rinnakkain, ja tarkista koko varmistaaksesi, että arviossa on tasainen johdonmukaisuus.

Pokerisuunnittelu - Planning Pokerista on puhuttu paljon; Mainitsin sen toisessa blogi (Ultimate Johdatus ketterään projektinhallintaan) . Ja yksi parhaista resursseista sen ymmärtämiseksi voidaan nähdä tässä .

Se yhdistää periaatteessa asiantuntijalausunnon, analogian ja tiimien yhteistyön yhdeksi helpoksi, nopeaksi ja luotettavaksi prosessiksi.

Se kokoaa yhteen useita asiantuntijoita, jotka ovat sopivimpia tekemään arvio teknisen kokemuksen ja toimialan, dynaamisen vuoropuhelun ja vankan perustelun perusteella.

Nopeus

Nopeus mittaa joukkueen kykyä viimeistellä työ tietyllä iteraatiolla (tai sprintillä).

Se ilmaistaan ​​alueena, esimerkiksi 23-32 tarinapistettä sprinttiä kohden, varsinkin projektin alussa. Yleensä tämä johtuu siitä, että ellei sama joukkue ratkaise samanlaista ongelmaa, on vaikea määrittää, mikä joukkueen nopeus olisi. Huomaa, että tarkoitamme joukkueen nopeutta eikä yksittäisen nopeutta.

Nopeutta käytetään julkaisun suunnitteluun ja työsuunnitelmien ja pakettien mukauttamiseen projektin edetessä, mikä mahdollistaa vaatimustenmukaisuusolettamiemme säätämisen säännöllisesti ja tarkasti koko toteutuksen ajan.

Kun aloitamme, meidän on pakko määritellä nopeusalue, jolla on vähän tietoja. Historiallisia arvoja voidaan käyttää, jos laitteet ja ongelma-alue ovat samat, mikä ei ole todennäköistä. Projektissa työskentelevän ryhmän kanssa on mahdollista toistaa, jotta saat nopeuden tunteen, mutta se on kallista eikä toimi, jos projektin aloittamisesta tehdään vielä päätöksiä. Myös ennuste voitaisiin tehdä.

Nopeuden ennustaminen sisältää useiden tarinasprinttien ottamisen ja niiden jakamisen tehtäviksi, jotka suoritetaan tarinan loppuun saattamiseksi. Arvioidaan kunkin tehtävän tuntimäärä, joka sisältää muun muassa suunnittelun, kehittämisen, testauksen ja arvioi joukkueen kapasiteetin tietyssä sprintissä. 70 prosentin kapasiteetti sitoutuneelle joukkueelle on hyvä perusta. Tästä syystä yksinkertaisessa tilanteessa, jos joukkueen käytettävissä olevat tunnit ovat esimerkiksi:

• 4 tiimin jäsentä * 2 viikkoa * 40 tuntia viikossa = 320 tuntia
• Kerrotaan 70% kapasiteetilla = 224 tuntia
• Lisää kaikki ominaisuustehtävät ja lopeta laskeminen 224: ssä
• Ota kaikki valmiit ominaisuudet, lisää yhteen tarinapisteet ja saat nopeuden, sano 36
• Nimeä 20% kummallekin puolelle sijoittuaksesi matalimmalle ja korkeimmalle saavuttaaksesi arvioidun nopeuden 29–43 tarinapistettä

Nopeus vaihtelee yleensä ensimmäisten 2 - 4 iteraation aikana ja vakautuu sitten pienellä pistealueella. Siksi on olemassa ensimmäinen alue, ennen kuin ensimmäinen sprintti oli 29–43, kun se saavutti sprintin 4, se voi vakiintua 34: stä 38: een. Tämä antaa meille enemmän luottamusta lopetuspäivän ennusteeseen.

Puskurisuunnitelmat riskejä ja epävarmuutta varten

Kaikissa ohjelmistoprojekteissa on epävarmuutta. Tämä epävarmuus vähenee projektin edetessä ja tekniikasta, ympäristöstä, suorituskyvystä sekä asiakkaiden ja käyttäjien tarpeista tiedetään enemmän.

Tätä epävarmuutta vähennetään puskurilla tai säätimellä ohjelmoinnissa, jota edustaa estimaatin virhemarginaali ja tuntemattomat tekijät, joita ei voida määrittää ennen kehityksen aloittamista.

Puskureita on tyypillisesti kahta tyyppiä: ominaisuus ja ohjelmointi. Koska määrität aina kiinteän hinnan kiinteälle toimituspäivälle, on suositeltavaa käyttää ominaisuuspuskuria.

Tämä lähestymistapa tarjoaa uskottavan riskinhallintastrategian ja antaa asiakkaalle luottamuksen projektin toteuttamiseen tai siihen, mitä he näkevät projektin lopussa.

Ominaisuuspuskurit

Ominaisuuspuskurin avulla ennustetaan, että tietty joukko ominaisuuksia toimitetaan, mutta toinen ominaisuuksien joukko valmistuu myöhemmin. Tämän tulisi näyttää vähimmäisominaisuudet, joita asiakas pitää välttämättöminä toteuttamiskelpoisen tuotteen lanseeraamiseksi, mutta annettua aikataulua voidaan toimittaa enemmän, jos erilaiset sisäiset ja ulkoiset vaikutteet sen sallivat.

Joten asiakas voi päättää, että tuotteen myöhästymisen tärkeimmät ominaisuudet, yhteensä 100 tarinapistettä, ovat tärkeämpiä. Asiakas voisi sitten harkita lisäominaisuuksia, jotka lisäävät vielä 30 tarinapistettä. Jos näin on, joukkue aikoo toimittaa 130 tarinapistettä, joista vähintään 100 valmistuu kiinteähintaisen sopimuksen päivämäärän loppuun mennessä.

Lopulliset ajatukset

Ketterä käsite voidaan ymmärtää ja mukauttaa. Mikä on yhtä totta, kun on kyse arkaluonteisten asioiden, kuten hinnan, laajuuden ja keston, käsittelystä. Valitettavasti tiedän, että vaativat asiakkaat haluavat, että kaikki korjataan heti, ja yleensä syyttävät toimittajaa, kun kaikki alkaa hajota. Vastaavasti olen tietoinen siitä, että jotkut myyjät, jotka eivät halua tehdä kompromisseja, ovat tuntemattomia eivätkä vastaa asiakkaiden tarpeisiin. Ketterän lähestymistavan valinnassa on välttämätöntä olla luottamus, hyvät suhteet ja erinomainen viestintä. Molempien osapuolten on noudatettava näitä arvoja, jotta voidaan ylläpitää tervettä projektia, josta on hyötyä molemmille ja joka tarjoaa tyydytystä ja menestystä kaikille. Sinun on pidettävä avoin mieli ja rakentava asenne yhteistyöhön ja neuvotteluihin, tämä on paras tapa estää suhteiden rappeutuminen.

Joskus joidenkin asiakkaiden on vaikea sopeutua ketterän menetelmän mukautuvuuteen ja jättää hallinnan ja komennon asenne. Ei ole helppoa laittaa kaikki uskosi ja luottamuksesi joukkueeseen, jota et tunne. Suurimman osan ajasta asiakkaat haluavat luoda kaikki vaatimukset etukäteen tarkennuksena siitä, mitä he odottavat saavansa toimituksen yhteydessä. Tämä antaa heille luottamuksen siihen, että projektin laajuus on määritelty hyvin. Mutta loppujen lopuksi tämä ei toteudu hyvänä lähestymistapana. Jos soveltamisala ja vaatimukset eivät ole todellisia ja niiden kanssa on työskenneltävä sopimuksen vuoksi, monet ongelmat syntyvät nopeasti.

Tiedetään, että tätä lähestymistapaa perinteisissä menetelmissä soveltamisala voi muuttua, tuntemattomia voidaan paljastaa tai se, mitä asiakas uskoi haluavansa, ei ole enää totta tai on täysin erilainen. Mukautuva lähestymistapa hinnoitteluun, suunnitteluun ja soveltamisalaan antaa asiakkaalle mahdollisuuden tunnistaa tuotteesi siten, että se on juuri sitä mitä tarvitset haluamasi markkinat. Tämän avulla palveluntarjoaja voi olla reagoiva, kekseliäs ja tehokas. Asiakkaan ja myyjän yhteistyön hyödyntäminen sopimusneuvotteluissa on avainasemassa.

Myyjien on oltava rehellisiä ja asiakkaiden on oltava realistisia etukäteen, mitä voidaan saavuttaa. Myyjä, joka antaa epärealistisia lupauksia kohteista ja nostaa sitten kustannuksia, voi voittaa sopimuksen, mutta pian on tyytymätön asiakas käsissään. Suhteet hajoavat usein molempien osapuolten välisen luottamuksen puutteen vuoksi. Luottamus on rakennettava alusta alkaen ja ylläpidettävä koko projektin ajan. Myyjän on oltava joustava ja tehtävä yhteistyötä tarvittaessa. Asiakkaat haluavat aina enemmän; Tämä on luonnollinen seuraus liiketoiminnasta. Arvojen vaihdon on oltava yhtä tasainen, mikä hyödyttää molempia. Asiakkaat pyrkivät luomaan arvoa liiketoiminnalleen. Myyjien tulisi yrittää luoda arvo, jonka avulla heillä on pitkät suhteet asiakkaisiinsa. Ketterien arvojen manifestin ja sen periaatteiden tutkiminen on vankka perusta muodostaa pitkä, vahva ja tasapainoinen suhde.

johtopäätös

Toivottavasti tämä antoi sinulle käsityksen ohjelmistoprojektin suunnittelusta, arvioimisesta ja hinnoittelusta Ketterä . Kaikki tässä kuvatut lähestymistavat ja tekniikat on suunniteltu rakentamaan luottamusta tiimiin ja edistämään asiakkaiden luottamusta siihen, kuinka kauan ohjelmistotuote kestää ja maksaa. Rakenna lopuksi itseluottamusta, kun on kyse päätöksestä jatkaa.

Noudata näitä oppaita ja löydät varmasti tyydyttävän reitin seuraavan ohjelmistotuotteen herättämiseksi eloon.