Ohjelmistotuotanto, projektinhallinta Syksy Miksi ohjelmistoprojektin hallinta on erilaista? 3. Projektinhallinta

Transkriptio

1 3. Projektinhallinta ohjelmistoprojektien koon kasvaessa on törmätty projektinhallinnan ongelmiin: jatkuva, osin huonosti hallittu kasvu myöhästymiset huono laatu budjettien ylitykset projektien epäonnistumiset muissa insinööritieteissä käytetyt projektinhallinnan menetelmät eivät tunnu toimivan Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 1 Miksi ohjelmistoprojektin hallinta on erilaista? tuotteen erityisluonne: tuote ei ole samalla tavoin konkreettinen kuin insinöörityön tuotteet yleensä työprosessit eivät ole vakiintuneita: lyhyt historia, vähän kokemusta, työtavat jatkuvassa muutostilassa jokainen projekti on erilainen: jokaiselle tuotteelle on omat (prosessiin vaikuttavat) vaatimuksensa usein ei ole sopivia vertailukohtia Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo Projektinhallinnan tehtävät Tehtäväkuvauksen laatiminen tehtäväkuvauksen (tarjouksen) laatiminen projektisuunnitelman laatiminen ja ylläpito projektin aikataulun laatiminen ja ylläpito projektin kustannusten arviointi ja seuranta projektin seuranta ja tarkastukset työntekijöiden valinta ja arviointi raportointi ja projektin esittely käsitellään myöhemmin usein projekti täytyy myydä asiakkaalle tai esimiehille laatimalla tarjous: mitä projektissa luvataan tehdä projektin kustannus- ja aikatauluarviot miksi juuri meidän pitäisi saada tämä projekti hyvien projektitarjousten laatiminen voi ratkaista yrityksen koko liiketoiminnan: saadaanko sopimus riittääkö yrityksellä töitä = hyviä projekteja Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 3 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 4 Projektin seuranta projektin etenemistä seurataan koko ajan seuranta = verrataan suunnitelmia toteutuneeseen aikataulu: työvaiheiden eteneminen kustannukset: jakautuminen ja kokonaiskertymä seurannan keinot: seurantatyökalut keskustelut projektiryhmän jäsenten kanssa mitä tehdään jos alkaa näyttää huonolta? ongelmat on tärkeää havaita ajoissa Raportointi ja esittely projektin raportointi eri vaiheissa asiakkaille esimiehille kirjalliset ja suulliset raportit mikä on työn vaihe esitettävä asiat kuulijoiden tuntemalla terminologialla kommunikointitaito on tärkeä! Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 5 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 6 Taina, Verkamo 1

2 3.2 Projektin suunnittelu projektin suunnittelun keskeinen apuväline on projektisuunnitelma laaditaan ennen varsinaisia projektin työvaiheita päivitetään ja täydennetään tarvittaessa projektin aikana projektisuunnitelman tarkoitus: projektin etenemisen seuranta antaa mahdollisuudet saada projekti valmiiksi ajoissa antaa keinot huomata aikataulusta lipsumiset mahdollisimman pian Projektin seurannan vaiheet 1. Selvitetään projektin rajat (aika, henkilöt, budjetti). 2. Selvitetään projektin lähtötilanne (parametrit). 3. Määritellään projektin tarkistuspisteet ja tuotokset. 4. Toistetaan vaiheita 5-12, kunnes projekti päättyy tai keskeytetään: 5. Tehdään aikataulu. 6. Sijoitetaan tehtävät ja henkilöt aikatauluun. 7. Projektiryhmä toimii suunnitelman mukaan. 8. Tarkistetaan eteneminen. 9. Muutetaan tarvittaessa projektin parametreja. 10. Päivitetään tarvittaessa aikataulua. 11. Neuvotellaan tarvittaessa päivityksistä projektin rajoihin ja tuotoksiin. 12. Jos ilmenee ongelmia, tarkastetaan prosessi ja tarvittaessa korjataan projektisuunnitelmaa. Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 7 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 8 Projektisuunnitelman sisältö välttämättömät tiedot: projektin työvaiheet projektin tehtävät projektin aikataulu lisäksi (samassa tai eri dokumenteissa) voi olla myös: laaduntarkkailusuunnitelma validointisuunnitelma versionhallintasuunnitelma ylläpitosuunnitelma koulutussuunnitelma Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 9 Projektisuunnitelman muutokset suunnitelmaa päivitetään koko projektin ajan: muutoksia tulee varmasti jotkut osat saattavat muuttua usein (esim. aikataulu, työnjako) mieluummin väljä kuin tiukka suunnitelma päivityksen oltava suoraviivaista kannattaa erottaa dokumentin pysyvämmät ja muuttuvammat osat Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 10 Projektisuunnitelman osat 1.Johdanto 2.Projektiorganisaatio 3.Riskianalyysi 4.Laitteisto- ja ohjelmistovaatimukset 5.Työn ositus 6.Projektin aikataulu 7.Seuranta- ja raportointitavat Projektisuunnitelman osat (jatkuu) johdanto = projektin raamit projektin tavoitteet ylärajat budjetille, ajoitukselle, resursseille ym. projektiorganisaatio osallistujat ja heidän roolinsa osallistujien erityistaidot riskianalyysi projektin riskit riskien todennäköisyys ja vakavuus riskien ratkaisustrategia Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 11 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 12 Taina, Verkamo 2

3 Projektisuunnitelman osat (jatkuu) laitteisto- ja ohjelmistovaatimukset tarvittavat laitteisto- ja ohjelmistokomponentit uusien komponenttien kustannusarvio työn ositus toiminnot, tarkistuspisteet ja tuotokset aikataulu toimintojen väliset riippuvuudet tarkistuspisteiden vaatimat ajat henkilöiden työnjako seuranta- ja raportointitavat 3.3 Riskienhallinta projektin valmistuminen pyritään takaamaan myös tilanteissa, joissa tapahtuu jotakin eitoivottua onnistumista uhkaavien riskien tunnistaminen tunnistettujen riskien analysointi toteutumisen todennäköisyys toteutumisen vaikutukset vastatoimien suunnittelu riskien seuranta projektin aikana riskienhallinnan ylläpito Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 13 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 14 Mikä on riski? Riskienhallintaprosessi tapahtuma joka on mahdollinen (todennäköisyys >0 mutta <1) todennäköisyys = 0: mahdoton tapahtuma todennäköisyys = 1: ei riski vaan rajoitus toteutuessaan vahingoittaa projektia voi olla projektikohtainen vaikuttaa aikatauluun tai käytössä oleviin resursseihin tuotekohtainen vaikuttaa kehitettävän tuotteen laatuun yrityskohtainen vaikuttaa (tekijä- tai asiakas-)organisaatioon Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 15 Risk identification List of potential risks Risk analysis Prioritised risk list Risk planning Risk avoidance and contingency plans Risk monitoring Risk assessment Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 16 Riskien tunnistus pyritään löytämään kaikki riskit, jotka voivat vaikuttaa projektin onnistumiseen käytännössä unohdetaan kovin epätodennäköiset ja merkityksettömät riskit riskit voivat liittyä esimerkkejä käytettyyn teknologiaan tietokannan suorituskyky henkilökuntaan henkilöstön vaihtuvuus organisaatioon organisaation muutokset käytettyihin työkaluihin tehottomat työkalut vaatimuksiin suuret muutokset kustannusten ja aikataulun arviointiin virhearviot Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 17 Riskien analysointi mietitään kunkin riskin todennäköisyys ja vakavuus: todennäköisyys = miten varmasti riski toteutuu prosentteina tai luokiteltuna (esim. viisi luokkaa vähäisestä erittäin todennäköiseen) vakavuus = miten merkittävä riski on projektille tuhoisa, vakava, siedettävä vai vähäpätöinen päätetään, miten riskeihin varaudutaan mitkä riskit otetaan huomioon suunnitelmissa yleensä on syytä ottaa huomioon ainakin kaikki tuhoisat ja kohtalaisen todennäköiset vakavat riskit Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 18 Taina, Verkamo 3

4 Riskien vastatoimet jokaiselle valitulle riskille suunnitellaan vastatoimet = mitä tehdään jos riski toteutuu vastatoimet voivat olla riskin välttämistä: pienennetään toteutumisen todennäköisyyttä vaikutusten minimointia: vähennetään toteutumisen haittavaikutuksia jatkosuunnitelmia: mietitään toimintatapoja, joita voidaan seurata, jos riski toteutuu Riskien seuranta riskien toteutumista seurataan koko projektin elinkaaren ajan riskin toteutuessa ryhdytään suunnitelmien mukaisiin toimenpiteisiin projektisuunnitelmaa voidaan joutua päivittämään: projektin kuluessa ilmenee uusia riskejä jonkin tunnistetun riskin todennäköisyys tai vakavuus muuttuu jokin sellainen riski toteutuu, jota varten ei ole suunniteltu vastatoimia Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 19 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo Projektin aikataulutus Aikataulun laatiminen projektin tarkistuspiste (milestone) kukin tarkistuspiste on jonkin työvaiheen (perustoiminnon) lopussa tarkistuspisteiden avulla seurataan projektin pysymistä aikataulussa projektin tuotos (deliverable) projektista saatava asiakkaalle merkittävä tulos esim. vaatimusdokumentti kaikkiin tarkistuspisteisiin ei liity tuotoksia 1. jaetaan projekti perustoimintoihin 2. arvioidaan kunkin perustoiminnon kesto 3. selvitetään perustoimintojen riippuvuudet 4. selvitetään, mihin perustoimintoon kukin tuotos tai tarkistuspiste liittyy perustoiminto joka tuottaa tuotoksen perustoiminto jonka päättyminen = tarkistuspiste 5. yhdistetään perustoiminnot toimintoverkoksi (activity network) Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 21 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 22 Toimintoverkko toimintoverkko kuvaa perustoimintojen järjestyksen ja aikataulun yleensä projektissa on eräitä tarkistuspisteitä, jossa kaikki käynnissä olevat perustehtävät yhtyvät samalle projektille voi tehdä useita erilaisia toimintoverkkoja yleensä projektipäällikkö tekee toimintoverkon lopputulokseen vaikuttaa mm. varautuminen riskeihin Toimintoverkko tehtävien keskinäiset riippuvuudet joitakin tehtäviä ei voida aloittaa, ennen kuin eräät muut tehtävät on saatu päätökseen riippuvuudet on otettava huomioon toimintoverkossa tehtävien rinnakkaisuus toisistaan riippumattomia tehtäviä voidaan hoitaa samanaikaisesti rinnakkaisuuden määrä riippuu resursseista rinnakkaisuus nopeuttaa projektia, mutta lisää aikataulun laadinnan vaatimaa työtä Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 23 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 24 Taina, Verkamo 4

5 Kriittinen polku koostuu tehtävistä, jotka on saatava valmiiksi aikataulun mukaan, jotta projekti ei myöhästy jokaisella perustoiminnolla on aikaisin ajankohta, jolloin se voi alkaa myöhäisin ajankohta, jolloin sen täytyy alkaa aikaisin mahdollinen lopetusaika myöhäisin mahdollinen lopetusaika joustovara, joka riippuu tehtävästä ja kriittisestä polusta ajoituskaavio sisältää kaikki perustoiminnot kestoaikoineen ja tarkistuspisteet Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 25 Ohjeita aikataulun laatimiseen suuressa projektissa voi laatia ajoituskaavion kullekin isommalle työvaiheelle erikseen muistettava näiden väliset riippuvuudet pienemmissä projekteissa riittää yksi yhteinen ajoituskaavio valittava sopiva rakeisuus: liian hieno jaottelu: suunnittelun ja seurannan vaatima työmäärä on suuri liian karkea jaottelu: poikkeamia ei havaita ajoissa pienimmät perustehtävät ~ 1-2 viikkoa suurimmat perustehtävät ~ 8-10 viikkoa Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 26 Tehtävien kestot ja riippuvuudet Task Duration (days) Dependencies T1 8 T2 15 T3 15 T1 (M1) T4 10 T5 10 T2, T4 (M2) T6 5 T1, T2 (M3) T7 20 T1 (M1) T8 25 T4 (M5) T9 15 T3, T6 (M4) T10 15 T5, T7 (M7) T11 7 T9 (M6) T12 10 T11 (M8) Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 27 4/7/99 start 10 days T4 8 days T1 15 days T2 Toimintoverkko 18/7/99 M5 14/7/99 15 days 25/7/99 M3 25/7/99 M2 M1 T7 T3 5 days T6 20 days 10 days T5 25 days Finish Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 28 T8 4/8/99 M4 11/8/99 M7 15 days T9 15 days T10 25/8/99 M6 19/9/99 T11 10 days 7 days 5/9/99 M8 T12 kriittinen polku Ajoituskaavio 4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9 Start T4 T1 T2 M1 T7 T3 M5 T8 M3 M2 T6 T5 M4 T9 M7 T10 M6 T11 M8 T12 Finish Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo Kustannusten arviointi yleensä jo projektin tarjouksen osana on jonkinlainen kustannusarvio projektin tärkeimmät kustannustekijät: laitteisto- ja ohjelmistokulut matkat ja koulutus työvoimakustannukset palkat työtilat sosiaalikulut merkittävin kustannustekijä Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 30 Taina, Verkamo 5

6 Kustannusten arvioinnin ongelma kustannusarvio joudutaan laatimaan aikaisin tarvitaan neuvoteltaessa tarjouksesta liian korkea arvio: projektia ei saada liian matala arvio: projekti ei valmistu budjetin puitteissa mutta: kokonaistyöpanoksen tarve riippuu olennaisesti laadittavasta ohjelmatuotteesta minkälaisista osajärjestelmistä tuote koostuu? minkälaista ammattitaitoa tekijöiltä edellytetään? kuinka paljon työtä kuinka kauan työ kestää? Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 31 Tuottavuus teollisuudessa kustannusten arviointi perustuu yleensä tuottavuuteen: kuinka paljon valmiita tuotteita tuotantolinjalta valmistuu aikayksikössä tuottavuus = tuotoksen määrä/työpanos mikä on tuottavuus ohjelmistotyössä? tuotos = ohjelmatuote työpanos = henkilötyö millä näiden määrää mitataan? Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 32 Tuotos ja työpanos ohjelmistotyössä Kustannusten arviointitekniikoita työpanosta voidaan mitata käytetyllä työajalla vaikuttaa kohtalaisen suoraviivaisesti kustannuksiin (palkat, tilakustannukset) millä tuotoksen määrää voidaan mitata? ohjelmatuotteen fyysinen koko ohjelmatuotteen sisältämän toiminnallisuuden määrä kustannusmallit kerätään tietoa aiemmista projekteista kuvataan eri tekijöiden väliset riippuvuudet mallina asiantuntija-arviot sovellusalueen ja ohjelmistotekniikan asiantuntijat arvioivat työmäärän analogiaan perustuva arviointi perustuu aiempiin samantapaisiin projekteihin Parkinsonin laki arvio = käytettävissä olevien resurssien kokonaismäärä kilpailuun perustuva arviointi Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 33 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 34 Kustannusmallit: kokoon perustuva arviointi tavallisin koon mitta: koodirivien määrä ohjelmatuote koostuu toimivasta koodista iso tuote = paljon koodia helposti mitattavissa jälkeenpäin ongelmia: koodin laatiminen on vain osa työstä eri ohjelmointikielissä koodirivin merkitys on erilainen: erilainen tuottavuus? koodirivejä ei voida laskea alkuvaiheessa COCOMO ohjelmatuotteen kokoon perustuva kustannusten arviointimalli perustuu projekteista kerättyyn dataan ensimmäinen versio vuonna 1981 vesiputousmallin mukainen prosessi kokonaan uutta koodia kokomittana koodirivit uudempi versio (COCOMO 2, 1995) mm. prototyypit, komponentit, uudelleenkäyttö erilaiset kokomitat elinkaaren eri vaiheissa Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 35 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 36 Taina, Verkamo 6

7 COCOMO 2 prototyypitysvaihe: koko: suunnitteluelementtien määrä effort = size * (1-reuse%) / productivity korkean tason suunnittelun vaihe: koko: toiminnoista arvioitavat koodirivit effort = A* size B * M yksityiskohtaisen suunnittelun vaihe: koko: koodirivien määrä vastaava kaava kuin edellisellä tasolla, mutta kokoarvioon vaikuttavat myös vaatimusten muuttuvuus ja uudelleenkäytön määrä kuvaa projektin erityisominaisuuksia Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 37 COCOMO-mallin korjaustekijät eri vaiheissa erilaisia korjaustekijöitä korjaustekijät liittyvät tuotteeseen: mm. luotettavuusvaatimukset, monimutkaisuus, dokumentaatiovaatimukset laitteistoon: mm. työympäristön muutokset, aika- ja muistivaatimukset henkilöstöön: mm. ryhmän taidot ja kokemus projektiin: mm. työkalut vaikuttavat lopputulokseen kertoimina tai eksponentteina empiirinen: arvot perustuvat kerättyyn aineistoon Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 38 Kustannusmallit: toiminnallisuuteen perustuva arviointi koon arviointi voidaan perustaa tuotteen sisältämän toiminnallisuuden määrään riippumaton ohjelmointikielestä kuvaa ehkä paremmin käyttäjän kokemaa tuotteen toiminnallista kokoa voidaan määrittää jo aikaisemmassa vaiheessa = heti kun tiedetään mitä toimintoja tuotteen pitäisi sisältää Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 39 Toimintopistemenetelmä mitta: toimintopisteet (function points, FP) lähtökohtana korkean tason suunnitelmasta laskettavat toiminnallisuutta kuvaavat alkiot UFC = Σ (alkioiden lukumäärä) * painokerroin peruskokoarvio syötteet, tulosteet, kyselyt, ulkoiset liittymät, tiedostot FP = UFC * ( * Σ F i ) painotettu kokoarvio kokonaislukuarvo riippuu tyypistä kokonaislukuarvoiset (0-5) kompleksisuuskertoimet (14 kpl) Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo Henkilöhallinto Projektiin osallistuvat henkilöt mitä ohjelmistojen tekeminen on: teknistä työtä henkilötyötä henkilökunta: yrityksen tärkein voimavara oikeat henkilöt oikeissa tehtävissä menestys (yksikin) väärä henkilö väärässä tehtävässä kaaos korostetaan usein liikaa projektin tekijät = projektiryhmä konkreettinen ohjelmistotyö projektipäällikkö projektin päävastuuhenkilö pitää projektin langat käsissään = tietää missä mennään projektin johtoryhmä johtoryhmä seuraa projektin etenemistä projektiin liittyvien eturyhmien edustajat asiakkaat, esimiehet, viranomaiset muita osallistujia: ulkopuoliset asiantuntijat markkinointi Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 41 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 42 Taina, Verkamo 7

8 Projektipäällikön tehtävät tehtävät vaihtelevat yrityksestä ja projektista riippuen (pää)vastuu mm. seuraavista asioista: henkilöiden valinta tehtäviin koulutus suoritusten seuranta urakehitys palkkaus hyvitysperiaatteet työnkuva ryhmätyön kehittäminen Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 43 Projektipäällikön edellytykset mitä taitoja projektipäälliköltä vaaditaan: ongelmanratkaisukykyä johtamistaitoa kannustuskykyä psykologista silmää siis: ei tarvitse olla etevä koodaaja, mutta täytyy tietää, mistä ohjelmistotyössä on kysymys tietää milloin ei tiedä tietää kuka tietää Peter s principle: In an organization, each person rises to the level of his own incompetence. Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 44 Miten ohjelmia tehdään? Ihmisen muisti vaikuttavia tekijöitä joista on hyvä olla selvillä: ihmisen ajatteluprosessi ohjelmointityön luonne työtä tekevää yhteisöä säätelevät sosiaaliset tekijät käytännön olosuhteet kolmitasoinen hierarkia: nopea lyhytkestoinen muisti tietojen syöttö ja alkukäsittely tilaa vain noin 7 alkiolle työmuisti tiedon pitkäaikaisempi käsittely hitaampi pitkäkestoinen muisti pysyvä talletus mutta tieto ei aina löydy! vrt. tietokoneen muistijärjestelmä Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 45 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 46 Muistin erityispiirteitä Ongelmanratkaisu muistiyksikön koko tieto jää mieleen kokonaisuuksina: syöte täytyy hahmottaa jotta se säilyisi semanttinen tieto kertyy asiayhteyden ja kokemuksen kautta ymmärrys syntaktinen tieto kertyy opettelemalla ja painamalla muistiin yksityiskohdat Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 47 vaikein osa tehtävästä on ongelmanratkaisua Problem Partial solutions New knowledge Existing knowledge Long-term memory Solution Working memory yhdistettävä eri alueiden asiantuntemusta: sovellusalue tietotekniikka hallinto Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 48 Taina, Verkamo 8

9 Henkilöstön motivointi ihmisten erilaiset tarpeet Selfrealization needs Esteem needs Social needs Safety needs Physiological needs Kolme ylintä kerrosta ovat keskeisiä. luovuus myönteinen palaute ryhmätyö Erilaiset työntekijät motivointi (Bass, Dunteman): tehtävä motivoi oma menestys motivoi vuorovaikutus motivoi persoonallisuustyypit (Myers, Briggs): ulospäin- vai sisäänpäinsuuntautunut (E / I) aistihavaintoihin vai intuitioon perustuva (S / N) harkitseva vai emotionaalinen (T / F) suunnitelmallinen vai sopeutuva (J / P) ja monia muita luokitteluja Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 49 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 50 Projektiryhmä projektityö on ryhmätyötä ryhmän koko: toimiva yksikkö tyypillisesti 2-8 henkeä laajemmat ryhmät jaetaan (tai jakautuvat) osiin hierarkkiset ryhmät yhteistyön kannalta paras sopiva sekoitus taidoiltaan ja luonteenominaisuuksiltaan erilaisia ihmisiä suuri joukko samanlaisia ei välttämättä ole hyvä Ryhmän koheesio (kiinteys) koheesio = hyvin yhteen toimivaa ryhmää koossapitävä voima = ryhmäfiilis etuja: yhteiset laatuvaatimukset (ryhmän standardit) yhteistyökyky oppiminen toisilta kyky jatkaa / täydentää toisten työtä yhteinen työ egoless programming vrt XP Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 51 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 52 Kiinteän ryhmän ongelmia ryhmä voi olla myös liian kiinteä torjuva suhtautuminen ulkopuolisiin esim. johtajan vaihtuessa uuteen, ryhmän ulkopuolelta tulevaan NIH = not invented here syndrooma ryhmäharha (groupthink) liiallinen lojaalisuus ryhmän sisällä enemmistöpäätökset silloinkin, kun pitäisi käyttää itsenäistä harkintaa Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 53 Ryhmän jäsenten kommunikointi vaikuttavia tekijöitä: ryhmän koko koon kasvaessa kommunikointi kasvaa 2! liian suuri ryhmä ei pysty keskustelemaan ryhmän rakenne tiukka hierarkkisuus haittaa avointa keskustelua ryhmän jäsenten luonteet henkilökemia työtilat Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 54 Taina, Verkamo 9

10 Projektiryhmän rakenne Pääohjelmoijaryhmä keskitetty projektipäällikkö hoitaa keskitetysti koko projektin hallinnan kullakin jäsenellä selkeät tehtävät kommunikointi projektipäällikön kautta Useimmiten jokin välimuoto hajautettu äärimmillään ryhmällä ei ole lainkaan johtajaa kullakin tehtävällä vastuuhenkilö kommunikointi ryhmän sisällä voi olla myös hajautettu useisiin itsenäisiin ryhmiin Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 55 Specialist pool Administrator Toolsmith OS specialist Tech. author Test specialist Nucleus of chief programmer team Chief programmer Librarian Backup programmer Outside Communication vastaa kokonaissuunnittelusta, jakaa tehtävät muille Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 56 Roolit usein työryhmässä on tarpeen jakaa nimettyjä osatehtäviä tai rooleja vrt. pääohjelmoijaryhmän asiantuntijat esimerkkejä osatehtävistä: työkalut tiedostojärjestelmän ylläpito kokousten sihteeri tietyn dokumentin päävastuu Työntekijöiden valinta valinnassa huomioon otettavaa: sovellusalueen tuntemus laitteistoalustan tuntemus ohjelmointikielen tuntemus koulutustaso kommunikointitaidot sopeutuvuus (kokemusten vaihtelevuus) työasenne persoonallisuus vaikeasti arvioitavissa Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 57 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 58 Työntekijöiden valintaan liittyviä ongelmia työntekijät ovat projektin onnistumisen kriittisin tekijä ja myös suurin kustannustekijä huonot valinnat tulevat kalliiksi taitotasovaatimukset ovat suuret usein ei ole tarjolla riittävän paljon hyviä ja kokeneita tekijöitä alan nopea muuttuminen aiheuttaa ongelmia sovellusalueasiantuntemusta ei aina ole olemassa ammattitaidon kehittäminen Työtilat yhteinen avoin työtila vai erilliset työhuoneet? tutkimustuloksia on kumpaankin suuntaan erilliset työhuoneet: työrauha oma persoonallinen työympäristö yhteinen työtila: helpompi järjestää spontaaneja neuvotteluja helpompi kysyä, hakea apua jatkuva tuntuma toisten tekemisiin (yhteinen työ) Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 59 Syksy 2004 Ohjelmistotuotanto / Taina, Verkamo 60 Taina, Verkamo 10