Kõige täielikum nõuete haldamise ja jälgitavuse juhend

Nõuete olek ja muudatuste taotlemine

Nõuete olek

Projektiga kursis püsimiseks jälgige iga nõuet kogu selle eluea jooksul. Täiendava turvalisuse ja täpsuse tagamiseks võite selle teabe salvestamiseks isegi määrata atribuudi väärtuse. Seda tüüpi oleku jälgimine aitab vähendada tarkvaraprojektide puhul levinud dilemmat – valeväiteid, et see on üheksakümmend protsenti tehtud. Igal nõudel peab mis tahes aja jooksul olema üks järgmistest olekutest:

Toetas (keegi toetas seda jõuliselt)
Heakskiitmise protsess oli edukas ja eraldamine on seatud lähtetasemele.
Pärast koodi hoolikat koostamist, skriptimist ja testimist rakendasime selle.
Kui nõue läbis ja testid läbis, kontrolliti selle edukat integreerimist tootega.
See nõue täidetakse hiljem.
Otsustate selle kustutada ja mitte rakendada.
Loobunud (kontseptsioonile ei antud kunagi rohelist tuld)

Lisaks eelnimetatud olekuvalikutele võib kaaluda ka muid olekuid. Mõned võivad valida oleku „Üle vaadatud”, et kinnitada oma nõuded enne nende lisamist põhikonfiguratsioonidesse. Teise võimalusena võivad organisatsioonid kasutada „Kliendile tarnitud” vahendit, et kontrollida, kas nad on nõude puutumata ja õigesti vabastanud.

Kui uurite arendaja käekäiku, võib ta vastata, et selle konkreetse projekti jaoks on 87 nõuet. 61 on juba kinnitatud ja 9 on paigas, kuid ootavad veel kontrollimist, samas kui 17 on veel lõpetamata. Siiski on oluline märkida, et kõik need taotlused ei ühti, kui rääkida nende suurusest või mõjust klientide rahulolule. need võivad nõuda ka erinevat pingutust. Projektijuhina poleks mul kahtlustki, et meil oli täpne arusaam allsüsteemi suurusest ja sellest, kui lähedal see valmimisele oli. See on palju tõhusam, kui lihtsalt öelda: "Ma olen umbes üheksakümmend protsenti valmis". Üldise edusammude pildiga võin kindlalt öelda: "See näeb suurepärane välja!"

Muuda taotlusi

Eduka nõuete haldamise saavutamiseks peab teie organisatsioon tegelema iga nõuete lisamise, kustutamise ja muutmisega. See võimaldab teil jälgida kõigi muudatustaotluste olekut ja mõju. Saate neid andmeid kasutada ka mitmele päringuküsimusele vastamiseks, näiteks:

Kui palju muutmistaotlusi on määratud aja jooksul esitatud?
Kui paljudele taotlustele on vastatud ja kui paljud on jäänud lahendamata?
Kui suur oli taotluste heakskiitmise määr ja kui suur protsent lükati tagasi?
Mil määral kulutas meeskond energiat iga lubatud muudatuse tegemiseks?
Kui kaua on taotlused tavaliselt avatud?
Kui paljusid üksusi (nt nõudeid või artefakte) iga esitatud muudatustaotlus mõjutab keskmiselt?

Veenduge, et jälgiksite kõiki arendusprotsessi käigus tehtud muudatusi pärast iga versiooni lähtetaseme määramist. Pidage meeles, et üks muudatustaotlus võib avaldada mõju paljudele eri tüüpi nõuetele (kasutajale suunatud, funktsionaalsed ja mittefunktsionaalsed). Et hinnata, kui palju muudatusi konkreetsel ajavahemikul tehti, jagage muudatuste arv sellele perioodile eelnevate nõuete kogusummaga (nagu baastaseme määratlemisel).

Me ei taha nõuete volatiilsust täielikult eemaldada. Lõppude lõpuks on nende muutmisel sageli õigustatud põhjendus. Kuid samal ajal peame tagama, et meie projekt saab muudatustega hakkama ja täidab endiselt oma kohustusi. Lõpetamisele lähemale jõudmine toob kaasa lisakulusid, kui muudatusi tehakse sageli; see muudab raskeks kindlaks teha, millal oma toote maailmale lasete! Arengu edenedes peaks enamik projekte muutuma muutustele vastupidavamaks; teisisõnu peaks muudatuste vastuvõtmise kiirus järk-järgult vähenema, kuni see jõuab vabastamise lõppedes nullini. Iteratiivne lähenemine annab meeskondadele mitu võimalust lisada hilisematesse iteratsioonidesse täiustusi, jäädes samal ajal siiski iga tsükli ajaskaala järgi.

Kui teie meeskond on muudatustaotlustega üle ujutatud, on tõenäoline, et valimisprotsess ei olnud kõikehõlmav või projekti edenedes tekivad ideed jätkuvalt. Seetõttu on oluline jälgida, kust need muudatused tulevad turundusest, kasutajatest, müügiinimestest, juhtimismeeskondadest jne. Selle teabe jälgimine aitab teil kindlaks teha, kes ja mis vajab tähelepanu, et minimeerida tähelepanuta jäetud nõudeid ja vältida kommunikatsioonihäireid.

Kui muudatustaotlused jäävad pikemaks ajaks lahendamata, on see selge märk sellest, et teie muudatuste haldamise protsess vajab tähelepanu. Olen olnud isiklikult tunnistajaks ühele organisatsioonile, millel olid mitu aastat vanad ja endiselt pooleliolevad täiustamistaotlused. Selleks, et projektijuht saaks prioriteediks seada oma energiat mahajäämuse kõige olulisemate üksuste osas, peaks see meeskond määrama konkreetsed avatud taotlused kavandatud hooldusväljaanneteks ja muutma muud pikaajalised edasilükatud muudatused tagasilükatuks. Nii saavad nad hõlpsamini tegeleda esmatähtsate ja kiireloomuliste asjadega, enne kui hakkavad tegelema vähem pakilisemate küsimustega.

Aeg ja pingutus

Optimaalse jõudluse tagamiseks soovitame teil tungivalt üles märkida aeg, mille teie meeskond kulutab nõuete kavandamise ülesannetele. See hõlmab kvaliteedinõuete koostamist ja muudatuste juhtimist, edenemise jälgimist, jälgitavuse andmete loomist ja muid selle protsessiga seotud tegevusi.

Inimesed küsivad minult sageli, kui palju aega ja energiat tuleks pühendada projekti vajadustele. See vastus sõltub suuresti selle suurusest, meeskonnast, organisatsioonist ja selle eesmärgist. Selliste projektide kriitilistesse ülesannetesse investeeritud jõupingutuste jälgimine aitab teil tulevasi ülesandeid täpsete hinnangute abil paremini planeerida.

Kui teie meeskond on varem projekti lõpetanud ja pühendanud 10% oma ajast nõuetele, olete järelemõtlemisel märganud, et nende nõuete kvaliteeti saab palju parandada. Kui tegemist on mõne teise samalaadse projektiga, oleks projektijuhil mõistlik tagada, et põhjalike spetsifikatsioonide koostamiseks panustatakse rohkem – piisama peaks olema üle kümne protsendi olemasolevatest ressurssidest!

Andmeid kogudes ja analüüsides võrrelge projekti arendustegevust toote suuruse mõõtmisega. Teie dokumenteeritud nõuded annavad aimu selle üldisest suurusest. Täpsemalt saate võrrelda jõupingutusi testitavate individuaalsete spetsifikatsioonide, kasutusjuhtumite või funktsioonipunktide loendamiseks – olenemata sellest, mis on proportsionaalne teie toote mõõtudega. Kogudes oma toote suurusega seotud andmeid ja pannes tähele sellega seotud juurutamispingutusi, saate koostada täpsed hinnangud sarnaste tulevaste projektide ettevalmistamiseks.

Hirm võib mõlguda paljude meeles; karta, et tarkvara mõõtmisprogrammi väljatöötamine röövib oluliste ülesannete jaoks väärtuslikku aega. Vastupidi, tõhusa ja sihipärase meetrikasüsteemi rakendamine ei nõua liiga palju pingutusi ega energiat. Kõik, mida pead tegema, on luua andmete kogumiseks ja analüüsimiseks põhiinfrastruktuur ning julgustada oma meeskonnaliikmeid oma töötegevuse kohta asjakohaseid üksikasju logima. Kui loote oma ettevõttes mõõdikutel põhineva kultuuri, on hämmastav, mida selle meetodi abil saab õppida!

Ärge unustage seda postitust jagada!