xDUF

Esimese GeekDinneri teemaks oli xDUF ehk Big Design Up Front (BDUF), Enough/Little Design Up Front ja No Design Up Front. Vestlus oli igati huvitav ning neile, kes ei jõudnud tulla, väikene tutvustus seisukohtadest.

Esimene äärmus, mille vaatluse alla võtame on BDUF. See parktika on tulnud otse ehitusest – kõigepealt tuleb plaanid valmis teha ja siis hakata reaalselt ehitama. Tundub esmapilgul loogiline samm, kuid tarkvara on siiski pehme ja lihtsamini muudetav kui maja, mida ehitatakse.  Teine problemaatiline koht selle vaate puhul on, et peaksime suutma võtta kõike arvesse võtta ja seda siiani inimesed teha ei suuda.

Mittetäielikkuse printsiip:
Ei ole võimalik kõike arvesse võtta, kõike määratleda, kõike põhjendada.
[Lorents, “Süsteemse käsitluse alused”, lk 26]

Peale printsiibi mõjutab suurt plaani ka maailma muutused. Äri on tihtipeale muutlik ning meeletu planeerimine võib kasutu olla, kui valimis saab. Lean põhimõtete järgi on see rämps ehk kasutu töö (suures mahus süsteemi spetsifikatsioon seisab riiulis ja osa funktsionaalsust võib üldse ära jääda).

BDUF teine ots on NDUF, mis juba nime järgi tundub olevat kauboilik lähenemine või häkkimine. Küll kuidagi saab järgnevad nõuded juurde lisada. Tavaliselt tekkib suur tehniline võlg, mida keegi ei soovi ära maksta ning proovitakse uuesti alustada. Seda praktikat võiksid kasutada äärmisel juhul väga tugevate disaini oskuste ja arhitektuuriliste teadmistega inimesed. Selle peale pole mõtet rohkem aegagi kulutada.

Kuldne kesktee on siinkohal pigem piirkond kui punkt. LDUF/EDUF puhul tuleb küllaltki palju lähtuda enda meeskonna võimetest ja enesekindlusest. Projekti alguses tasuks panna paika arhitektuurilised väärtused ja konventsioonid koodi kirjutamise ja disaini osas. Need pole kivisse raiutud ning neid võib vajadusel muuta. Teine hea praktika on visandada mudel, mis annaks üldise pildi, kuidas ehitatav maailm välja näeb (see ei pea olema ilusasti joonistatud UML diagramm mõnes programmis, vaid visandid tahvlil on piisavad).

Projekti käigus on meil võimalik hõlpsalt kasutada parktikad nagu Test Driven Development/Behavior Driven Development, sest kõik ei ole nö geeniuste poolt ette kirjutatud. Lisaks võib toetavad mudelid võtta küllaltki standardsed, mis võiksid natuke aega kokku hoida.

Minu poolsed argumendid on praegu lauale laotatud, võib-olla on teil midagi lisada või vastu väita.