Apr 15 2010
Vajadused ja nõuded
Kolmas loeng projektijuhtimisest.
Siit leiate slaidid. Ja siit audiosalvestuse.
Tänane loeng on suurel määral analüüsist. Aga isegi kui te ise olete ainult projektijuht ja analüüsiga ei tegele, peaksite ikkagi teadma, mis toimub ja kuidas on õige asju teha.
Räägin teile kõigepealt ühe loo.
Kui ma veel ise vaene üliõpilane olin, kärutasin vahel maailmas ringi häälega. Üldiselt lahe kogemus, sest rahvas, kes hääletajaid peale võtab, on üldiselt väga kenad inimesed.
Sekka sattus muidugi ka igasuguseid imeinimesi. Oli näiteks üks tegelane, kes ise ka ei teadnud, kuidas täpselt oma sihtkohta jõuda, tema meetodiks oli lihtsalt kohalike käest juhiseid küsida. Mina ei olnud kahjuks kohalik ja eriti aidata ei osanud. Kohalikku keelt ei tundnud me ka keegi ja nii juht seletaski inimestega käte ja jalgade abil. Ise oli ta küllaltki joviaalses tujus ja valis küsimiseks ka rahvast, kelle adekvaatsus minu meelest kõvasti soovida jättis, aga kes olin mina, et teda selle eest kritiseerida, eks.
Ja nii me tiirutasime ja tiirutasime, kuni lõpuks kulus mõnekümne kilomeetri läbimiseks mitu tundi.
Sel ajal oli mul küll teine elustiil ja rohkem aega kui praegu ja viivitusest polnud väga hullu, aga mõnes teises olukorras oleks see küll harja punaseks ajanud.
Tegelikult on meil siin ilmne analoogia tarkvarategemisega. Me võime tarkvaraprojekti ka läbi viia selliselt, et teema natuke midagi, siis küsime suvaliselt inimeselt instruktsioone, siis teeme jälle natuke, küsime mõnelt teiselt inimeselt jne. Mis te arvate, milliseid ajahinnanguid me sellise meetodi kasutamise korral saame anda?
Või siis võime hankida endale kaardi.
Ma olen ise suur kaartide ja kaarditarkvara fänn, katsun alati võimalikult suurt navigeerimisvõimekust omada, kui kusagil käin või sõidan.
Tänapäeval on selleks head võimalused, veebis ja GPS seadmetes olevad kaardid ütlevad meile minuti täpsusega, kuhu me mis ajaks jõuame.
Ja tarkvara on ka parem teha, kui meil on täpne instruktsioon ees, et nüüd teeme seda ja siis toda. Ajahinnangutest rääkimata.
Tegelikus elus juhtub aga, et meie tarkvara valmistamise instruktsioonid on pigem sellised. Natuke parem kui turbanis vanamehelt saadud instruktsioonid, aga mitte väga.
Ja ajahinnangud on ka muidugi vastavad.
Tänane loeng ongi sellest, kuidas oma kaart võimalikult täpseks saada.
Definitsioonide erisus on peamine segaduse ja kommunikatsiooniprobleemide allikas tarkvaraprojektis.
Definitsioonid tuleb algusest peale paika panna.
Lugu: HR department vs arendaja nimemuutuse teemal.
Nõuded tegelikult omaette pikk teema, sestap siin kaetud lühidalt.
Lõpliku spetsifikatsiooni sisu on tihti tracetav tagasi ärireegliteni.
Tarkvara võib olla nt veebisait või pihuarvutite süsteem vms asi
baba-interface
Näide: tehnoloogiline kitsendus, et me tohime kasutada ainult vaba tarkvara. projekt tehti .neti peale.
Kui mõni neist osadest jääb alguses kirjeldamata, ei pääse me sellest ikkagi – lõpuks tuleb ta lisada ja see võib tähendada olulist projekti ümbertegemise kulu.
Lugu: visioon