T-76.115 Projektisuunnitelma Team Tubeless Muutoshistoria Versio Pvm Tekijä Kuvaus 0.1 3.10.2005 Kekkonen Ensimmäinen mallipohjaan täytetty versio 0.2 11.10.2005 Kekkonen Projektisuunnitelman täydennystä 0.3 13.10.2005 Kekkonen Projektisuunnitelman edelleentäydennys asiakkaan ja mentorin kommentteja varten 0.4 17.10.2005 Kekkonen Projektisuunnitelman täydennys PP iteraation palautusta varten Sisältö 1. Johdanto Tämä dokumentti on Team Tubelessin projektisuunnitelma Teknillisen korkeakoulun kurssilla T- 76.4115 Ohjelmistokehitysprojekti I. 1.1 Projektin tarkoitus ja laajuus Projektissa toteutetaan Test World Oy:lle järjestelmä rengastestien mittaustulosten käsittelyyn. Projektin työmäärä on rajattu 1190 tuntiin ja projekti alkaa 27.9.2005 ja päättyy 2.3.2006. Test World Oy on yksityinen, puolueeton ja riippumaton yritys, joka on erikoistunut autojen ja renkaiden talvitestaukseen. Yritys tekee tilaustyönä talvitestausta auto- ja rengasvalmistajille, viranomaisille sekä autoalan lehdille. Test World Oy palvelee asiakkaitaan myös vuokraamalla testiratoja, halleja, toimistoja ja avustavaa henkilökuntaa. [1] Testiraportteja luotaessa tehdään paljon virhealtista käsityötä esim. syötettäessä eri renkaiden nimiä laskentaohjelmaan. Testiraportit eivät ole tällä hetkellä yhdenmukaisia eli asiakkaille lähtee erilaisia ja -näköisiä raportteja. Projektissa tehdään TestWorld Oy:lle NohevaII-järjestelmä, jonka avulla testiraporttien luomista automatisoidaan sekä vähennetään virheitä poistamalla ylimääräiset käsisyöttövaiheet. Laskentaohjelmistosta tehdään stand alone -tyyppinen jolloin testiraportteja voidaan luoda välittömästi kun testitulokset on siirretty mittalaitteilta järjestelmään. 2. Osapuolet ja henkilöstö Projektiin osallistuu projektiryhmä, asiakas ja mentor. Projektiryhmä muodostuu kurssin opiskelijoista, jotka tuottavat projektin aikana asiakkaalle eli Test World Oy:lle ohjelmiston. Mentor on kurssin puolesta oleva assistentti joka ohjaa projektiryhmää ja antaa tarvittaessa apua. Projektin osapuolet on esitelty kaaviossa 1.
Kaavio 1: Projektiryhmän osapuolet 2.1 Projektiryhmä Projektiryhmä tuottaa NohevaII-järjestelmän asiakkaalle yhdessä sovittujen vaatimusten pohjalta. Alle on merkitty projektiryhmän jäsenet sekä kunkin päävastuualueet. Ryhmän webbisivut ovat osoitteessa http://users.tkk.fi/~stikkane/tt/. 2.1.1 Manageriryhmä Nimi: Markku Kekkonen Roolit: projektipäällikkö, työn ja testauksen suunnittelu ja seuranta E-mail: markku.kekkonen#hut.fi Nimi: Sami Tikkanen Roolit: Vaatimustenmäärittely, laadunvalvonta ja asiakasvastaavuus E-mail: stikkane#cc.hut.fi Nimi: Juha Kauppi Roolit: Pääkehittäjä E-mail: juha.kauppi#hut.fi 2.1.2 Kehittäjät Nimi: Tuomas Hellstén Roolit: TBD E-mail: thellste#cc.hut.fi Nimi: Tiina Korhonen
Roolit: TBD E-mail: tjkorho3#cc.hut.fi Nimi: Marko Lindström Roolit: TBD E-mail: marko.lindstrom#hut.fi Nimi: Jaakko Manelius Roolit: TBD E-mail: jmaneliu#cc.hut.fi 2.2 Muut osapuolet Projektiryhmän lisäksi projektissa ovat mukana asiakkaan eli Test World Oy:n edustajat Jukka Antila sekä Harri Eskelinen sekä kurssin puolesta mentor Markus Rautopuro. Asiakkaan vastuulla on kertoa projektiryhmälle toteutettavan järjestelmän vaatimukset sekä hyväksyä toteutettu järjestelmä. Nimi: Jukka Antila Rooli: asiakas E-mail: jukka.antila#testworld.fi Nimi: Harri Eskelinen Rooli: asiakas E-mail: harri.eskelinen#testworld.fi Nimi: Markus Rautopuro Rooli: mentor E-mail: markus.rautopuro#aureolis.com 3. Tavoitteet ja lopetuskriteerit 3.1 Asiakkaan tavoitteet Taulukko 1 listaa asiakkaan tärkeimmät tavoitteet ja niiden hyväksyntäkriteerit prioriteettijärjestyksessä. Taulukko 1: Asiakkaan tärkeimmät tavoitteet Tavoite 1. Toimiva, asiakasta hyödyttävä ja asiakkaan raportointitoimintaa kehittävä järjestelmä 2. Hyvä toimintavarmuus ja pieni virhealttius Hyväksyntäkriteeri Asiakkaan tekemä oma arvio projektin lopussa. Järjestelmä täyttää toimintavarmuudelle asetetut tavoitteet ja mittaustulosten laskennan on
3. Priorisointi eli avainkohtien toteuttamisjärjestys 4. Jatkokehitys - mahdollisuudet projektin jälkeen, koodin ja dokumentaation selkeys toimittava vrheettömästi. Vaatimukset toteutetaan sovitussa järjestyksessä. Koodi noudattaa koodauskäytäntöä ja dokumentaatio on asiakkaan kannalta selkeätä ja kuvaa toteutetun järjestelmän, joka mahdollistaa järjestelmän myöhemmän laajentamisen. 3.2 Projektiryhmän tavoitteet Taulukko 2 listaa projektiryhmän tavoitteet ja kriteerit, joilla nämä tavoitteet todetaan saavutetuiksi. Taulukko 2: Projektiryhmän tavoitteet Tavoite Hyväksyntäkriteeri 1. Kurssin läpäiseminen Ryhmä saa kurssista hyväksytyn arvosanan. 2. Arvosana vähintään 4 ja kurssin tavoitteiden täyttäminen 3. Sujuva ja tehokas yhteistyö ja kommunikaatio asiakkaan kanssa 4. Toimiva ryhmätyöskentely 5. Ajankäytön jakaminen siten että rajoissa ja tavoitteissa pysytään Ryhmän lopullinen arvosana kurssista on 4 tai 5 ja kukin ryhmän jäsen kokee saavuttaneensa kurssin asettamat oppimistavoitteet. Asiakkaaseen pidetään yhteyttä, siten ettei asiakas koe olevansa missään vaiheessa projektia pimennossa projektin tilasta. Toisaalta projektiryhmän työskentely ei saa keskeytyä siitä syystä ettei asiakkaalta saada tarvittavaa tietoa. Ryhmän jäsenet suorittavat määrätyt omat tehtävänsä ajoissa sovittuihin päivämääriin mennessä, siten että työmäärä jakautuu kokonaisuudessaan tasaisesti. Tehtävät jaetaan jo alussa ryhmän jäsenten kesken siten että työmäärä on jokaisen osalla mahdollisimman samansuuruinen ja ettei kenenkään työmäärä ylitä kurssin puitteissa 170 tuntia. Tehtävät priorisoidaan jotta vähintään välttämättömät tehtävät tulevat suoritetuiksi. 3.3 Henkilökohtaiset oppimistavoitteet Taulukossa kolme on listattuna projektiryhmän jäsenten henkilökohtaiset oppimistavoitteet.
Taulukko 3: Ryhmän jäsenten henkilökohtaiset oppimistavoitteet Ryhmän jäsen Markku Kekkonen Sami Tikkanen Juha Kauppi Tuomas Hellstén Tiina Korhonen Marko Lindström Jaakko Manelius Henkilökohtainen oppimistavoite Oppia (ohjelmisto)projektin johtamista ja saada parempi käsitys hieman isommista ohjelmistoprojekteista oikean asiakkaan kanssa. Syventää osaamistani ja saada kokemusta manageriryhmässä olemisesta, erityisesti pääkehittäjän näkökulmasta. Tavoiteenani on myös saada lisää kokemusta Javasta ja kommunikoinnista tämän kokoisessa ryhmässä. Oppia toimimaan hieman isomman projektiryhmän osana, sekä saada tuntumaa projektista oikean asiakkaan kanssa. Oppia ryhmätyötaitoja, oikean asiakkaan kanssa toimimista sekä saada käytännön kokemusta ohjelmistokehitysprosessista. 3.4 Projektin keskeytyskriteerit Projekti keskeytetään ryhmän yhteisellä päätöksellä, mikäli jokin seuraavista tilanteista toteutuu: Kolme tai useampia jäseniä lähtee ryhmästä Asiakasyhteistyö loppuu (esim. asiakkaan kiinnostus loppuu, resurssit loppuvat, avainhenkilöstö poistuu tai liiketoiminta muuttuu) Asiakas ei toimita materiaalia tai informaatiota sopimusten mukaan Kurssin läpäiseminen ei muusta syystä ole mahdollista 3.5 Projektin lopetuskriteerit Projekti lopetetaan, kun jokin seuraavista kriteereistä täyttyy: Kurssi päättyy aikataulunsa mukaan Tuote on toimitettu asiakkaalle sovitussa laajuudessa, asiakas on sen hyväksynyt ja asiakas hyväksyy projektin päättyneeksi Henkilökohtaiset aikarajat on täytetty 4. Resurssit ja budjetti 4.1 Henkilöt
Projekti on jaettu kolmeen eri vaiheeseen ja alla olevasta taulukosta selviää kuhunkin osaan budjetoitu työmäärä Taulukko 4: projektin suunniteltu työmäärä Kekkonen Tikkanen Kauppi Hellsten Korhonen Lindström Manelius Yhteensä PP 60 50 40 0 0 0 0 150 I1 60 60 70 100 100 100 100 590 I2 50 60 60 70 70 70 70 450 Yhteensä 170 170 170 170 170 170 170 1190 4.2 Materiaalit Käytämme projektin aikana hyväksi Asiakkaan olemassaolevaa testi- ja tuotantopalvelinta jossa tällä hetkellä pyörii Noheva I ohjelmisto. Projektiryhmä saa tarvittavat ylläpitotunnukset Asiakkaalta. 4.3 Budjetti Taulukossa 4 on hahmoteltu projektin budjettia, jos projektia ei toteutettaisi tämän kurssin puitteissa. Projektiryhmän työstähän ei todellisuudessa nyt laskuteta asiakkaalta mitään. Taulukko 5: projektin budjetti Kustannuserä Määrä Hinta Asiakkaan SoberIT:lle maksama summa kertasumma 3000 3 000 Asiakkaan käyttämä oma aika 2 hlö * 3 h/vko * 17 vko * 30 /h 3 060 Projektiryhmän työ 1190 h, à 50 /h 59 500 Yhteensä 65 560 5. Työkäytännöt ja työkalut 5.1 Käytännöt Tässä luvussa kuvataan projektin aikana käytettävät työkäytännöt sekä tarvittavat työkalut. 5.1.1 Iteratiivinen kehitys Projektin aikana projektiryhmä käyttää iteratiivista kehitystä. Iteratiivisessa kehityksessä jokaista iteraatiota voisi ajatella minivesiputouksena. Jokainen vaihe alkaa iteraatiosuunnittelulla, jossa käydään läpi ne asiat jotka tulisi toteuttaa kyseisen iteraation aikana. Tämän jälkeen jatketaan vaatimusten keräyksellä ja vaatimusmäärittelyllä, jonka jälkeen päästään suunnittelemaan itse toteutusta ennen toteutusvaihetta. Toteusvaiheen jälkeen ohjemiston kaikki siihen asti tehdyt
toteutukset testataan, ei ainoastaan uudet lisäykset. Testauksen jälkeen valmistellaan iteraation palautus. Aiakkaalta saadaan palautetta jokaisen iteraation aluksi edellisen iteraation osalta. Tämän lisäksi jokaisen iteraation aikana, noin kahden viikon päästä iteraation alkamisesta, asiakkaalle järjestetään demo edistymisestä jossa asiakkaalla on hyvä mahdollisuus vaikuttaa kehityksen ja antaa palautetta aikaisessa vaiheessa jos jokin toteutus ei täytä asiakkaan asettamia vaatimuksia. 5.1.2 Iteraation suunnittelu Iteraation suunnittelu aloitetaan välittömästi iteraatiodemon jälkeen olevalla tapaamisella asiakkaan kanssa. Iteraatiosuunnitelma tehdään iteraation ensimmäisen viikon aikana ja se toimitetaan sekä asiakkaalle että mentorille. Asiakas hyväksyy suunnitelman tai ehdottaa siihen tehtävät muutokset esimerkiksi niissä tapauksissa jolloin jonkin ominaisuuden toteuttaminen priorisoidaan korkeammalle. Projektiryhmän johtoryhmä suunnittelee ajankäytön ja arvioi iteraation kuluvan ajan kunkin yksittäisen henkilön kohdalla ja esittää arvionsa asiakkaalle iteraatiosuunnitelman palautuksen yhteydessä. 5.1.3 Dokumentointi Jokainen ryhmän jäsen on vastuussa itse tuottamistaan dokumenteista, mutta päävastuu on projektipäälliköllä. Hän huolehtii siitä että odkumentit palautetaan ajoissa ja oikeassa muodossa. Dokumentteja palautetaan HTML ja PDF muodoissa. Projektiryhmän johtoryhmä käy läpi palautettavat dokumentit ennen palautusta ja korjaa niissä mahdollisesti olevia puutteita. Dokumentteja pidetään versionhallinnassa. Jokainen kehittäjä luo dokumentoinnin omasta työstään ja pääkehittäjä tarkastaa näin tuotetut dokumentit. 5.1.4 Riskien hallinta Riskit todennetaan aluksi sen mukaan mitä oletettavia ongelmia projektin edetessä saattaa ilmaantua. Lokia päivitetään tarpeen mukaan. 5.1.5 Tuntiraportointi Tuntiraportointiin ei käytetä erillistä työkalua. Jokainen ryhmän jäsen laskee viikon aikana käyttämänsä tunnit ja ilmoittaa ne viikon päätteeksi sunnuntaina tai maanantaina projektipäällikölle, joka päivittää tehdyt tunnit ryhmän www-sivuille. 5.1.6 Ohjelmiston koon määrittäminen
Ohjelmiston koko määritetään ensisijaisesti tuotettujen koodirivien määränä (LOC). Koodirivien määrästä ilmoitetaan myös todellinen arvo eli ne koodirivit jotka eivät ole kommentteja tai dokumentointia koodin sisällä. 5.1.7 Kommunikointi Kommunikointi ryhmän sisällä tapahtuu kurssin puolesta tarjottavan TikiWiki ohjelmiston avulla. Myös asiakkaalle ja mentorille annetaan pääsy kyseiseen ohjelmaan. Yleisluontoiseen, kaikkia koskevaan yhteydenpitoon käytetään sähköpostia. Ryhmän www-sivut toimivat myös kommuninkointi välineenä ryhmän sisällä. Tarvittaessa käytetään pikaviestiohjelmia kuten Messenger ja Miranda. 5.1.8 Iteraatiodemo Projektipäällikkö suunnittelee iteraatiodemoon otettavan materiaalin ja valmistelee esitettävän edistymisraportin iteraatiodemossa. Projektipäällikkö huolehtii iteraatiodemon pysymisestä aikataulussa ja toimii demon puheenjohtajana. Pääkehittäjä valmistelee ohjelman demoamisen ja suorittaa sen mahdollisesti yhdessä kyseisistä osista vastuussa olevien kehittäjien kanssa. 5.1.9 Vikojen seuranta Järjestelmän vikaraportointiin käytetään kurssin puolesta tarjolla olevaa Bugzilla -ohjelmistoa. 5.1.10 Versionhallinta Versionhallintaan käytettävä työkalu on CVS (Concurrent Versions System). CVS repositorio sijaitsee yhden projekryhmäläisen TKK:n ATK-keskuksen kotihakemistossa. Versionhallinnassa noudatetaan seuraavia käytäntöjä uuden version päivityksen yhteydessä kirjoitetaan lokiviesti, jossa kuvataan tehdyt muutokset dokumentit päivitetään vähintään päivän päätteeksi ja muutokset kirjataan myös dokumentin muutoshistoriaan koodin päivitetään versionhallintaan, kun ominaisuus on valmis. Vain kääntyvää ja toimivaa lähdekoodia saa päivittää repositorioon. versiot merkitään tagilla palautusten, käyttöönottojen ja järjestelmä- tai hyväksymistestaukseen otettavien versioiden yhteydessä 5.1.11 Koodauskäytäntö
Koodi kirjoitetaan Java -kielellä ja muotoillaan Sun:in koodauskäytännön mukaisesti, joka on saatavissa osoitteesta http://java.sun.com/docs/codeconv/. 5.1.12 Vertaistestaus Vertaistestausta aloitetaan sunnittelemaan välittömästi kun vertaistestausryhmät on vahvistettu. Pyrimme siihen että vertaistestausta suoritetaan jo ennen iteraation yksi palautusta tai ainakin iteraation kaksi alussa, jolloin ohjelmiston kehittämistä varten toisen iteraatiokierroksen aikana saadaan riittävän ajoissa arvokasta näkemystä täysin uudelta kantilta. Vertaistestauksen suunnittelu toteutetaan siten että molemmista ryhmistä testauksesta vastuussa olevat henkilöt tapaavaat muutaman kerran ennen varsinaista vertaistestauksen aloittamista, jotta itse testaus voidaan suorittaa ennalta suunniteltujen määrityksien mukaisesti. 5.1.13 Vaatimusten hallinta Vaatimukset projektin suhteen tulee ensisijaisesti asiakkaalta sillä he ovat myös tuotteen loppukäyttäjiä sen lisäksi että he ovat tuotteen tilaajia. Vaatimukset selvitetään asiakkaan ja projektiryhmän välisissä kokouksissa, joiden perusteella projektiryhmä esittelee vaatimusmäärittelyn asiakkaalle, joka hyväksyy määrittelyn tai ehdottaa korjauksia. Projektiryhmä voi myös ehdottaa asiakkaalle vaatimuksia joita ohjelmistolla tulee olla jotta sen toteuttaminen olisi esimerkiksi realistista. 5.1.14 Prototyyppi Asiakkaan pyynnöstä projektiryhmä aloittaa välittömästi ensimmäisen kehitysiteraatiovaiheen alussa käyttöliittymäprototyypin rakentamisen. Tämä prototyyppi demotaan asiakkaalle toisen kehitysviikon lopulla. 5.2 Laadunvarmistussuunnitelma 5.2.1 Projektitason aiheet 5.2.2 Iteraatiotason aiheet
5.3 Työkalut Versionhallinta Versionhallintaan käytetään CVS -ohjelmaa, jonka kanta on asennettu ATK-keskuksen kotihakemistoon. Ohjelmointi Ohjelmistokehitysympäristönä käytetään integroitua Eclipse -kehitysympäristöä. Vikaraportointi Järjestelmän vikaraportointiin käytetään kurssin puolesta tarjolla olevaa Bugzilla -ohjelmistoa. Kommunikointi Kommunikointi ryhmän sisällä tapahtuu kurssin puolesta tarjottavan TikiWiki ohjelmiston avulla. Yleisluontoiseen, kaikkia koskevaan yhteydenpitoon käytetään sähköpostia. Ryhmän www-sivut toimivat myös kommuninkointi välineenä ryhmän sisällä. Tarvittaessa käytetään pikaviestiohjelmia kuten Messenger ja Miranda. 6. Vaiheistus Projekti on jaettu kolmeen iteraatioon. Seuraavassa kuvataan niiden päätavoitteet, tuotettavat dokumentit ja muut tuotokset, tehtävät sekä työmääräarviot. Lisäksi projektin kannalta tärkeimmät päivämäärät on merkitty taulukkoon. Iteraatiot ja niiden aikataulut ovat kurssin määräämiä 6.1 Aikataulu Taulukko 6 sisältää projektin aikataulun ja tärkeimmät päivämäärät. Taulukko 6: Projektin aikataulu Pvm Tapahtuma PROJEKTIN SUUNNITTELU (27.9.- 20.10.2005) Pe 30.9 Ma 3.10 Ma 17.10. To 20.10 Ensimmäinen asiakastapaaminen DL 13:00 Iteraatiosuunnitelman palautus (projektisuunnitelman luvut 6.1 ja 6.2) sähköpostilla mentorille ja asiakkaalle DL 13:00 Vaiheen tuotosten palautus 14.00 (?) Iteraatiodemo TOTEUTUS 1 (21.10.- 8.12.2005) Ma 31.10. Ma 31.10. DL 13:00 Ryhmän lopullisen kokoonpanon ilmoittaminen opettajalle DL 13:00 Iteraatio- ja laadunvarmistussuunnitelman palautus plan (proj. suunn. luvut. 5.2. & 6.1 & 6.3) sähköpostilla mentorille ja asiakkaalle
Pe 4.11 Ma 5.12. Ke-To 7.- 8.12. käyttöliittymäprototyypin esittely asiakkaalle (tärkeimpien toiminnallisten vaatimusten osalta) DL 13:00 Vaiheen tuotosten palautus 8-19 Iteraatiodemo 9.12.-15.1. Joululoma TOTEUTUS 2 (16.1. - 2.3.2006) Ke 18.1. DL 13:00 Iteraatio- ja laadunvarmistussuunnitelman palautus plan (proj. suunn. luvut. 5.2.3 & 6.1 & 6.4) sähköpostilla mentorille ja asiakkaalle 1.-3.2. Demo asiakkaalle ja mentorille Pe 17.2. Ti 21.2. Ma 27.2. DL 13:00 Valmiin järjestelmän toimitus ja testausohjeet vertaisryhmälle DL 13:00 Vertaistestauksen tulosten raportointi vertaisryhmälle DL 13:00 Vaiheen tuotosten palautus Ke-To 1.-2.3. 8-19 Iteraatiodemo 6.2 Projektin suunnittelu (PP) Tavoitteet: projektin suunnittelu menetelmien ja työkalujen valinta asiakkaan toimintaympäristön ymmärtäminen vaatimusmäärittely yleisellä tasolla sisältäen tärkeimmät käyttötapaukset lopputulosten oikeuksista sopiminen käytettävien työkalujen sekä kehitysympäristön pystyttäminen Tuotokset: projektisuunnitelma (paitsi luku 5.2 Laadunvarmistussuunnitelma) vaatimusmäärittely (luvut 1-5, luvut 6-9 ainakin tärkeimpien vaatimusten osalta, luvut 11-12) edistymisraportti ohjeet menetelmien ja työkalujen käytöstä
Taulukko 7; tehtävät: Nimi Arvio Vastuuhlö Alku_pvm Loppu_pvm Tehty Ero Vaatimusmäärittely 30 stikkane 30.9.2005 17.10.2005 Työkalujen ja toimintaypäristön pystyttäminen 10 jkaupp2 1.10.2005 17.10.2005 Projektin tavoitteiden määrittely 20 MGM 30.9.2005 17.10.2005 Luennot 18 MGM 27.9.2005 17.10.2005 Ryhmätapaamiset 18 MGM 27.9.2005 Asiakastapaamiset 12 MGM 30.9.2005 17.10.2005 Mentortapaaminen 4 MGM 3.10.1005 17.10.2005 Iteraatiosuunnitelma 5 mjkekkon 3.10.2005 3.10.2005 Riskienhallinnan suunnitelma 5 MGM 3.10.2005 17.10.2005 Edistymisraportin tekeminen 4 mjkekkon 3.10.2005 17.10.2005 Projektisuunnitelman kirjoitus 20 mjkekkon 3.10.2005 17.10.2005 Yhteensä 150 MGM 27.9.2005 17.10.2005 *MGM = Management ryhmä, DEV = kehittäjät, ALL = kaikki 6.3 Toteutus 1 (I1) Tavoitteet: Tuotokset: Tehtävät: 6.4 Toteutus 2 (I2) Tavoitteet: Tuotokset: Tehtävät:
7. Riskiloki Taulukko 8: Riskilogi ID Riski Vaikutukset Hallintatoimenpiteet Vastuuhenkilö 1 2 3 4 Ryhmän jäsen keskeyttää Ryhmän jäsenten ajankäytölle on asetettu rajat etukäteen. Jokin proejktiryhmän jäsenistä sairastuu kriittisellä hetkellä ennen demoa / palautusta Tuotteen vaatimusmäärittely ei ole onnistunut Projektin kannalta tärkeää tietoa poistuu ryhmästä. Muut kuormittuvat, projektin laajuutta tulee vähentää. Aika loppuu kesken, eikä tuotetta saada aikarajojen puitteissa valmiiksi Tuotteen toiminnallisuus jää vajaaksi Koko projektin aikataulu siirtyy ja aika loppuu kesken Tulee ylläpitää hyvää yhteishenkeä ryhmän sisällä. Toteutuksen elintärkeät osaalueet tulee suorittaa pariohjelmointina. Tehtävät priorisoidaan, ja ensiksi toteutetaan tärkeimmät tehtävät Mitä lähempänä iteraation loppua ollaan, sitä useamman henkilön täytyy olla selvillä kehityksen kulusta Panostetaan suunnitteluun Koko projektiryhmä / projektipäällikkö projektipäällikkö projektipäällikkö manageriryhmä Lähdeluettelo [1] Test World Oy, http://www.testworld.fi/?sivu=testworld&kieli=fi, tarkistettu 11.10.2005