Projektide alustamine

Targo TennisbergArendusjuht ja isehakanud guru

http://www.targotennisberg.com/tarkvara

Oktoober 2008

Projektijuhtide roll

Projektijuhid pole mitte lihtsalt selleks, et klienti ja programmeerijat teineteise eest kaitstaTarkvaraprojekt sisaldab põhimõtteliselt tundmatust

Muutuvad tehnoloogiad, kliendid, vahendid jneTundmatus -> ebakindlus -> risk -> vajadus riske hallataLõputult asju, mis võivad puusse minna

Peamine ülesanne enne projekti algust on riskide identifitseerimine ja maandamine

Vahe tähtajas ja eelarves lõppeva projekti ning “tahtsime parimat, aga välja tuli nagu alati” projekti vahelEnamik riske õnneks kontrollitav vastavate kontrollküsimuste nimistute abil

Riskihaldus

Risk pole iseenesest midagi hirmsatRiski teadvustamine ja vastavate meetmete kasutamine on pool võitu

Riskihaldus peaks olema formaliseeritudMiinimumvariandis lihtsalt mingisse dokumenti kirja panna

Osalistel võimalik riske teadvustada

Struktuurne mehhanism probleemide ennetamiseksRiskide tõsidusega arvestamine aitab meil keskenduda õigele probleemile

Aitab arvutada õige suurusega projektilõtkuRiskide dokumenteerimine projektist projekti aitab vältida vigade kordamistVaja hoida värsket nimistut “meie top 10 riski”

Projektiriskide testid

Pea igas tarkvaraarenduse / projektijuhtimise käsiraamatus on mõni test/nimistu

Lugege raamatuid Software Project Survival Guide, Steve McConnellPractical Project Initiation, Karl Wiegers

http://www.targotennisberg.com/tarkvara/survival_test.html (Steve McConnelli ainetel)http://www.targotennisberg.com/tarkvara/2008/06/06/eduka-projekti-retsept Joeli test

http://www.joelonsoftware.com/articles/fog0000000043.html

Enne projekti alustamist tuleb mõelda, kuidas neist testidest hiljem kuiva nahaga pääseda

Tüüpriskid - juhtimine

Ebapiisav planeerimine ja ülesannete identifitseerimineProjektistaatuse ebapiisav läbipaistvusEbaselge projektijuhtimise ja otsuste tegemise struktuurAntud ebarealistlikud lubadusedEbarealistlike ootustega juhtkond või kliendidIsiksuste konfliktid personali hulgas

Tüüpriskid - nõuded

Selge projektivisiooni puudumineNõuetealase kokkuleppe puudumineKliendi (ja kasutaja) puudulik osalus nõuete defineerimiselPrioritiseerimata nõudedEbaselgete nõuetega uus turgKiiresti muutuvad nõudedEbaefektiivne nõuete muutmise protsessNõuete muutmiste tagajärgede ebapiisav hindamine

Tüüpriskid – puudulikud teadmised

Puudulik koolitusPuudulik arusaam meetoditest, vahenditest ja tehnoloogiastVähene arusaam ärilisest rakendusvallastUued tehnoloogiad või arendusmeetodidEbaefektiivne või halvasti dokumenteeritud arendusprotsess (või ignoreeritakse seda üldse)Tehnilised lähenemised, mis ei pruugi töötada

Tüüpriskid – sõltuvused / liidestus

Kliendi omaloodud andmestruktuurid v –hoidladSisemised või välised allhankijadKomponentide vahelised sõltuvusedVastavate kogemustega inimeste olemasoluKomponentide taaskasutus ühest projektist teise

Tüüpriskid - allhankimine

Tellija nõuded on ebaselged, valed või mittetäielikudTellija ei vasta allhankija küsimustele täielikult ja operatiivseltAllhankijal puuduvad asjakohased tarkvaraarendus- ja juhtimisprotsessidAllhankija ei tarni tähtajaks piisava kvaliteediga komponenteAllhankija ostetakse üles kellegi teise poolt, satub finantsraskustesse või lõpetab tegevuse

Tüüpriskid – allhankimine 2

Allhankija annab ebarealistlikke lubadusi, et hanget saadaAllhankija ei anna projekti staatusest täpset ja operatiivset infotLepingus kirjeldatud projektiskoobi üle puhkevad vaidlusedKui allhankija asub teises riigis, võivad tekkida probleemid impordi/ekspordiseadustegaKommunikatsioon, materjalide edastamine ja edasi-tagasi sõitmine aeglustavad projekti käiku

Projekti edu tagamise sammud

Eelnevalt oli juttu sellest, mis võib valesti minna, mida me saame teha, et läheks hästi?1. Defineerida ärilised eesmärgid2. Identifitseerida osapooled ja nende huvid3. Identifitseerida ja prioritiseerida projekti kitsendused4. Koguda nõuded5. Tuletada projekti edukriteeriumid6. Projekti skoop täpselt piiritleda7. Luua kirjalik projektiplaan8. Luua operatiivsete kokkulepete struktuur kliendiga9. Defineerida ja katta vastutusalad10. Defineerida projektis kasutatavad protsessid11. Luua vajalik tehniline infrastruktuur

Ärilised eesmärgid

Puuduvad hämmastavalt paljudes projektidesTeeme midagi, aga keegi ei tea, miks

Peavad olema selged kõigile projekti osalistele (konsensus)SMART – Specific, Measurable, Achievable, Relevant, Time-specificNäiteid:

Saavutada X kuuga Y regioonis Z% turuosaJõuda X kuuga kasumisseTöödelda X transaktsiooni päevas Y täpsusegaRahuldada valitsuse määruses nr X toodud nõudedVähendada kasutajate teenindamiseks kuluvat aega X tunni võrra Y% juhtudest

Meie situatsioonis on eesmärgid tihti nõuete kujul (eriti riigihangetel)

Sellegipoolest oluline ärilisi eemärke mõistaKlient ei pruugi teada, mida ta tegelikult tahab

Osalised ja nende huvid

Osalised on kõik, keda projekt mõjutab või kes mõjutavad projektiSisemiste osaliste näiteid:

Projektijuht, analüütikud, sponsor juhtkonnast, arendajad, testijad, IT, sisemised partnerid, omanikud, marketing, tootmine, finants, juristid, müük

Väliste osaliste näiteid:Kasutajad (otsesed ja kaudsed), tellijad, valitsuse nõuete seadjad, audiitorid, standardiorganisatsioonid, allhankijad, materjalide tarnijad, seonduvate toodete haldajad ja kasutajad, äripartnerid, avalikkus

Osalistel on soovid, eelkujundatud suhtumised, võidulävi ja piirangud, mis tuleb identifitseerida

Võivad projekti käigus muutuda – tähtsamate osalistega tuleb suhelda läbi kogu projekti

Osalised ja nende huvid 2

Tuleb defineerida, kuidas me lahendame osalistevahelisi huvide konflikte

Näiteid: konsensus, erinevate kaaludega hääletamine, üks inimene on diktaator, komitee otsustab mingi analüüsi põhjalPeamine on, et me mõistame ja järgime otsustusreegleid

Kõige olulisem osaline on projekti sponsorSponsor maksab meie laste leiva eestIlma sponsorita projekt tavaliselt hävibSponsorlust tuleb hoida kogu projekti jooksul!

Tähtsamad osalised peavad olema ühel nõul järgmistes punktides:

AjakavaRessursidSkoopNõutav kvaliteet

Projekti piirangud/paindlikkus

Tarkvaratootmises on alati ebakindluse aspektPaindlikkuse telgedel 1=projekti täielik ebaõnnestumine, kui piirangute piires ei tulda toimeIlma mingi paindlikkuseta projektid (väga väikese pindalaga viisnurk) ebaõnnestuvad tavaliselt

Vaja teada, mida esimesena ohverdada kui häda käesOluline tähtsamate osalistega läbi rääkida

Tähtajast mõeldakse tihti kui fikseeritud suurusestEnamasti tegelikult teatud paindlikkus

Nõuded

Milleks meile nõuded?Kui me ei tea, mis on meie vajadused, siis me ei tea, millal me valmis oleme Täpsemad nõuded -> projekti tähtaja parem ennustatavus -> $$

3 nõuete tasetÄrilised

Rahuldavad ärilisi vajadusi (vt eespool)

KasutajanõudedKirjeldavad, mida peab kasutaja saama produktiga teha

FunktsionaalsedSüsteemi kirjeldus erinevates tingimustes

Kõik peavad olema kirjeldatud!

Nõuded

Otsest funktsionaalsust mittepuudutavad nõudedJõudlus

Milline on maksimaalne samaaegne kasutajate arv?Milline on keskmine ühe kasutaja poolt teostatavate operatsioonide arv minutis?Millised on eeldatavad andmemahud põhitabelites? Milline on andmete hulga kasv päevas/kuus/aastas põhitabelites?Millised on enamkasutatavad operatsioonid?Millise ajaga peavad olema teostatud enamkasutatavad/tavalised operatsioonid arvestades ülaltoodud operatsioonide arve ja andmemahte?

Käideldavus: Mis on tegelik maksimaalne lubatud downtime?Kuidas mõõdame SLAle (service level agreement) vastavust? Kuidas teostatakse vigade parandust toodangus ning millised on reageerimisajad?

Projekti edukriteeriumid (xkcd)

Projekti edukriteeriumid

Tehnilised mõõdikud, mis on tuletatud ärilistest eesmärkidestArendajatele ei saa seada eesmärgiks “saavutada 40% turuosa”

Projektijuhtimise ülesanne on tõlkida ärilised eesmärgid tehnilisteks

Eesmärgid peavad olemaRealistlikudKvantifitseeritudBinaarselt kontrollitavad (jah/ei)

NäiteidProjekti maksumus on X% piires ettenähtud eelarvest ja tähtajastDefektide arv on <XVeebisait kannatab välja X üheaegset kasutajat keskmise viitega Y sekunditPärast koodi kliendile üleandmist ei esine üle X ärikriitilise veaKogu 1. prioriteedi funktsionaalsus antakse üle X tähtajaks

Eesmärke peab olema mõistlik hulk – tuleb prioritiseerida

Skoop

Skoobikirjeldus on leping tellija ning projektimeeskonna vahel, mis kirjeldab:

Mida projektis tehakseJa ka seda, mida seal ei tehta

Piir peab olema selgelt paigasSoovitavaid muudatusi lihtne testida, kas nad on ühel või teisel pool piiri

Eriti tähtis juhul, kui projekt on vaid väike osa suurest visioonist

Uued ja uued visiooni osad “imenduvad” projekti

Skoopi hea kirjeldada kontekstidiagrammiga

Piiritleb süsteemi sisendid ja väljundid

Kontekstidiagrammi näide

Projektiplaan

Sagelilevinud arvamus, et igasugused plaanid ja dokumendid on mõttetu ajaraiskamine

“Hakkame parem ometi koodi kirjutama”

Plaani kirjutamine on tegelikult lihtneVõib kasutada mõnd olemasolevat plaanipõhja ja valida sealt relevantsed kohad

http://www.slideshare.net/ahmedhasan/ieee-1058-1998-software-project-management-plan/IEEE standard – väga põhjalik

Raske osa on tegelik planeerimine Kirjaliku plaani vajadus sunnib meid selle kohe ära tegemaMillalgi tuleb need küsimused niikuinii vastata ja hiljem on ajakulu palju suurem

Projektiplaani osad

Kõrgtaseme ajagraafikPeamiste ülesannete kirjeldusPersonal, eelave ja muud ressursidRollid ja vastutusaladKuidas vajalikke inimesi leida ja koolitadaEeldused, sõltuvused ja riskidPeamiste komponentide kirjeldused ja tähtajadIdentifitseeritud tarkvara loomise metoodika Projekti monitoorimise protsessi kirjeldusKogutavad ja analüüsitavad mõõdikudSuhted allhankijatega

Kokkulepped kliendiga

Tihedad tarnedKiire tagasiside tarnetele Tarnete paigaldusprotsess (kes paigaldab, kes ehitab, kuidas propageeritakse andmestruktuur ja andmed, etc)Tarne vastuvõtukriteeriumidKiire arendusse minevate tööde kinnitamise protsess Skoobimuudatuste haldamise protsess (funktsionaalsuse vahetamine, lisarahastus, vms)

Kokkulepped kliendiga 2

Ligipääsud nende sisevõrgu ressurssideleTestkeskkond (rakendusserver, andmebaas): vähemalt logidIntegreeritavad süsteemid (AD, ERPid, vms)Taaskasutatav infoarhitektuur (kliendid, arved, kasutajad, tooted vms)

Tarnitava dokumentatsiooni nimekiri ja sisukirjeldusKes koolitab lõppkasutajaid? Ligipääs rakenduse lõppkasutajatele töö monitoorimiseks ja tagasiside saamiseks (motiveeritud inimesed)Kokkulepped kasutatavate tehnoloogiate ja teekide osas  (ka siis kui kliendil on “ükskõik” tuleb “jah” sõna kätte saada)Kuupäevad, mil saame ligipääsu asjadele millest meie projekt sõltub

Kui klient neid ei pea, siis me ei garanteeri enam oma tähtaegu

Vastutusalad projektis

Allpool näiteid mitmesugustest projekti tegevustestIgal tegevusel peab olema konkreetne vastutajaVastutaja peab teadma, milliste valdkondade eest ta vastutab Iga tegevus peab kajastuma projekti graafikus

TehnilisedKõrgtaseme arhitektuurTehniline (detailne) disainKoodikirjutamineDetailsete etapiviisiliste ajagraafikute koostamineInstallatsiooniprogrammi loomineVanast süsteemist andmete konverteerimineIntegreerimine (projekti omavahelised komponendid ja liidestused teiste süsteemidega)Testimine (sh funktsionaalne, suitsu-, integratsiooni-, jõudluse ja koormustestimine)DokumenteeriminePlaanide, hinnangute, arhitektuuri, disaini, etapiplaanide, koodi, testimisplaanide ülevaatusedÜlevaatuste ja testimise käigus leitud vigade parandamineVersioonikontrollisüsteemi haldamineEhitusskriptide haldamineVanade projektide toetamineHädaolukordade lahendamine

Vastutusalad projektis

MittetehnilisedÜldine (tehniline ja mittetehniline) koordineerimineRiskihaldusProjektiplaani koostamine ja värskendamineProjektigraafiku jälgimineTellijaga suhtlemineLõppkasutajaga suhtlemineEtapitulemuste demonstreerimine juhtkonnale, tellijale ja kasutajateleNõuete muudatustega tegelemineMuudatuste mõju hindamine (tehnilise meeskonna poolt)Testijate küsimustele vastamineDokumenteerijate küsimustele vastamineTehnilise meeskonna koolitamineProjekti hiljem toetavate inimeste koolitamineEtapitulemuste üleandmine

Protsessid projektis

Kvaliteedi tagamise protsessTehnilised ülevaatused (spetsifikatsioon, arhitektuur, kood)VeahaldusTestimismetoodika ja –põhjalikkus

Unit testingFunktsionaalne testimineIntegratsiooni testimine

Kvaliteedi tagamiseks eraldatud pädevad inimesedMitte lihtsalt kõige noorem ja vähemkogenum projekti liige

Muudatuste tegemise protsessMillise suurusega muudatusi on võimalik/lubatud tehaKes ütleb lõpliku sõna muudatuste tegemise osas

KommunikatsiooniplaanLihtne tabel: asjaosalised, kommunikatsiooniaeg ja –viisNäiteid: projekti sponsor, emailida iga 2 nädala tagant, juhtiv arendaja, koosolek igal teisipäeval, tellija esindaja, helistada esmaspäeviti ja neljapäeviti

Projekti infrastruktuur ja vahendid

Enne tööleasumist tuleb planeerida ja üles seadaVersioonihalduse repositooriumÜlesannete haldus (ChangeLogic, TFS)EhitusskriptidNightly build system (kui ei kasutata ChangeLogicut)Testkeskkond (rakendusserverid, andmebaasid, muu)

KujundusTellida vajalik kujundusLõigata lahti taaskasutatavateks elementideks

Kokkuvõte

Tegevusi on paljuPaljud võimalik delegeerida, aga nad peavad tehtud saamaTegevustele tuleb planeerida vastav aeg ja inimressurssTegemata tööd tuleb millalgi ikka ära teha, aga arvatavasti kallima hinnaga

Thank You. Questions?