Realisatsioon ja tarnimine

1. Realisatsioon ja tarnimine Targo Tennisberg Isehakanud guru http://www.targotennisberg.com/tarkvara Mai 2010

2. Projektijuhtimistarkvara • Millist tarkvara meil projektiga seoses vaja läheb? • Ajagraafikud • Nt MS Project • Kulude ja eelarve haldamine • Tihti mingi raamatupidamis- või finantstarkvara • Ressursihaldus (sh inimressursi) • Tiimitöö ja kommunikatsioon • Nt MS Project Server • Veahaldus • TFS, Bugzilla • Dokumentatsiooni haldus • Mingi dokumendihaldussüsteem • Versioneerimine, juurdepääsud, staatused

3. Tarkvaraprojektijuhtimistarkvara • Eripärad võrreldes “üldotstarbeliste” projektijuhtimistarkvara nõuetega • Lähtekoodi versioonihaldus • Erinevate arendajate töö integratsioon • Väljalasete haldus • Automaatne build, testimine jne • Integreeritud muudatuste kontroll

4. Ajagraafikute haldamise tarkvara • Sündmuste vahelised sõltuvused • Ülesannete vastavusse seadmine inimeste ja teiste ressurssidega • Hinnangute võimaliku ebatäpsusega arvestamine • Ülesannete organiseerimine vastavalt tähtajale • Paralleelsete projektide haldamine • Critical Path

5. Veahaldustarkvara • Kõik vead peavad olema kirja pandud • Igal veal peab olema konkreetne omanik/tegeleja • Vea reprodutseerimise sammud peavad olema kirjeldatud • Veal peab olema määratud prioriteet • Peab olema võimalik jälgida vea ajalugu • Lisaks veel organiatsiooni või projekti spetsiifilised väljad

6. Projektiigapäevane juhtimine • Kommunikatsioon • Arendusmeeskond • Klient • Välised partnerid • Planeerimine • Elu muutub, plaanid vajavad täiendamist • Etapiplaan, iteratsiooni plaan, nädala plaan • Probleemid peavad olema igapäevaselt näha

7. Projekti igapäevane juhtimine 2 • Probleemidelahendamine • Kiire ja adekvaatne reaktsioon igale probleemile • Kiirus suurendab kliendi usaldust • Väldib katkiste akende sündroomi • Skoobihaldus • Tihti jäetakse analüütiku teha • Tegelikult projektijuhi ülesanne, analüütik annab vaid sisendit • Kasumlikkuse printsiip jälle – teeme asju, mille eest makstakse

8. Tööülesannete seadmine • Projektijuht määrab: • Vastutajad • Tähtajad – arendaja annab hinnangu, aga tähtaeg siiski projektijuhi vastutada • Prioriteedid • Kas lahendus peab alati olema ilus? • Võib-olla mitte

10. Kliendi usaldus • Projektis pidev väike huvide konflikt • Tellija soovib rohkem skoopi väiksema ajaga • Täitja huvi vastupidine • Antud lubadusi skoobi ja tähtaegade suhtes peab täitma • Võimaldab skoobiväliste tööde osas oluliselt enam endale kindlaks jäämist

11. Tellija ja muudatuste kontroll • Muudatuste kontroll tuleb sisse seada kohe projekti alguses • Tellija enda huvides projekti õigeaegseks lõpetamiseks • Projekti mahu suurenemine on üldjuhul täitjale hea • Rohkem tööd ja leiba • Kasutada ära võimalusi mahu suurendamiseks • Balansseerida tehnoloogilise riski kuhjumisega

12. Tellija ja tundmatuse risk • Suurim riski allikas on tundmatus • Pisikese projekti arendusmaht on kohe hinnatav • Suurema oma mitte • Vältimaks tundmatust arenduses tehakse analüüsi • Väikese projekti analüüsimaht kohe hinnatav, suurema oma mitte • Vältimaks tundmatust detailanalüüsis tehakse eelanalüüsi • Nt 2 nädalat eelanalüüsi, 4 kuud detailanalüüsi, aasta arendust • Ei pea tasuta ära tegema tellija tegemata tööd

13. Tellija ja skoop • Mida PKD-s kirjas pole, seda pole olemas • Tellija ei tohi eeldada kasutuslugude realiseerimist, mida pole kirjeldatud • Isegi juhul kui ilma selleta pole võimalik jõuda skoobis oleva kasutuslooni • Samas tuleb meil analüüsi käigus aidata kliendil õigeid otsuseid teha

14. Tellija ja skoop 2 • PKD-s tihti hallid alad • Liiga üldiselt kirjeldatud funktsionaalsus • Tellijad kipuvad selles osas funktsionaalsust juurde kauplema • Baseline’iks lihtsaim viis ja vähim ajahinnang antud funktsionaalsuse loomiseks • Üle selle mineva funktsionaalsuse tarvis on muudatuste haldus • 2 päeva, 2 nädala, 2 kuu lahendused • Eelnevad väited võivad kõlada drakooniliselt, aga nad hoiavad teid halvemast

15. Tellija ja refaktoreerimine • Tihti leiame end olukorrast, kus: • Tarkvara on kohandatud ebasobivatesse oludesse • Tarkvaralahenduse koormus on oluliselt kasvanud • Tarkvara oli lihtsalt halvasti kirjutatud • Ainsaks lahenduseks refaktoreerimine ja mingite osade uuesti kirjutamine • Tellijatele see üldjuhul ei meeldi • Selgitada tellijale, et muutuvad olud nõuavad ka tarkvara kohandamist • Kulutada nt 10% uue funktsionaalsuse eelarvest vana funktsionaalsuse korrastamiseks

17. Suunamuutuse risk • Võib juhtuda, et süsteemi kirjelduseks loodud analüüsidokument erineb liialt palju reaalselt soovitavast süsteemist • Kohe kui see juhtub, tuleb tellijaga arutada • Algsed mahuhinnangud pole enam pädevad • Vaja kas uut fikseeritud kokkulepet või T/M arvelduse peale üleminekut

18. Arhitektuur – projektijuhi vaade • Süsteemi struktuur • Taaskasutuse analüüs • Nõuete realistlikkuse uuring • Kas meil on üldse võimalik sellist tarkvara teha? • Nõuete jälgitavus • Iga komponendi puhul peab teada olema, millisele nõudele see vastab • Realisatsiooniplaan • Arhitektuurivigade parandamine

19. Arhitektuuridokumentatsioon Arendajate ekspertiis Projekti keerukus

20. Arhitektuuri ülevaatused • Liiga palju formaalset arhitektuuri on väiksem viga kui liiga vähe! • Ülevaatus (review) parandab oluliselt iga dokumendi kvaliteeti • Aitab identifitseerida puudulikke nõudeid • Aitab identifitseerida liigset tööd • Kontrollida: • Korrektsust – kas asi hakkab tööle nagu vaja • Täielikkust – kas kõik eesmärgid on kaetud • Arusaadavust – kas inimesed on võimelised selle põhjal tööd tegema

21. Programmeerimine – projektijuhi vaade • Standardid • Lihtsus • Asjad on kas valmis või ei ole • Muudatuste kontroll • Igapäevane build • Igapäevane automaatne testimine

22. Koodistandardid • Klasside, moodulite, funktsioonide ja koodi asetus • Koodi kommentaarid • Nimestandardid • Muutujad, funktsiooni, klassid, failid • Funktsioonide maksimumpikkused • Maksimaalne funktsioonide arv klassis • Lubatav keerukuse aste

23. Koodistandardid 2 • Vastavus arhitektuuristandarditele • Mäluhaldus, vigade käsitlemine, multithreading jne jne • Vahendite ja teekide standardid • Vahendite ja teekide kasutamise konventsioonid • Lähtekoodi kataloogide struktuur • Lähtekoodi failide struktuur • Nt 1 klass=1 fail • Poolelioleva koodi tähistamine

24. Branchimine

25. Koodi integreerimine • Arendaja kirjutab koodi • Arendaja unit testib koodi • Arendaja käib oma koodi debuggeris läbi • Arendaja saadab koodi ülevaatusele • Arendaja saadab koodi testimisele • Kood vaadatakse üle ja testitakse • Arendaja parandab leitud vead • Parandused vaadatakse üle • Arendaja integreerib koodi põhi-branchi • Kood on valmis

26. Testimine – projektijuhi vaade • Kasutajaliidese prototüübi ülevaatus • *Kasutajajuhendi / spetsifikatsiooni ülevaatus • Arhitektuuri ülevaatus • Tehnilise disaini ülevaatus • Koodi ülevaatus • **Unit testing • *Integratsioonitestimine • Suitsutestimine • **Süsteemitestimine

27. Kas me oleme valmis? Tarkvara nimi _______________________ Kinnitan, et tarkvara on väljalaskmiseks valmis: Projektijuht: _________________________________ Juhtiv arendaja: ______________________________ Juhtiv testija: ________________________________ Valdkonna juht: ______________________________ Dokumentatsiooni haldaja: _____________________ Kasutajatoe haldaja: ___________________________ Turundusjuht: ________________________________

28. Isiklik ajahaldus • Eelnevates loengutes on selgunud, et projektijuhil on müriaad ülesandeid • Kuidas mitte hulluks minna? • Range prioritiseerimine • Üks asi korraga • Keegi ei jõua ise kõike meeles pidada • Vajalikud on abivahendid

30. Projektide lahkamine (postmortem) • Tark õpib teiste vigadest, loll ei õpi omadestki • Koosolek kõigi osalistega • Eeldatavasti taanduvad paljud probleemid inimestele • Vahel mõistlik reatöötajad juhtidest eraldada • Neutraalne osaline viib koosolekut läbi • Sisendid • Projekti mõõdikute tulemused • Projekti liikmete isiklikud kogemused

31. Projekti lahkamine - reeglid • Kõik peavad saama oma sõna öelda • Respekteerida teiste osaliste vaatekohta ja kogemusi • Vältida teiste inimeste ideede ja sisendi kritiseerimist • Vältida inimeste kritiseerimist minevikusündmuste eest • Mõelda juurpõhjustele, mitte ainult sümptomitele • Keskenduda mõistmisele, õppimisele ja tulevikku vaatamisele

32. Projekti lahkamine – küsimused • Mis läks hästi? • Teeme neid asju tulevikus jälle • Mis oleks võinud paremini minna? • Teeme teinekord teisiti • Millised asjad juhtusid, mis meid üllatasid? • Sisend tulevaste projektide riskianalüüsile • Millised aspektid meile endiselt arusaamatuks jäävad? • Vajavad veel lähemat uurimist • Igaüks peab saama vastata!

33. Projekti lahkamine – edasised sammud • Identifitseeritud tegevused tuleb ka ära teha!! • Vastasel korral inimesed kaotavad usu protsessi • Igale identifitseeritud probleemile omanik • Igale tegevusele tarnitav eesmärk ja tähtaeg

34. Kokkuvõte • Projekt on midagi väärt ainult siis, kui ta valmis saab • Alati vaja silmas pidada: kas meie tegevused aitavad kaasa projekti valmimisele?