Riskit

Keltsi/Projektisuunnitelma/Riskit

Joku ilkeä hakkeri löytää tämän editointisivun -> editoi härskiyksiä -> typerää työtä ilkeän hakkerin etsimisessä => käytetään jotain tietoturvallista ratkaisua, kuten Linux-ympäristöä

Windows-ympäristö lakkautetaan -> ei voida työskennellä Windows kaatuu -> työtä menetetään => Käytetään Linux-ympäristöä

Projektikuri höltyy ja palataan perinteisiin menetelmiin. -> Projektin tavoitteita menetelmän suhteen ei saavuteta. Aikaa tuhlaantuu. Mitään ei saada aikaiseksi. =>

Yhteistä koodausstandardia ei saada sovittua. Aika kuluu koodin ulkoasun kanssa leikkimiseen. Riidellään välilyöntien paikasta. Huonontaa ilmapiiriä. => pyritään alusta alkaen sopimaan Sun standardin mukaisesta koodausstandardista.

Goaleja ei saada selvitettyä. Projektin määrittely on epämääräinen. => Goalien tekeminen on ykkösprioriteetissä

Ei tehdä testejä. Uusien iteraatioiden tekeminen vaikeutuu huomattavasti. Projektin tuotosten laatu on alhainen. Softa kaatuilee. => Opetetaan testien tekeminen aikaisin. Mitataan testien tekemistä ja läpimenoprosenttia. Laaditaan funktionaaliset testit testaaman asiakastarinoiden toteutumista.

Projektipäällikön aika loppuu. Goaleja ja asiakastarinoita ei saada tehtyä. Kokousten esityslistat jäävät tekemättä. Kaikki tapahtuu ad hoc. => lisää vastuuta itse tiimille

Projektiryhmän jäsen sairastuu eikä pääse paikalle. => Käytetään pariohjelmointia, ei ongelmaa koska kaiken tiedon pitäisi välittyä koko ryhmälle. Näin menetetään vain pieni osa työstä.

Projektipäällikkö sairastuu eikä pääse paikalle. Ryhmä joutuu toimimaan ilman ohjausta. => Harjoitellaan XP-rutiinit riittävän itseohjautuviksi, ja tehdään yksi versio projektin loppuun saakka ulottuvasta iteraatiosuunnitelmasta sisältöineen.

Uusia asioita ja työkaluja on liikaa. Aika menee niiden opetteluun. Tehokasta työtä ei saada juuri tehtyä. => Ei oteta liikaa uusia työkaluja. Käytetään projektin alussa aikaa uusien työkalujen opetteluun.

XP nopeat iteraatiot ja testit aiheuttava liikaa ylimääräistä työtä. Projektin aikana ei saada kuin pieni osa tarkoitetusta valmiiksi. Testien tekemisestä ja dokumentaatiosta pidättäydytään. => Pyritään painottamaan laadun tärkeyttä sisällön kustannuksella. Pyritään tarjoamaan asiakkaalle hänelle eniten lisähyötyä tuottavat ominaisuudet laadukkaasti.

Paperidokumentoinnin vähemmälle huomiolle jättäminen hermostuttaa TKTL ja kurssin vetäjiä. Arvosanat huononee ja laitos ei saa standardinmukaista dokumentaatiota. Tutkijoiden työ projektien jälkikäteisseurannassa vaikeutuu. => Viimeinen iteraatio käytetään dokumentointiin.

Antin wikiwikiwebiä pyörittävä kone hajoaa. Projektin dokumentointi hukkuu eikä uutta voida tehdä. => Antti tekee backupin wikistä viikoittain CVS:ään.

Laitos vaatii runsaasti ulkoisia, ryhmän sisäisen toiminnan kannalta ylimääräisiä dokumentteja. Ryhmän toiminta hidastuu lähes pysähtymispisteeseen. Muutoksien tekeminen on raskasta. Testaamisesta luovutaan. Joustavuus häviää. Laatu on olematonta. Iteraatioiden aikana ei saada paljoakaan aikaiseksi. Projektin tavoitetta saada proof of concept-tyylinen prototyyppi ei saavuteta lähellekään. => Projektipäällikkö pyrkii neuvottelemaan järkevän dokumentaatiotavan.

Testausta ei tehdä tai tehdään vähän. Projektin tuottaman koodin laatu on olematonta. Koodi on täynnä bugeja. Refaktorointi ei onnistu, kun muutokset rikkovat tuotantokoodin. => Tehtävät hyväksytään valmiiksi vasta kun niistä on oikeasti tehty testit ja koodi on integroitu tuotantokoodiin.

Asiakkaat ja muut ulkopuoliset intressiryhmät eivät sopeudu XP-menetelmän radikaaleihin eroihin verrattuna perinteiseen vesiputousmalliin. Syntyy kitkaa ja kommunikointi on vaikeaa, sillä kumpikaan osapuoli ei ymmärrä toisiaan. => Pyritään ottamaan ulkopuolisten intressiryhmien tarpeet huomioon siinä määrin kuin ne ovat kohtuullisia oman työn valmiiksi saamiseksi.