HOHTO Henkilöstön osaamisen hallinnan työkalu

Transkriptio

1 Tampere University of Technology Department of Pervasive Computing TIE Project Work on Pervasive Systems Mahtirojekti (4) HOHTO Henkilöstön osaamisen hallinnan työkalu Loppudokumentti v1.1 Jussi Tuurinkoski: Taina Peltonen: Juho Teperi: Oskari Ruutiainen: Niko Junkala:

2 Versiohistoria Versio 1.1 Päivämäärä Tekijä Tuurinkoski Kuvaus Statistiikan korjausta Tuurinkoski Oikoluku ja korjaukset Tuurinkoski Kappaleet 1, 2, 4, 5, Ruutiainen Kappale Peltonen Kappaleet 6, 7, 8, Tensu Header and footer finetuned Outi S-K Tables finalized Outi S-K Revisions Outi S-K First draft 2/27

3 Sisällys Määritelmät ja lyhenteet Johdanto Projektiorganisaatio Mahtirojekti-ryhmä Asiakas Kurssihenkilökunta Tuote Tarkoitus Ympäristö Kolmannen osapuolen komponentit ja lisenssit Rajoitteet Toimitettava tuote Oikeudet Projektinhallinta Kommunikointi Prosessin kuvaus Tavat ja työkalut Motivaatioruiskeet Tuntikirjaukset Riskit ja ongelmat Riskit, joihin oli valmistauduttu Riskit, joihin ei ollut valmistauduttu Hylätyt ajatukset ja jatkokehitys Hylätyt ajatukset Jatkokehitys Opitut asiat Kokemukset Kehitettävää Yhteenveto Kommentit kurssista Hyvät asiat Kehitettävää ja huonoja puolia Statistics Viitteet Liitteet /27

4 Määritelmät ja lyhenteet HOHTO Aiemmin HOHT-projektinimestä (henkilöstön osaamisen hallinnan työkalu) sittemmin johdettu toimitettavan tuotteen virallinen julkistusnimi 4/27

5 1 Johdanto Tämän loppuraportin tarkoitus on antaa lukijalle kokonaiskuva projektin etenemisestä määrittelyvaiheen alusta aina tuotteen loppuun saattamiseen saakka. Aikataulu- ja resursointisyistä tämä raportti tullaan luovuttamaan kurssihenkilökunnalle ja julkaisemaan projektiryhmän sivuilla ennen varsinaista tuotantoon vientiä ja käyttöönottoa. Dokumentti on suunnattu Mahtirojektiryhmälle, Tietotekniikan projektityökurssin kurssihenkilökunnalle, Goforen henkilökunnalle sekä kaikille kyseisestä projektista kiinnostuneille. Projektin etenemisvaiheiden lisäksi dokumentti kuvaa lyhyesti ongelmat, joita tuotteella pyritään ratkaisemaan, projektissa käytetyt teknologiat, projektinhallintamenetelmät, asiakkaalle toimitettavat (ohjelmakoodi, dokumentit, jne.), tuntikirjanpidon eri näkökulmista, kurssipalautteen sekä koostetun statistiikkasivun. 5/27

6 2 Projektiorganisaatio 2.1 Mahtirojekti-ryhmä Jussi Tuurinkoski, projektipäällikkö Juho Teperi, web-ohjelmointiasiantuntija ja käytettävyysasiantuntija Oskari Ruutiainen, tietoturva-asiantuntija Taina Peltonen, ohjelmoija Niko Junkala, ohjelmoija Masi Kajander (keskeytti omalta osaltaan joulukuussa 2013) 2.2 Asiakas Asiakas on ohjelmistoalan yritys Gofore Oy. Gofore kuvaa henkilöstöään tietoyhteiskunnan palveluarkkitehteinä ja rakentajina. Alla on listattu Goforen edustajat ja mainittu pääasiallinen kontakti Goforen ja Mahtorojekti-ryhmän välillä: Salum Abdul-Rahman (ensisijainen kontakti) Erkki Salminen Jaakko Salonen Janne Mattila Juha Virtanen Juhan Huotarinen Jussi Nurminen Sami Kallio 2.3 Kurssihenkilökunta Alla on listattu kurssin vastuuhenkilöt sekä projektiryhmän assistentti. Outi Sievi-Korte, vastuuhenkilö Tero Ahtee, vastuuhenkilö Marko Leppänen, assistentti 6/27

7 3 Tuote 3.1 Tarkoitus Tuotteen tarkoitus on toimia tukena asiakasyrityksen henkilöstön osaamisen hallinnassa. Tuotteella voidaan määrittää henkilöstön osaaminen ja hyödyntää tietoa työntekijän kehityskeskustelussa. Tuotteen avulla pystytään seuraamaan yrityksen, ryhmän tai yksilön taitojen kehitystä ja tietoa osaamisesta voidaan hyödyntää etsiessä sopivia työntekijöitä projekteihin, tilatessa kouluksia henkilöstölle tai vertaillessa ryhmien välistä osaamista ja kehitystä. 3.2 Ympäristö Tuote toimii web-sovelluksena ja sitä ei liitetä asiakasyrityksen muihin järjestelmiin. Asiakas vastaa itse tuotteen käyttöönottoympäristöstä. Järjestelmän palvelimella käytetään MongoDB-tietokantaa, johon skeeman ja validoinnit tarjoaa Mongoose. Http-palvelimena käytetään Node.js-alustaa yhdessä express.js-ohjelmistokehyksen kanssa. Selainpohjaisessa asiakassovelluksessa käytetään JavaScriptiä ja Angular.js-ohjelmistokehystä käyttöliittymän tarjoamiseen. 3.3 Kolmannen osapuolen komponentit ja lisenssit Listaus projektissa käytetyistä kolmansien osapuolien komponenteista ja niiden lisenssit löytyvät erillisestä markdown-tiedostosta liitteenä. 3.4 Rajoitteet HOHTO:n käyttöön ei liity erillisiä rajoitteita. Tuote on itsenäinen web-sovellus. 3.5 Toimitettava tuote Toimitettava tuote on web-palvelun lähdekoodi ja sen ylläpitodokumentaatio. Tuotteen lähdekoodi toimitetaan asiakkaalle Github-versiohallinnan kautta. Versiohallinta sisältää kaikki tarvittavat tiedostot tuotteen käyttöönottoon. Asiakkaalle tarjotaan myös ylläpito-ohje, joka kertoo tarkemmin myös miten jatkokehittää tuotetta. Ylläpitodokumentin lisäksi asiakkaalle toimitetaan projektiin liittyen projektisuunnitelma, määrittelydokumentti, testausraportti sekä loppudokumentti. 7/27

8 Taulukko 3.1 Dokumentit. Dokumentin nimi Palautuspäivä Vastuuhenkilö Toimitettu Projektisuunnitelma v Tuurinkoski Gofore, kurssihenkilökunta, projektiryhmän sivu Vaatimusmäärittely v Tuurinkoski Gofore, kurssihenkilökunta, projektiryhmän sivu Testausraportti v Tuurinkoski Gofore, kurssihenkilökunta, projektiryhmän sivu Loppuraportti v Tuurinkoski Gofore, kurssihenkilökunta, projektiryhmän sivu Ylläpitodokumentti v Teperi Gofore Palaverimuistiinpanot Tuurinkoski Gofore Projektisuunnitelman katselmointipöytäkirja Tuurinkoski kurssihenkilökunta Koodikatselmointipöytäkirja Tuurinkoski kurssihenkilökunta Project Highlights viikoittain sunnuntaisin Tuurinkoski kurssihenkilökunta, projektiryhmän sivu Taulukko 3.2 Koodirivien määrä Missä Määrä Backend 3078 Frontend 2779 Template 1455 Yhteensä /27

9 Kuva 3.1 Koodirivien määrä ajan funktiona 3.6 Oikeudet Tuotteen kaikki oikeudet jäävät molemmille osapuolille, asiakasyritykselle sekä kehittäjille. Molemmat osapuolet saavat jatkokehittää palvelua haluammaan tavalla. Oikeudet on määritelty tarkemmin kehitysryhmän ja asiakasyrityksen välisessä kirjallisessa sopimuksessa. 9/27

10 4 Projektinhallinta 4.1 Kommunikointi Turhan työn välttämiseksi ja tehokkuuden maksimoimiseksi kommunikointi ryhmän sisällä, ryhmän ja asiakkaan välillä sekä ryhmän ja kurssihenkilökunnan välillä on kriittinen osa projektissa. Tämän vuoksi päätimme alusta lähtien pitää säännöllisesti viikkopalaveria ryhmän kesken ja ehdottaa asiakkaalle säännöllisiä asiakastapaamisia lähtökohtaisesti kahden viikon välein. Asiakastapaamiset Goforen Tampereen toimistolla olivat erittäin hyödyllisiä. Tunnin aikaikkunaan sai paljon keskustelua ja oli mielenkiintoista kartoittaa asiakkaan näkemyksiä ja pyrkiä yhteiseen visioon. Välillä asiakasosapuoli saattoi hieman innostua kertoessaan toiveita palvelun toiminnallisuuksista, jolloin oli syytä itse keskittyä poimimaan suuremmassa kuvassa ajatus ja toive, mitä HOHTO mahdollisesti voisi tarjota. Projektin alussa asiakastapaamisia pidettiin kahden viikon välein, mikä oli tärkeää määrittelyvaiheessa, mutta työn edetessä tapaamisien välinen aika muuttui käytännössä usein kolmeksi tai neljäksi viikoksi, sillä esityslistaan ei saatu tarpeeksi avoimia kysymyksiä tai keskustelunaiheita, että palaveriin käytetty aika olisi ollut kannattavaa. Mahtirojekti-ryhmän kesken pidimme säännöllisesti viikkopalaverin joka tiistai kurssin luentojen jälkeen. Viikkopalavereissa suoritettiin työnjako ja täydennettiin backlogia tarvittaessa. Palavereissa tehtiin myös paljon suunnitteluratkaisuja, jotka vaikuttivat HOHTO:n toimintoihin suuressa kuvassa. Yksittäiset toiminnallisuuskohtaiset ratkaisut teki kukin ohjelmoija itse, jonka jälkeen toteutus esiteltiin muulle ryhmälle. Viikkopalaverien lisäksi projektiryhmä kokoontui usein koodausiltamiin, pääasiassa torstaisin. Sekä viikkopalaverit että koodausiltamat vaikuttivat positiivisesti projektin etenemisen lisäksi yhteishenkeen, mikä oli ensisijaisen tärkeää motivaation ylläpitämiseksi. Kurssihenkilökunnan kanssa ensimmäinen palaveri oli projektin kick-off. Tätä seurasivat myöhemmässä vaiheessa sekä projektisuunnitelman että koodin tarkastustilaisuudet ja projektin valmistuttua vapaamuotoinen esittelypalaveri valmiista tuotteesta. Ennakko-odotuksiin nähden yhteisiä palavereita ja vuorovaikutteisia katsauksia työn etenemisestä oli melko vähän. Toisaalta turhan tuntuisia palavereita ei ollut, mikä oli hyvä asia. 10/27

11 Projektin aikana raportoimme työn etenemisestä ja projektiin liittyvistä tapahtumista viikkokatsauksien muodossa suoraan kurssihenkilökunnalle. Pian projektin alkamisen jälkeen päätimme myös laittaa viikkokatsaukset julkiseen jakoon projektiryhmämme sivulle. Tätä kautta myös Goforen edustajat pääsivät halutessaan lukemaan kyseisiä raportteja viikottain. Viikkokatsaukset lähetettiin kurssihenkilökunnalle erikseen kunkin viikon sunnuntaina. Tapaamisten rungot olivat pääasiassa ennalta suunniteltuja ja niissä käytiin asioita läpi suuremmassa kuvassa. Yksityiskohtaisempaan ja nopeaan yhteydenpitoon käytimme IRC:tä. Perustimme kaksi kanavaa, joista toinen oli ryhmän yksityinen kanava ja toinen ryhmän ja asiakkaan yhteinen kanava. Ryhmän yksityinen kanava olikin ryhmän keskinäisen kommunikoinnin ensisijainen työkalu. Hyödynsimme IRC:tä myös tuntikirjanpidossa. Ensimmäisiä toteutettuja asioita projektin alussa oli IRC-botin tekeminen, joka otti vastaan tuntikirjaukset, päivitti ne automaattisesti.tsv-tiedostoon, josta merkinnät näytettiin projektiryhmän verkkosivuilla reaaliaikaisesti. IRC-botille toteutettiin myös kysymys-vastaus toiminnallisuus, jonka avulla henkilö pystyi jättämään yleensä suunnitteluratkaisuun liittyvän kysymyksen!ask <kysymys> komennolla, johon muut pystyivät vastaamaan!answer <id> <vastaus> komennolla. Projektiryhmän ja asiakkaan yhteinen kanava helpotti yhteydenpitoa ja asioiden sopimista, kuten palaveriaikatauluja, monessa tilanteessa. Kynnys oli pienempi kuin sähköpostin kirjoittamisessa ja vastauksetkin saatiin puolin ja toisin paljon nopeammin. IRC:n lisäksi kommunikointivälineitä oli useita eri tarkoituksiin. Gofore loi oman projektiympäristön sisäiseen Confluenceen, johon Mahtirojekti-ryhmä sai tunnukset. Tämän wikin kautta jaettiin projektin dokumentit (projektisuunnitelma, vaatimusmäärittely, palaverimuistiinpanot, testausraportit ym.), yhteystiedot ja linkit tärkeisiin sivustoihin, kuten projektiryhmän sivulle, Heroku-pilvipalveluun ja projektityökurssin kotisivulle. Pääasiallinen kommunikointiväline projektiryhmän ja asiakkaan välillä oli kuitenkin sähköposti. IRC-botin kysymys/vastaus toiminto käsitti pääasiassa työkaluihin ja suunnitteluratkaisuihin liittyviä kysymyksiä eikä niinkään teknisiä yksityiskohtia toteutuksista. Bugihavaintojen, rikkinäisten toiminnallisuuksien tai toteutuskohtaisten umpikujien raportoimiseksi ja ratkaisemiseksi hyödynsimme Github:n tarjoamaa Issue Trackeria. Työnjako, työn edistymisen seuranta ja backlogin ylläpito hoidettiin Goforen tarjoaman lisenssin turvin AgileZen Kanban-taululla. 11/27

12 4.2 Prosessin kuvaus Projektin läpivientiprosessi alkoi aiheen saatuamme teknologioiden valitsemisella. Toteutustavasta oli alusta lähtien selkeä visio, joten pääsimme keskittymään vaatimusten keräämiseen välittömästi. Vierailimme Goforen Tampereen toimistolla esittelemässä itsemme, alustavat suunnitelmat tietokannan toteuttamisesta ja valitut teknologiat. Ensimmäisen asiakastapaamisen jälkeen teimme ensimmäiset versiot vaatimusmäärittelystä ja projektisuunnitelmasta. Varmistimme lisäksi, että kukin kehittäjä sai asennettua vaaditut työkalut ja valmisteltua itselleen toimivan kehitysympäristön. Ensimmäisen sprintin loppuun mennessä olimme toteuttaneet backendiin jo perustoiminnallisuudet valtaosalle alustavan toiminnallisen määrittelyn perusvaatimuksista. Toisen sprintin alkajaisiksi saimme palautetta vaatimusmäärittelystä. Esittelimme myös käyttöön ottamiamme yksikkötestaustyökaluja. Olimme tässä vaiheessa saaneet jo vahvan rungon aikaiseksi. Tähän mennessä myös ryhmille oli tullut tarve, joten se lisättiin perusvaatimuksiin ja niiden implementointi aloitettiin välittömästi. Suunnitteluratkaisujen osalta teimme päätöksen käyttää käyttöliittymässä välilehtiä kullakin profiilisivulla jakamaan sisältöä siten, että käyttäjän ei tarvinnut rullata sivua ylös ja alas nähdäkseen kyseiseen profiiliin liittyviä tietoja. Toinen sprint päättyi välinäyttöihin. Tähän mennessä olimme tehneet valtaosan perustoiminnallisuudesta ja olimme erittäin hyvin aikataulussa. Kolmas sprint alkoi pienellä hengenvedolla. Tähän asti töitä oli tehty tehokkaasti ja tulosta oli syntynyt hyvää vauhtia. Huomasimme kuitenkin backendin ja koodin refaktoroinnille olevan tarvetta, mikä olikin kolmannen sprintin suurin yksittäinen työvaihe. Refaktorointi venyi hieman yli viikolla. Tämän aikana uutta toiminnallisuutta ei juurikaan voinut kehittää, joten tämä antoi hyvää aikaa yksikkö- ja e2e-testien toteuttamiselle. Kolmannen sprintin aikana oli myös aika laittaa viimeiset toiminnalliset vaatimukset lukkoon. Muutoksille oli toki ketterän kehitystapamme ansiosta tilaa, mutta suuria linjauksia palvelun lisätarjonnasta ei enää tehty. Neljännen sprintin aluksi päätimme yhdessä Masi Kajanderin kanssa, että hän jättää projektikurssin omalta osaltaan kesken. Asiasta oli keskusteltu jo aiemmassa vaiheessa. Implementoinnin osalta refaktorointi oli tehty ja oli aika keskittyä hiomaan perustoiminnallisuutta ja viemään lisäominaisuuksia eteenpäin. Asiakastapaamisessa tuli ilmi vielä uusia vaatimuksia esimerkiksi avainsanojen ja projektiroolien ylläpitotyökaluista. Otimme myös nämä seikat työjonoon. Implementoinnin ohessa aloitimme ensimmäiset epäviralliset 12/27

13 järjestelmätestit Heroku-pilvipalvelun kautta ennen joulutaukoa. Joulutauon jälkeen työ jatkui kovalla tahdilla. Ensin oli vuorossa uuden julkaisun lataaminen testiympäristöön, jonka jälkeen järjestimme käytettävyystestauksen, johon osallistui yhdeksän henkeä Goforelta. Käytettävyystestaus osoittautui hieman hankalaksi, sillä käytettävyyteen ei pystynyt täysin keskittymään palvelun bugien vuoksi. Saimme kuitenkin hyvää palautetta ja ehdimme reagoimaan moneen asiaan ennen koodaustyön loppuun saattamista. Koodaustyö ja testaus oli nyt tehty takarajaan mennessä. Viidennen sprintin aikana kirjoitimme ylläpitodokumentin asiakkaalle käyttöönottoa varten ja varmistimme, että tuote on valmis tuotantoon vietäväksi. Kuva 4.1. Työn edistyminen eri vaiheissa 4.3 Tavat ja työkalut Projektin tavoitteena oli toteuttaa itsenäinen web-sovellus, jonka tekemiseen käytettäisiin moderneja web-teknologioita. Teimme varhaisessa vaiheessa päätöksen, että koko palvelu pohjalta pinnalle tultaisiin tekemään JavaScript:llä. Tietokanta toteutettiin MongoDB:n avulla, jossa skeemoista ja validoinnista huolehti Mongoose. Tämä osoittautui hyväksi valinnaksi relaatiokannan yli, sillä tietokannan joustavuus oli helpottava tekijä ketterässä kehityksessä. Backendin JavaScript-kirjastona hyödynnettiin Node.js. Frontendin esittämisessä käytettiin HTML 5:sta ja Less CSS ja JavaScript:n osalta pääasiassa AngularJS. Backendin ja käyttöliittymän välinen rajapinta onnistui REST-kutsujen avulla. Versionhallinnassa luotimme Githubiin. Projektiin liittyi kaksi erillistä tietosäilöä, joista toinen oli täysin pyhitetty HOHTO:n koodille ja bugiseurantaan. Toinen säilöistä oli vapaamuotoisempi dokumenttien jakamiseen ja projektisivun 13/27

14 ylläpitämiseen hyödynnetty tietosäilö. Github:sta ei erikseen otettu varmuuskopioita projektin aikana erilliselle levylle, mutta kaikilla projektiryhmän jäsenillä oli haettuna kummankin tietosäilön sisällöt paikallisesti omalle tietokoneelle. Dokumentointiin liittyvät työkalut vaihtelivat projektin alussa. Otimme aluksi käyttöön Libre Officen, mutta olimme tyytymättömiä työkalun epäjohdonmukaisuuksiin ja käytettävyyteen, joten siirryimme malliin, missä suurin osa dokumentoinnista tehtiin markdown-formaatissa ja tarvittaessa joko vietiin PDF:ksi tyylilisäysten kanssa tai vaihtoehtoisesti muokattiin leipäteksti Microsoft Office tuoteperheen työkaluilla. Kehityksessä käytettiin tekstieditoreina ohjelmoijasta riippuen Sublime Text:ä, Notepad++:a tai Vim:ä. Käyttäjätestauksen palautteet kerättiin Google Docs:lla toteutetun lomakkeen avulla Excel-taulukkoon. Backlogin ylläpitoon, tehtävien jakamiseen ja työnseurantaan käytettiin AgileZen-työkalua. Kyseessä on ketterään kehitykseen tarkoitettu Kanbantaulu. Käytimme taululla värikoodauksia eri aihealueisiin liittyviin tehtäviin. Taululla olevat tehtävät jaettiin neljään vaiheeseen. Tehtävä oli joko auki, työn alla, valmis siinä merkityksessä, että muut pystyivät käyttämään jo koodia tai koodin osia tai kokonaisuudessaan valmis, millä tarkoitettiin sitä, että koodi oli valmis seuraavaan julkaisuun ja että tehtävä voitiin siirtää arkistoon. Bugien ja teknisten ongelmien monitorointiin käytettiin Githubin Issue Trackeria ja yleisten suunnitteluratkaisuihin liittyviin ongelmien monitorointiin IRC-bot:n tarjoamaa kysymys/vastaus toiminnallisuutta. Testauksen työkaluina toimivat Grunt rutiinien automatisointiin, Mocha JavaScript testikehystä yksikkö- ja e2e-testien toteutukseen. Järjestelmätasolla tuotetta testattaessa HOHTO oli ladattuna Heroku-pilvipalveluun, johon päivitettiin aina uusin julkaisu testattavaksi. Tämä menetelmä mahdollisti yhden tuotantoa jäljittelevän testiympäristön, ja kukin pystyi kehittämään uusia ominaisuuksia tai korjaamaan vanhaa toiminnallisuuttaa omissa kehityshaaroissaan. Myöhemmin, kun toiminnallisuus oli testattu paikallisesti se voitiin ladata uuden julkaisun mukana Herokuun. Kommunikoinnin pääasialliset työkalut olivat IRC ja sähköposti projektiryhmän kesken, IRC, Confluence ja sähköposti projektiryhmän ja asiakkaan välillä sekä sähköposti projektiryhmän ja kurssihenkilökunnan välillä. 14/27

15 4.4 Motivaatioruiskeet Projektiryhmän motivaatio läpi projektin oli sen onnistumisen kulmakiviä. Onnistumiset ruokkivat sitä, mutta joskus oli hyvä myös sulkea kehitystyökalut ja nojata taakse. Joulutauko tarjosikin hyvän hengähdystauon, joskin aikataulun suunnittelussa olisi pitänyt huomioida tarkemmin tammikuun erittäin lyhyt jäljellä oleva työskentelyaika. Järjestimme projektiryhmän oman saunaillan marraskuun aikana ja samanlaiseen tapahtumaan tulemme päättämään projektin viimeisten palaverien jälkeen helmikuun puolivälissä. Tämän lisäksi pidimme projektin pikkujoulut tammikuun puolella yhdessä asiakkaan kanssa. Ohjelmassa oli jousiampumista, hyvää ruokaa ravinteli Huberissa ja muutama jälkiruoka Teerenpelissä. Pikkujoulut ja illan aikana käydyt keskustelut kuvasivat hyvin projektiryhmän ja asiakkaan välillä vallitsevaa arvostusta ja hyvää yhteishenkeä. 15/27

16 5 Tuntikirjaukset Tässä luvussa käydään läpi toteutuneet tuntimäärät projektissa. Kuva 5.1 Toteutuneet työtunnit työkategorioittain Kuva 5.2 Toteutuneet työtunnit ajan funktiona (viikkokohtainen) 16/27

17 Kuva 5.3 Toteutuneet työtunnit ajan funktiona (sprint-kohtainen) Taulukko 5.1 Toteutuneet työtunnit henkilöittäin viikkoa kohden Viikot Jussi Juho Oskari Taina Niko Masi Yhteensä YHT /27

18 6 Riskit ja ongelmat 6.1 Riskit, joihin oli valmistauduttu Projektisuunnitelmaan määritellyistä riskeistä [2] toteutui riski "Yksi ryhmän jäsen ei pysty jatkamaan kurssin suorittamista". Sen todennäköisyys oli merkitty erittäin pieneksi, mutta myös merkittävyys oli kohtalaisen pieni. Riski toteutui neljännen sprintin alussa. Ennusmerkit olivat kuitenkin havaittavissa jo selvästi aiemmin: ryhmäläisellä oli paljon muita, projektin ulkopuolisia velvoitteita ja osallistuminen työn tekemiseen oli vähäistä. Riskin toteutuminen ei tuottanut ongelmia, vaan keskeyttäneen tehtävät pystyttiin siirtämään muille jäsenille. 6.2 Riskit, joihin ei ollut valmistauduttu Koodin refaktorointi sprintin kolme aikana vei odotettua noin viikon pidemmän ajan. Tämä tietenkin vähensi aikaa muiden tehtävien tekemiseltä, mutta ei kuitenkaan vaarantanut projektin valmistumista ajallaan. Lisäksi refaktoroitavana olevaan koodiin liittyviä uusia ominaisuuksia ei kannattanut tehdä refaktoroinnin aikaan, mutta sen sijaan he, jotka eivät refaktoroineet, pystyivät tekemään muun muassa yksikkötestejä. Myös muutamat toiminnallisuudet, joiden oletettiin olevan nopeita ja yksinkertaisia tehdä, osoittautuivatkin paljon oletettua monimutkaisemmiksi ja näin veivät odotettua enemmän aikaa. 18/27

19 7 Hylätyt ajatukset ja jatkokehitys 7.1 Hylätyt ajatukset Aluksi pohdittiin, että järjestelmässä voisi hakea käyttäjiä erilaisten kriteereiden avulla. Esimerkiksi jos haluttaisiin projektiin henkilö, jolla ei ole paljoa osaamista tietystä taidosta, mutta kova kiinnostus oppia se, voitaisiin käyttäjien hakukriteereiksi syöttää haluttu taito ja sen kiinnostustaso 5 ja taitotaso 2. Järjestelmä näyttäisi listauksen hakua parhaiten vastaavista käyttäjistä. Asiakkaan kanssa todettiin kuitenkin, että tämä ei ole tarpeellinen toiminto järjestelmän pääasiallinen tarkoitus huomioituna. Pohdinnan alla oli, että taidon kokemusmäärä kuukausina laskettaisiin automaattisesti projekteiden, joissa käyttäjä on ollut mukana ja kyseistä taitoa on käytetty, pituudesta. Kuitenkaan kaikki projektin osallistujat eivät käytä kaikkia projektiin lisättyjä taitoja, ja eri taitoja saatetaan käyttää eripituisia aikoja projektien sisällä. Tämän vuoksi taidon kokemusmäärän eri projekteissa voi lisätä manuaalisesti ja järjestelmä laskee käyttäjän taidon kokemusmääräksi yhteen nämä eri projektien taidon kokemusarvot. Tilastotiedon esittämiseen graafeina pohdittiin D3-kirjastoa tai Angularin valmista toteutusta, mutta päädyttiin Flot-kirjastoon. Myös muun muassa Angularin valmis autocomplete-toteutus hylättiin ja kirjoitettiin oma direktiivi, sillä niillä ei ollut mahdollista tehdä asioita, joita tarvitsi tehdä. 7.2 Jatkokehitys Käyttäjää ei voida poistaa järjestelmästä. Asiakas totesi, että on hyvä, että käyttäjiä ei voi poistaa tietokannasta, ettei tietoa häviä, mutta käyttäjät voitaisiin näennäisesti poistaa, eli ne eivät näkyisi järjestelmää käytettäessä, mutta olisivat tarpeen tullen tietokannasta saatavilla. CV:n voi viedä järjestelmästä vain JSON-muodossa. Sitä käyttäjä ei voi sinällään käyttää CV:nään. Hyödyllistä olisi, jos järjestelmästä saisi suoraan ulos hyvin muotoillun dokumentin PDF:nä. Voisi olla myös tarpeen pystyä muokkaamaan CV:tä ennen vientiä, jos esimerkiksi ei haluta kaikkia järjestelmään tallennettuja taitoja tai työpaikkoja näkyviin CV:seen. 19/27

20 Asiakkaan alustavassa vaatimusmäärittelylistauksessa lisätoiveena oli integraatio Goforella jo käytössä oleviin järjestelmiin (Confluence, JIRA, PlanMill, jne.) [1]. Projektiryhmä totesi, että kirjautuminen järjestelmään voisi olla yhtenäinen muiden järjestelmien kanssa. Järjestelmässä esitetään tilastotietoa graafeina käyttäjän taitojen tasoista ja taitojen kehityksestä yrityksessä. Myös muunlaista tilastotietoa voitaisiin esittää. Asiakkaan kannattaa pohtia tarkemmin, millaista tietoa haluaa järjestelmällä seurata ja tehdä sitä kuvaavia graafeja. Asiakas halusi, että järjestelmässä voi kuka tahansa tehdä mitä tahansa, eli ei ole esimerkiksi ylläpitokäyttäjäryhmää, joka ainoastaan voi esimerkiksi poistaa tai yhdistää taitoja. Jos järjestelmä ei toimi näin vapaana hyvin, voitaisiin siihen lisätä käyttäjäryhmiä, joiden käyttäjät pystyisivät tekemään erilaisia asioita. 20/27

21 8 Opitut asiat 8.1 Kokemukset Ryhmän jäsenet oppivat alusta alkaen tai taitojaan parannellen projektin kielenä käytettyä JavaScriptiä, MongoDB-tietokannan käyttöä, web-palvelun arkkitehtuuria ja muita käytettyihin teknologioihin liittyviä asioita. Lisäksi tutuksi tulivat projektissa käytetyt työkalut, esimerkiksi Confluence, AgileZen ja GitHub. Projektissa pääsi oppimaan projektinhallintaa käytännössä ja viemään asiakasprojektin läpi määrittelyvaiheesta tuotantoon. Valitut työkalut ja teknologiat olivat hyviä. Oikeat henkilöt tekivät päätökset näiden suhteen, eli ne joilla oli jo projektin alussa tietämystä ja kokemusta näistä. Työskentely ryhmänä sujui hyvin. Ryhmähenki oli hyvä, toisia autettiin tarvittaessa ja projektista keskusteltiin tiiviisti. Onnistuimme pitämään lupauksemme asiakkaalle siitä, mitä ollaan toimittamassa. Yhteydenpito asiakkaan kanssa sujui odotettua helpommin. Asiakas sopi mielellään tapaamisia kanssamme tiloihinsa useamminkin kuin kurssi vaati. Lisäksi asiakkaan suhtautuminen projektiryhmään oli erittäin positiivinen läpi projektin, mikä lisäsi motivaatiota. 8.2 Kehitettävää Jos projektia olisi tehnyt täysipäiväisesti, eikä muiden koulutöiden ja osalla myös töiden ohella, olisi projektiin pystynyt keskittymään paremmin. AgileZenissä olevia tehtäviä olisi voinut pitää paremmin ajantasalla ja resursoida selkeämmin ja tarkemmin esimerkiksi kuka tekee minkäkin tehtävän ja paljon sen tekemiseen on aikaa. Viikkopalaverien aiheet olisivat voineet olla aina etukäteen näkyvillä koko ryhmälle, jotta ryhmä tietäisi jo etukäteen, mitä asioita ollaan käsittelemässä ja mahdollisesti valmistautua palaveriin. Joka kerta ennen palaveria asiakkaan kanssa oltaisiin voitu toimittaa asiakkaalle palaverin esityslista, jotta tarpeelliset henkilöt olisivat asiakkaan puolelta paikalla ja että he tietäisivät etukäteen, mitä ollaan tekemässä ja mahdollisesti tutustua esiteltävään materiaaliin etukäteen. Esityslista toimitettiin kyllä muutaman kerran. 21/27

22 8.3 Yhteenveto Tiivis yhteydenpito sekä ryhmän sisällä että ryhmän ja asiakkaan välillä on helpottanut projektin kulkua paljon. Ryhmän kokeneempien jäsenten ammattitaito ja asiantuntemus varmistivat, ettei missään vaiheessa tullut hätä. Heillä oli vahva visio, jonka seuraaminen johti hyvään lopputulokseen. Asiakkaalla oli myös yllättävän hyvä ja selkeä näkemys siitä, mitä he halusivat. Projektiryhmän näkökulmasta etenevä toteutus vastasi asiakkaan odotuksia ja asiakaskin vaikutti tyytyväiseltä jo loppuvaiheen demoihin sekä lopputulokseen. Asiakkaan suullinen hyväksyntä saatiin vuoden alussa käydyssä asiakastapaamisessa, jonka jälkeen palvelu kehittyi vielä huimasti etenkin käytettävyydeltään viimeiseen versioon mennessä. 22/27

23 9 Kommentit kurssista 9.1 Hyvät asiat - Vapaus valita projekti useista aiheista - Kurssilla ei juurikaan tarvinnut tehdä turhaa dokumentaatiota - Projektin läpi vieminen arvokas kokemus - Kontaktit asiakasyritykseen - Ryhmälle annettiin kaikki vastuu projektin onnistumisesta - Vertaisarvioinnit olivat ajatuksen hyviä, mutta olisi ollut tarpeen seurata tarkemminkin jonkun toisen ryhmän projektin etenemistä, jotta vertaispalaute olisi ollut hyödyllisempää - Koodin ja projektisuunnitelman tarkastustilaisuudet olivat hyvä asia opettavana esimerkkinä o Näki, että tällaisiakin voidaan pitää ja samalla sai esimerkin tapahtuman läpiviennistä - Kurssin aikataulutus oli esillä heti projektin alusta alkaen 9.2 Kehitettävää ja huonoja puolia - Luennoitsijan englanninkielentaito vaikutti negatiivisesti luentojen antiin - Workshopit olivat aika valmistelemattomia ja ehkä senkään vuoksi eivät tarjonneet oikein mitään o Muiden projektien ongelmista keskusteleminen olisi ollut mielekkäämpää, jos projektit olisivat olleet tuttuja o Nyt keskustelut olivat pintaraapaisuja ja ongelmat sellaisia, joihin ei osannut antaa valistunutta vastausta, jolloin keskustelu jäi mitäänsanomattomaksi - Useat luennot vaikuttivat myös aika turhilta, esimerkiksi kun käytiin dokumentin sisällysluettelo yhdessä läpi luentosalissa - Sprintit olivat melko pitkiä ja rakenne noudatteli edelleen suoraan vesiputousmallia ketterät lähestymistavat vaihtoehtoina unohdettu? - Aiheita tuli myöhässä valittavaksi o Seuraavaksi kerraksi tiukka deadline yrityksille? - Projektin onnistuminen, projektikurssin hyödyllisyys ja muut vastaavat seikat tosi vahvasti kiinni omasta ryhmästä, projektiaiheesta tai asiakkaasta (ehkä enemmänkin neutraali toteamus) 23/27

24 10 Statistics 24/27

25 25/27

26 Viitteet [1] Gofore Tietotekniikan projektityö asiakasvaatimukset. Viitattu Saatavilla: [2] HOHTO Projektisuunnitelma. Viitattu Saatavilla: 26/27

27 Liitteet [1] Listaus kolmannen osapuolen komponenteista lisensseineen. Saatavilla: 27/27