DT blogi

Aeg-ajalt tekib projekte, mis valmivad väljaspool meeskonnatööd ja elavad mõne projektis üksi osaleva arendaja käe all. Mõnikord läheb neil projektidel hästi. Tavaliselt mitte ja probleemid tekivad ikka siis kui seda kõige vähem oodatakse. Kuidas võiksid sellised projektid meid kummitama hakata?

Puuduvad kokkulepped meeskonnaga

Meeskondades on tavaliselt paigas omavaheline kommunikatsioon, valitud on vahendid ja töömeetodid. Kõik, mis väljapoole seda jääb, tuleb meeskonda üllatama selliste probleemidega:

• lahenduse ülesehitus ei vasta sellele, kuidas arendusmeeskond lahendusi tavaliselt ehitab,
• kasutatud on teiste teadmata mitmeid tehnilisi vahendeid, millega teistel kokkupuuted puuduvad või mille kasutamise on arhitekt välistanud,
• et lähtekoodi üle puudub meeskondlik kontroll, on selle kvaliteet tugevalt alla meeskonna enda keskmist,
• üksi ja omapäi tegutsemine annab täiesti vabad käed ignoreerida keerukamaid vahendeid, mida meeskond projektides kasutab,
• valminud lahendus on väga raske liidestada kvaliteedikontrollisüsteemidega, sest lähtekood ei arvesta selle võimalusega (inimene ehk arvestas tasemel, et küll nad siis pärast vaatavad),
• kontroll valmiva lahenduse üle on 100% ühe inimese käes ja projektijuhi riskid on seega kõrged arvestades arendajate äärmist optimismi.

Ma olen täiesti kindel, et siia nimekirja annab lisada veel terve posu asju, mis juhtuda võivad. Samas need mõned punktid siin peaks olema piisav, et olukorda hinnata õudusjutuks.

Seda probleemi ei teki meeskonnas töötava arendajaga, kellele antakse antud lahendus kõrvaltegemiseks või kes määratakse täies ulatuses uue lahendusega tegelema. Kui tal säilub meeskonnaga side, siis on tema vastutus küll suurem, kuid ta tegutseb siiski selliselt nagu meeskonnas on välja kujunenud. Samas peab see arendaja olema tugev tegija, sest vastutama peab ta nüüd kordi suuremas ulatuses kui meeskonnas tegutsedes.

Projektijuhi probleemid

Paraja üllatuse saab selliselt valminud süsteemi korral ka projektijuht, kes soovib antud süsteemi anda üle oma projektimeeskonnale edasiseks arenduseks.

Oma üllatuseks avastab projektijuht, et kuigi süsteem on valminud just siinsamas  keskkonnas, meie üldkasutatava infrastruktuuri peal, on sellega jätkamine sarnane väliste süsteemide ülevõtmisele:

• meeskonna jaoks on nii kood, selle ülesehitus kui ka lahendused võõrad,
• kasutatud on vahendeid, mida meeskond oma igapäevases töös ei kasuta,
• terve hulk koodi tuleb ümber kirjutada, et see vastaks nõuetele, mida meeskond oma lahendustele esitab,
• lahendust on pagana raske panna automaatsele kvaliteedikontrolli vahendite külge ja selleks tuleb kõvasti vaeva näha.

Kindlasti saab projektijuht kinnitust hinges vaikselt närivale kahtlusele: selle süsteemi andmine meeskonnale toob kaasa samasugused ajakulud nagu kaasnevad nende süsteemidega, mis mujalt sisse tulevad mingil kujul. Küsinud arendajatelt hinnangud, saab ta oma kahtlusele 200% kindla kinnituse.

Kuidas probleemi vältida?

Selle probleemi vältimiseks on olemas mitmed nõksud, kuid peamine neist on see: ära jäta inimest tegutsema üksi. Kaasa algusest peale keegi meeskonnast, kes hoiab asjadel silma peal ja aitab vältida igasuguste anomaaliate teket. Kindlasti on soovitatav selline lahendus paigutada kohe algusest kvaliteedikontrolli süsteemide külge, et sellel oleks lihtsam silma peal hoida.

Samuti soovitan seda, et olulisemad otsused, mis lahenduse ülesehitust puudutavad, räägitakse läbi meeskonnaga, kuigi meeskond ise otseselt arendusse segatud pole.

Kirjutas Gunnar, 19.01.2012 kell 13:47, teemal Tarkvaraarendus. Jälgi selle postituse kommentaare läbi RSS-uudistevoo (feed). Lisa kommentaar või tagasisideviide (trackback) oma veebilehelt või blogist.