1 / 34

Realisatsioon ja tarnimine

Realisatsioon ja tarnimine. Targo Tennisberg Isehakanud guru http://www.targotennisberg.com/tarkvara Mai 2010. Projektijuhtimistarkvara. Millist tarkvara meil projektiga seoses vaja läheb? Ajagraafikud Nt MS Project Kulude ja eelarve haldamine

tasha
Download Presentation

Realisatsioon ja tarnimine

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. 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

  16. 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

  17. Arhitektuuridokumentatsioon Arendajate ekspertiis Projekti keerukus

  18. 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

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

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

  21. 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

  22. Branchimine

  23. 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

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

  25. 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: ________________________________

  26. 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

  27. 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

  28. 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

  29. 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!

  30. 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

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

More Related