Tölvumál - 01.02.2008, Qupperneq 40

4 0 | T Ö L V U M Á L
Skipta verktíma í ítranir: Það að skipta verktímanum niður í ítranir/spretti
þar sem ákveðinn hluti kerfisins var hannaður, forritaður, prófaður og svo
hleypt af stokkunum kom vel út að flestu leyti (sjá þó umfjöllun síðar um of
stuttar ítranir). Það skiptir mjög miklu máli í flestum hugbúnaðarverkefnum
að afurðirnar líti dagsins ljós sem fyrst. Aðal ástæðan fyrir því er sú að það
er í raun ekki fyrr en fólk er komið með eitthvað í „hendurnar“ sem það
treystir því að verkefnið sé á réttri leið.
Á meðfylgjandi mynd má sjá hvernig forritunin dreifðist á verktímann. Þar
kemur fram að strax í fyrstu viku var kóðun hafin og hélst hún nokkuð
jöfn þangað til í síðustu vikunni. Þetta er þvert á það sem gerist í mörgum
verkefnum þar sem kóðun eykst jafnt og þétt allan tímann og nær jafnvel
hámarki undir lokin.
Byrja að prófa strax: Fyrstu afurðir verkefnisins fóru í prófanir strax í lok 1.
viku. Til prófunar var aðalgluggi Windows biðlarans með einu textasvæði
og hnappi og fannst sumum gustuk að byrja að prófa þegar jafn lítið var
tilbúið. Við þessar prófanir fundust 27 villur!
Einingaprófanir á skilum (build): Mikill tími fór í prófanir á skilum við
miðlægar þjónustur MiFID hugbúnaðarins. Segja má að einn forritari hafi
nánast verið í fullu starfi við einingaprófanir. Enda fór það svo að villan sem
fannst í þjónustunum var prentuð út og hengd upp á vegg.
Leysa villur jafn óðum: Það reyndist mjög vel að ráðast á villurnar jafn
óðum. Þetta gaf kost á því að nota síðustu vikuna til að endurprófa og
undirbúa útgáfu kerfisins.
Það sem virkaði ekki
Of stuttar ítranir: Verktímanum var skipt upp í 7 ítranir. Hver ítrun var því
tæplega ein og hálf vika en almennt er mælt með því að hver ítrun sé 4­6
vikur. Hópurinn rak sig fljótlega á það að ítranirnar voru of stuttar og mjög
erfitt var að koma nokkru fyrir á þeim tíma. Tvisvar var því gripið til þess
ráðs að sameina ítranir og urðu þær því 5 talsins þegar upp var staðið. Þó
er ekki víst að betra hefði verið að fækka ítrunum enn frekar.
Erfitt að skilgreina atburðarásir/notkunartilvik (scenarios/use cases): Það er
gömul saga og ný að erfitt getur verið að lýsa í texta því sem hugbúnaður á
að gera. Í MSF er farin sú leið að skilgreina svokallaða atburðarás (Scenario)
sem lýsir því sem notandinn er að reyna að framkvæma og hvað það er
sem hann vill geta gert í hugbúnaðinum. Í okkar tilfelli hefði verið hægt að
skilgreina þessar atburðarásir betur og hefði þær þá nýst betur við forritun
og prófanir. Hins vegar er rétt að benda á það að daglegir „scrum“ fundir
minnka þörf fyrir skriflegar skilgreiningar sem þessar.