Ohjelmistotuotanto
Projektinhallinta

Projektinhallinta on läpileikkaava teema, joka kulkee koko ohjelmistokehitysprosessin läpi esitutkimuksesta ylläpitoon. Projektinhallinta varmistaa että ohjelmistoprojekti toteutetaan suunnitellusti, aikataulussa, budjetissa ja vaatimusten mukaisesti.

Ohjelmistoprojekti eroaa muista projekteista siinä, että lopputuote on abstrakti ja monimutkainen, vaatimukset voivat muuttua projektin aikana, ja teknologinen kehitys on nopeaa. Näistä syistä ohjelmistoprojektien hallintaan on kehitetty erityisiä menetelmiä ja käytäntöjä.

Projektinhallinnan osa-alueet

Projektinhallinta koostuu useista osa-alueista, jotka kaikki ovat tärkeitä projektin onnistumisen kannalta:

1. Laajuudenhallinta (Scope Management)

Laajuudenhallinta määrittelee mitä projektiin kuuluu ja mitä ei. Se sisältää vaatimusten määrittelyn, työn jakamisen osiin (WBS, Work Breakdown Structure) ja muutosten hallinnan. Laajuuden hallinta estää projektin laajentumisen hallitsemattomasti (scope creep).

2. Aikataulu- ja ajanhallinta

Aikatauluhallinta varmistaa että projekti valmistuu sovitussa ajassa. Se sisältää:

  • Tehtävien tunnistamisen ja määrittelyn
  • Tehtävien kestojen arvioinnin
  • Riippuvuuksien tunnistamisen
  • Aikataulun laatimisen (Gantt-kaaviot, verkkokuviot)
  • Kriittisen polun määrittämisen

3. Kustannushallinta

Kustannushallinta varmistaa että projekti pysyy budjetissa. Se sisältää:

  • Kustannusten arvioinnin
  • Budjetin laatimisen
  • Kustannusten seurannan ja kontrolloinnin
  • Resurssien hinnoittelun

4. Laatuhallinta

Laatuhallinta varmistaa että tuotettu ohjelmisto täyttää asetetut laatuvaatimukset. Se sisältää laatusuunnittelun, laadunvarmistuksen ja laadunvalvonnan. Laatustandardeja ovat esimerkiksi ISO 9001 ja CMMI (Capability Maturity Model Integration).

5. Resurssihallinta

Resurssihallinta varmistaa että projektilla on käytössään tarvittavat resurssit oikeaan aikaan. Resursseja ovat henkilöstö, laitteet, työkalut ja tilat. Resurssihallinta sisältää resurssisuunnittelun, resurssien hankinnan ja resurssien tasapainotuksen.

6. Riskienhallinta

Riskienhallinta tunnistaa ja hallitsee projektiin liittyviä riskejä. Prosessi sisältää:

  1. Riskien tunnistaminen
  2. Riskien analysointi (todennäköisyys ja vaikutus)
  3. Riskien priorisointi
  4. Riskienhallintasuunnitelman laatiminen
  5. Riskien seuranta

7. Viestintähallinta

Viestintähallinta varmistaa että tieto kulkee tehokkaasti projektin sisällä ja sidosryhmien välillä. Se sisältää viestintäsuunnitelman laatimisen, säännölliset palaverit, raportointikäytännöt ja dokumentaation jakamisen.

Ohjelmistokehityksen mallit ja menetelmät

Ohjelmistokehitystä voidaan suunnitella ja ohjata erilaisilla malleilla ja menetelmillä. Sopiva lähestymistapa riippuu projektin tarpeista.

Vesiputousmalli (Waterfall)

Vesiputousmalli on perinteinen, peräkkäinen prosessimalli, jossa projekti etenee vaihe vaiheelta: esitutkimus → määrittely → suunnittelu → toteutus → testaus → käyttöönotto → ylläpito. Vaiheet suunnitellaan eteneviksi järjestyksessä. Aiempaan vaiheeseen palaaminen voi olla tarpeen, mutta se on usein työlästä.

Vesiputousmallin vaiheet etenevät esitutkimuksesta määrittelyn, suunnittelun, toteutuksen, testauksen ja käyttöönoton kautta ylläpitoon. Nuolet osoittavat vain eteenpäin.
Vesiputousmallin vaiheittainen eteneminen

Vesiputousmallin edut:

  • Selkeä rakenne ja vaiheistus
  • Helppo hallita ja seurata
  • Hyvä dokumentaatio
  • Sopii projekteihin, joissa vaatimukset ovat vakaat

Vesiputousmallin haitat:

  • Jäykkä, vaikea muuttaa suuntaa
  • Asiakas näkee tuotteen vasta lopussa
  • Riskit voivat realisoitua myöhään
  • Ei sovellu projekteihin, joissa vaatimukset muuttuvat

Ketterät menetelmät (Agile)

Ketterät menetelmät ovat iteratiivisia ja inkrementaalisia lähestymistapoja, jotka korostavat joustavuutta, asiakasyhteistyötä ja nopeaa reagointia muutoksiin. Ketterät menetelmät perustuvat Agile Manifestoon (2001), joka määrittelee neljä perusarvoa:

  • Yksilöt ja vuorovaikutus ennen prosesseja ja työkaluja
  • Toimiva ohjelmisto ennen kattavaa dokumentaatiota
  • Asiakasyhteistyö ennen sopimusneuvotteluja
  • Reagointi muutokseen ennen suunnitelman seuraamista

Miksi ketteriä menetelmiä kehitettiin?

Ketteriä menetelmiä kehitettiin vastaukseksi perinteisten, tarkasti etukäteen suunniteltujen ohjelmistoprojektien ongelmiin. Pitkissä projekteissa asiakkaiden tarpeet, liiketoimintaympäristö ja käytettävä teknologia ehtivät usein muuttua ennen kuin ohjelmisto valmistui. Jos valmis tuote esiteltiin asiakkaalle vasta projektin lopussa, väärin ymmärretyt vaatimukset ja muut virheet saattoivat tulla esiin hyvin myöhään, jolloin niiden korjaaminen oli kallista ja hidasta.

Ketterissä menetelmissä ohjelmistoa toteutetaan pienissä osissa ja siitä pyydetään palautetta säännöllisesti. Näin tärkeimmät ominaisuudet voidaan toimittaa aikaisemmin, muutoksiin voidaan reagoida hallitusti ja ongelmat havaitaan nopeammin. Menetelmät on otettu laajasti käyttöön erityisesti siksi, että ne parantavat asiakkaan ja kehitystiimin yhteistyötä, tekevät työn etenemisen näkyväksi ja pienentävät riskiä rakentaa pitkään vääränlaista tuotetta.

Mitä ketteryys ei tarkoita?

Ketteryyttä ei pidä ymmärtää niin, ettei ohjelmistoa tarvitse määritellä, suunnitella tai dokumentoida. Näitä asioita tehdään edelleen, mutta sopivassa laajuudessa ja usein vaiheittain projektin edetessä. Esimerkiksi vaatimuksia voidaan kuvata käyttäjätarinoina ja hyväksymiskriteereinä, arkkitehtuuria suunnitella ennen toteutusta ja sen aikana sekä olennaiset ratkaisut, rajapinnat ja käyttöohjeet dokumentoida.

Agile Manifeston ilmaus "ennen" ei tarkoita, että jälkimmäinen asia olisi arvoton. Prosesseilla, työkaluilla, dokumentaatiolla, sopimuksilla ja suunnitelmilla on paikkansa, mutta niiden tulee tukea toimivan ja asiakkaalle hyödyllisen ohjelmiston tuottamista. Ketteryys ei myöskään tarkoita suunnittelemattomuutta, jatkuvaa tavoitteiden vaihtamista tai sitä, että laatuvaatimuksista ja sovituista vastuista voitaisiin luopua.

Seuraavaksi esitellään kolme yleisesti käytettyä ketterää lähestymistapaa: Scrum, Kanban ja Extreme Programming (XP).

Scrum

Scrumissa kehitystyö jaetaan lyhyisiin, ennalta sovitun mittaisiin jaksoihin eli sprintteihin. Kussakin sprintissä toteutetaan sovittu kokonaisuus, jonka tulosta arvioidaan jakson lopussa.

Kanban

Kanbanissa työ etenee jatkuvana virtana ilman sprinttejä. Tehtävien eteneminen tehdään näkyväksi Kanban-taululla, ja keskeneräisen työn määrää rajoitetaan, jotta tehtävät valmistuvat tasaisesti.

Extreme Programming (XP)

XP painottaa ohjelmiston laatua ja nopeaa palautetta kehitystyön aikana. Sen ytimessä ovat tekniset työtavat, kuten jatkuva testaaminen, pariohjelmointi ja koodin säännöllinen parantaminen.

Projektinhallinnan työkalut

Projektinhallintaan on saatavilla lukuisia työkaluja, jotka helpottavat suunnittelua, seurantaa ja yhteistyötä:

  • Jira - Suosittu työkalu ketteriin projekteihin, tukee Scrumia ja Kanbania
  • Trello - Yksinkertainen Kanban-pohjainen työkalu
  • Asana - Tehtävienhallinta ja projektisuunnittelu
  • Microsoft Project - Perinteinen projektinhallintaohjelmisto aikatauluille
  • GitLab/GitHub Projects - Integroitu projektinhallinta versionhallinnan kanssa
  • Azure DevOps - Microsoftin kattava DevOps-alusta
  • Slack/Teams - Viestintä ja yhteistyö
Projektin onnistumisen mittaaminen

Projektin onnistumista mitataan useilla kriteereillä:

  • Aikataulu - Valmistuiko projekti ajallaan?
  • Budjetti - Pysyikö projekti budjetissa?
  • Laatu - Täyttääkö tuote laatuvaatimukset?
  • Laajuus - Toteutuivatko kaikki sovitut ominaisuudet?
  • Asiakastyytyväisyys - Onko asiakas tyytyväinen lopputulokseen?
  • Tiimin tyytyväisyys - Olivatko työolosuhteet hyväksyttävät?

Projektin päätteeksi järjestetään usein projektin päätöspalaveri (post-mortem, lessons learned), jossa arvioidaan mitä onnistui ja mitä voisi parantaa seuraavissa projekteissa.



Toggle Menu