Loppuraportti - StatbeatMOBILE Versio Päivämäärä Henkilö Kuvaus 1.0 21.3.2014 Westin Ensimmäinen versio 1.1 28.3.2014 Westin Täydennystä 1.2 4.4.2014 Pöyry & Westin Luku 1.3 ja muiden lukujen täydennystä 1.3 5.4.2014 Westin Luvut 2 ja 3.1 1.4 6.4.2014 Westin Luvut 1.2 ja 2.1 1.5 7.4.2014 Verkkoperä Täydennystä 1. Tulosten arviointi 1.1 Projektin tavoitteiden toteutuminen 1.2 Laatu 1.3 Tiedostetut ongelmat ja jatkokehitystarpeet 1.4 Haasteet 2. Resurssit ja metriikat 2.1 Henkilöresurssit 2.2 Tekniset metriikat 3. Käytännöt ja työkalut 3.1 Käytännöt 3.2 Vertaistestaus 4. Opetusarvo 4.1 Mitä tehtäisiin toisin 4.2 Opittua kurssilla 5. Kurssipalaute 1. Tulosten arviointi 1.1 Projektin tavoitteiden toteutuminen 1
Seuraava on lainaus projektisuunnitelmasta: Projektin ensimmäisenä tavoitteena on Statbeat käyttäjien mobiilikokemuksen parantaminen. Tällä hetkellä Statbeatilla on responsiivinen sivusto, jota halutaan viedä askel eteenpäin hybridi applikaation toteuttamisella. Hybridi applikaatio tarkoittaa sitä, että natiivin applikaation sisään rakennetaan HTML pohjaisesti sisältöä. Toisena tavoitteena on, ettei sidota palvelua liikaa natiiviteknologioihin. Asiakkaalle on tärkeää, että otamme huomioon Statbeatin jatkokehityksen. Hybridi applikaatioon pystyy tekemään natiivisti paljon ominaisuuksia haluttaessa. Tärkein natiivi ominaisuus projektissa on notifikaatiot. Kolmantena tavoitteena on tuottaa laadukasta jälkeä, jotta jatkokehitys onnistuu helposti HTML5 ja JavaScript/CoffeeScript painotteisesti. Pyrimme tarkastamaan koodin laadun aina kun sitä kirjoitetaan lisää. Uusi mobiilisovellus tai palvelu on ryhmän ja asiakkaan mielestä huomattavasti edellistä parempi. Uusi frontend on suunniteltu mobiililaitteita varten, joten sivuston toiminta ja elementtien sijoittelut ovat loogisemmat. Lisäksi natiiviapplikaatioiden avulla voidaan tarjota tärkeät notifikaatiot, jotka ovat aiemmin puuttuneet. Mobiilikokemusta on pyritty parantamaan tuomalla kiinnostavinta sisältöä ensimmäisenä näkyviin, helpottamalla navigointia oikopolkujen avulla sekä antamalla käyttäjälle vähemmän vaihtoehtoja kerrallaan. Lisäksi sisältö on pyritty tuomaan esiin siten, että se on helposti luettavaa ja se vie mahdollisimman vähän tilaa. Suurin puute uudessa mobiilikokemuksessa on että tämän projektin puitteissa ei ole ehditty toteuttaa kaikkia ominaisuuksia, jotka olivat tarjolla vanhassa palvelussa. Kuitenkaan montaa kriittistä ominaisuutta ei puutu. Projektin toinen tavoite, natiiviteknologioiden kevyt käyttö, on toteutunut. Android ja ios sovellukset on pidetty mahdollisimman kevyinä toteuttamalla valtaosan toiminnallisuudesta frontendiin. Tällä hetkellä natiivisovellukset sisältävät käytännössä ainoastaan natiivien notifikaatioiden vaatiman toiminnallisuuden. Projektissa on myös päästy kolmanteen tavoitteeseen. Koodin laatu on ryhmän mielestä erinomaisella tasolla vertaiskatselmointikäytäntöjen, staattisen koodianalyysin ja testien ansiosta. 1.2 Laatu Projektin laatutavoitteet (projektisuunnitelma kohta 5.2.1) olivat : 1. Helppokäyttöisyys 2. Nopeus ja sulavuus 2
3. Ylläpidettävyys 4. Koodin laatu ja ymmärrettävyys Sovelluksen ylläpidettävyys sekä koodin laatu ja ymmärrettävyys ovat kummatkin erinomaisella tasolla. Natiivisovelluskehykset ovat yksinkertaisia ja kevyitä, joten asiakkaan toiveiden mukaisesti niiden ylläpito on mahdollisimman helppoa. Sovelluskoodi on saatu pidettyä korkealaatuisena Git pull requestien ja tarkkojen vertaiskatselmointien ansiosta. Lisäksi pariohjelmointi, jatkuva integraatio ja staattinen koodianalyysi ovat kaikki osaltaan auttaneet laadukkaan koodin tuottamisessa. Lisää tietoa käytännöistä löytyy luvusta 3. Sovelluksen helppokäyttöisyys ei ehkä ole aivan sillä tasolla kuin on toivottu, sillä mm. vertaistestausryhmältä tuli moitteita käyttöliittymän epäintuitiivisuudesta tietyissä paikoissa. Osasyy tähän on että joudutaan tasapainoilemaan eri käyttäjäryhmien tarpeiden välillä se mikä on helppokäyttöistä ns. poweruserille ei välttämättä ole helppokäyttöistä noviisille tai henkilölle joka tutustuu koko Statbeat palveluun ensimmäistä kertaa. Vertaistestausryhmältä tulleen palautteen jälkeen ehdimme kehittämään käyttöliittymää valmiimmaksi, mutta emme ehtineet kurssin puitteissa testata sitä uudelleen. Sovelluksen kenties suurin heikkous on sen nopeus ja sulavuus, joka on korkeintaan kohtalainen. Tämä johtuu hybridisovellustekniikasta, johon projektin alussa asiakkaan toiveesta päädyttiin alunperin suunnitellun natiivisovelluksen sijan, sekä hitaasta backend API:sta. Sovelluksen responsiivisuutta ja sulavuutta voisi parantaa erilaisilla paikallisilla offline välimuistitoteutuksilla, mutta niitä ei ehditty tutkia tämän kurssin puitteissa. Asia on varsin todennäköisesti työlistalla asiakkaan omassa sovelluksen jatkokehitysprojektissa. 1.3 Tiedostetut ongelmat ja jatkokehitystarpeet Sovellus käyttää notifikaatioiden hakemisessa polling tekniikkaa, joka kuluttaa virtaa tarpeettomasti ja aiheuttaa notifikaatioiden ilmestymiseen ylimääräistä viivettä. Sillä päätettiin kuitenkin aloittaa sen yksinkertaisuuden takia. Teknisesti parempi ratkaisu tähän olisi ollut push notifikaatioiden käyttö, mutta tämä jätettiin toteuttamatta koska sen toteuttamiseen kuluvan ajan arviointi oli vaikeaa. Suurimmat syyt tähän olivat että ryhmän sisällä ei ollut kokemusta push notifikaatioiden toteuttamisesta ja toteutus olisi myös vaatinut asiakkaan järjestelmiin tehtäviä suurempia muutoksia. ios alustalla polling sovelluksen ollessa taustalla on toteutettu käyttäen tekniikkaa jota ei ole tarkoitettu reaaliaikaiseen pollaukseen. Tämän johdosta notifikaatioiden ilmestymisessä voi kestää toivottua kauemmin. Emme kerenneet testaamaan taustalla olevan applikaation notifikaatioiden esitykseen kuluvaa aikaa. 3
Sovelluksen käyttökokemusta voisi myös parantaa rakentamalla applikaatioon ennakoivan välimuistin, joka lataisi Statbeat API:sta tavaraa jo ennen kuin käyttäjä haluaa nähdä sen. Tämän avulla sovelluksen sulavuutta voitaisiin parantaa. ios applikaatio toimii oikein, mutta siihen pitää vielä lisätä kuvat ja suorittaa jonkin verran testausta ennen kuin se voidaan lähettää sovelluskauppaan. 1.4 Haasteet Projektin ensimmäinen suuri haaste oli kun suunta vaihdettiin Android natiivisovelluksesta hybridisovellukseen asiakkaan toiveesta. Osa ryhmästä oli liittynyt projektiin nimenomaan Android kehitystyön takia, joten tämä oli heille kova pettymys. Heidän motivointi osoittautui melkoisen haasteelliseksi, sillä turhaa Android kehitystyötä haluttiin välttää ja projektissa edetään kuitenkin asiakkaan ehdoilla. Projektissa käytettiin myös ryhmälle ennestään tuntematonta AngularJS teknologiaa. Tämä aiheutti haasteita mm. aikataulullisesti, kun frontend kehittäjillä kului aikaa uusien asioiden opetteluun. Toisaalta he olivat kuitenkin tyytyväisiä uuden mielenkiintoisen tekniikan oppimisesta. Backend, eli Statbeat API, osoittautui monessa tapauksessa hieman hankalaksi kun se ei sisältänyt niitä toimintoja tai ominaisuuksia joita olisi tarvittu. Mikäli Statbeat API olisi ollut projektiryhmän hoidossa, olisi puuttuvia toimintoja voitu kehittää tarpeen mukaan, mutta tässä tapauksessa vastuuhenkilöt olivat asiakkaan puolella omien kiireiden ja aikataulupaineiden alaisina. Lisäksi backend:istä löydettiin muutamia virheitä, joiden selvittely kulutti aikaa. Viimeiseksi on muistettava, että vaikka projektin tavoitteena oli toteuttaa pelkkä Android hybridisovellus, on sen lisäksi toteutettu myös ios sovellus ilman aiempaa ios kokemusta, mikä on kasvattanut projektin haastavuutta. 2. Resurssit ja metriikat 2.1 Henkilöresurssit Projektiryhmän työtunnit löytyvät erillisestä tuntikirjaustaulukosta, jonne henkilökohtaiset työtunnit on merkitty viikkotasolla. Allaolevissa kuvaajissa on esitetty on ryhmän tuntikertymä koko projektin ajalta sekä henkilökohtainen toteuma tavoitteisiin nähden. Työtunteja kertyi n. 97 % budjetoidusta kokonaismäärästä. Henkilökohtaisesti jäsenten toteuma oli n. + 0,5 opintopisteen haarukassa, poislukien ääripäiden henkilöt, jotka vaihtoivat kurssilaajuutta (yksi korotti ja yksi laski). 4
2.2 Tekniset metriikat 77 vertaiskatselmoitua ja mergettyä Git pull requestia 540 versiohallinta committia 188 yksikkö ja integraatiotestiä 21 testitapausta 5
3. Käytännöt ja työkalut 3.1 Käytännöt Hyödyllisin käytäntö on ollut yhteinen viikottainen kehityspäivä, mikä on mahdollistanut koko ryhmän työskentelyn yhdessä samassa tilassa, aluksi Maarintalolla ja vuoden vaihteesta asiakkaan tiloissa. Näkisimme että tehokas viestintä sekä ryhmän sisällä että asiakkaan kanssa on ollut avainasemassa projektin onnistumisessa. Työkaluista Flowdock on sopinut projektiin erittäin hyvin ja sen ansiosta olemme voineet luopua kankeista sähköposteista kokonaan. Siihen on myös integroitu versiohallinta, Trello ja ryhmän yhteinen Google kalenteri, joten sieltä on saanut hyvän lyhyen tähtäimen yleiskuvan eri töiden etenemisestä. Trelloa käytettiin projektinhallintatyökaluna ja sovelletuin osin kevyenä Kanban boardina. Sen käyttöä olisi ehkä kuitenkin voinut yrittää tehostaa hieman nyt se oli enemmän johtotrion käytössä eivätkä kehittäjät käyttäneet sitä kovinkaan aktiivisesti. Toisaalta, kehityspäivänä käytiin läpi yhdessä mitä kehittäjät tekevät hyödyntäen Kanbania. Versiohallinta ja vertaiskatselmointikäytännöt ovat toimineen esimerkillisen hyvin. Olemme noudattaneet projektisuunnitelmassa esitettyä mallia, jonka mukaan koodi toteutetaan erillisiin brancheihin, jotka pull requestien avulla vertaiskatselmoidaan ennen sisällyttämistä master haaraan. Nämä käytännöt, yhdistettynä staattiseen koodianalyysiin ja yksikkötesteihin, ovat mahdollistaneet erittäin hyvälaatuisen kooditoteutuksen. Test driven development (TDD) ei ole soveltunut tähän projektiin niin hyvin kuin toivottiin. Sitä on hankala soveltaa vahvasti käyttöliittymävetoiseen nettisovellukseen eikä ennestään tuntematon kieli/tekniikka (AngularJS) helpota asiaa. Alun jälkeen päädyimme vähentämään TDD:n käyttöä ja hyödyntämään sitä enemmän tilannekohtaisesti, esim. jos tietty toiminto tai koodiosuus selkeästi sopisi TDD:llä toteutettavaksi. Jatkuva integrointi (CI) on toiminut hyvin ja auttanut kehitystyössä. Frontendin puolella on hyödynnetty asiakkaan käyttämää Travis CI järjestelmää, ja sen lisäksi Android kehitystyötä varten pystytettiin Amazonin pilvipalveluun Jenkins CI, joka paketoi uuden asennettavan Android asennuspaketin koodimuutosten jälkeen. Tämä jälkimmäinen CI järjestelmä rakennettiin throwaway ajatuksella, joten se ajetaan todennäköisesti alas projektin ja aktiivisen Android kehitystyön päätyttyä. 3.2 Vertaistestaus 6
Toivoimme saavamme vertaistestausryhmältä kokemuksia erityisesti liittyen käyttökokemukseen, mutta tietysti osittain myös tekniseen toteutukseen. Toimitimme heille asennettavan Android paketin, suuren määrän testitunnuksia, ohjeistusta (myös suullisesti tapaamisessa), testitapausmatriisin sekä listan vapaamuotoisempia tehtäviä ja niihin liittyviä kysymyksiä. Loimme myös tietokantaan suuren määrän testidataa, jotta testaus olisi helpompaa. Valitettavasti ryhmältä saatu testausraportti oli varsin lyhyt ja epästrukturoitu. Suullisessa ohjeistuksessa mainittuja asioita oli jätetty huomioimatta ja jotkut ongelmakuvaukset olivat hyvin epäselviä tai ristiriitaisia. Jos olemme maininneet että sovellus ei vielä sisällä monia ominaisuuksia, niin ei ole erityisen hyödyllistä saada kuulla että ne puuttuvat. Saatiin tietää, että sovelluksen responsiivisuus on heidän mielestään suurin ongelma, ja että käyttöliittymä on paikoitellen epäintuitiivinen, mutta kaipasimme vähän enemmän perusteluja ja parannusehdotuksia. Tässä tapauksessa vertaistestauksesta saatu informaatioarvo jäi siis melko laihaksi. Toisen ryhmän palvelun vertaistestaus oli sikäli hankalaa, että he eivät voineet toimittaa palvelua vapaaseen käyttöömme, sillä palvelu vaati tunnukset ja yhteyden asiakkaan taustajärjestelmiin. Näin ollen testausta voitiin suorittaa ainoastaan ryhmän omalla tietokoneella. Ryhmä ei kuitenkaan varoittanut tästä etukäteen, joten emme olleet täysin varautuneita ja asennoituneita muutaman tunnin testisessioon. Vaikka saimme testauksen suoritettua, uskomme että tulokset olisivat olleet parempia jos olisimme tienneet että testaus suoritetaan ihan paikan päällä tapaamisessa. 4. Opetusarvo 4.1 Mitä tehtäisiin toisin Ryhmäjäsenten aikataulut olisi ollut hyvä käydä säännöllisesti ja tarkemmin läpi, jotta ryhmä olisi pysynyt paremmin kartalla siitä, mikä on henkilöresurssitilanne lähitulevaisuudessa. Nyt haasteita aiheuttivat mm. muutamat hieman yllättäen ilmoitetut matkat ja muut poissaolot. Lisäksi yksi suunnitellusta työmäärästä reilusti jälkeen jäänyt henkilö ei toistuvista lupauksistaan huolimatta yrittänyt kuroa vajetta umpeen vaan ilmoitti vasta viimeisellä työviikolla, että hän suorittaa pienemmän kurssiversion. Projektin loppuun olisi pitänyt varata selkeämpi puskuriaika pienkorjauksiin ja viilailuihin. Vaikka se olikin suunnitelmissa, kävi lopulta niin että ominaisuuksien toteuttaminen ja suuremmat kehitystyöt kestivät odotettua kauemmin ja venyivät aivan viimeisille viikoille. Toisaalta tässä projektissa tämä ei ole suuri ongelma, sillä asiakas jatkaa sovelluksen jatkokehittämistä heti kurssin päätyttyä osittain samalla henkilöstöllä. Toisin sanoen sovelluksen ei tarvinnutkaan olla täysin valmis ja loppuun asti viilattu projektin päätyttyä, vaan tiettyjen vaadittujen ominaisuuksien toteuttamisen jälkeen tarkoituksena oli vain varmistaa saumaton kehitysvastuun siirtyminen projektiryhmältä asiakkaalle. 7
Projektin arkkitehtuurin suunnittelun kannalta olisi ollut viisaampaa käyttää alussa aikaa projektin tavoitteiden selkeyttämiseen. Jotkut alussa tehdyt oletukset eivät pitäneet paikkaansa, ja tämän seurauksena jonkun verran työaikaa meni hukkaan. 4.2 Opittua kurssilla Henkilö Sami Opittua Tavoitteena oli oppia mitä tahansa projektinjohdosta, ryhmätyöskentelystä ja käytännöistä. Alla huomioita: Varsinkin kouluprojekteissa ominaisuuksien kehitysajat venähtävät helposti. Koodaajille stressitön Kanban-tyyppinen ketterä ohjelmistokehitys toimii hyvin. Käyttäjälähtöiseen lean-tyyppiseen kehitykseen se on loistava. Kanbanissa on helppo vaihtaa ominaisuuksien prioriteettejä tai lisätä uusia jos niin haluaa tehdä. Eli ei tarvitse päättää alussa mitä haluaa lopussa - se usein muuttuu jos haluaa tehdä parhaan mahdollisen. Jos aika tulee vastaan, voi jättää mahdollisesti ominaisuuksia pois. Ensimmäiset käyttöliittymäluonnokset kannattaa piirtää niin aikaisin kuin mahdollista, jotta kaikki tietävät suunnilleen mitä ollaan tekemässä. Sovellusta on tietenkin helpoin koodata kun design on valmis aikaisin, mutta jos designia tai käyttöliittymää tarvitsee muuttaa niin on turhauttavaa tehdä se monesti. Alussa toiminnallisuuden kehitys on kuitenkin tärkein. Bugeja ja korjauksia tarvitsee tehdä yllättävän paljon. Rennohko ilmapiiri saa aikaan positiivisen työskentelykokemuksen. Sooloilijat vaikuttavat muuhun ryhmään negatiivisesti. Kaverin auttaminen parantaa ryhmähenkeä. Asenne alussa ratkaisee lopussa. Kohtalaisen vaikeaa on olla samaan aikaa projektipäällikkönä ja designerina. Palvelimen vastausaika ja yleinen vasteaika ovat järkyttävän suuri osa sovelluksen käyttökokemusta. Kun kysyy käyttäjiltä niin ei tarvitse arvailla mitään. Arne Tällä kurssilla olen saanut lisää kokemusta ketterästä ohjelmistokehityksestä sekä nähnyt miten hankala yksi feature kerrallaan kuntoon -lähestymistapa käytännössä on (asioissa on aina riippuvuuksia jne.). Valitettavasti puhtaasta Kanban-ajatuksesta luovuttiin heti kättelyssä - sitäkin olisi ollut mielenkiintoista kokeilla. 8
Lisäksi olen päässyt kehittämään hybridimobiiliapplikaatiota, oppinut AngularJS-tekniikkaa ja nähnyt TDD:n vahvuudet ja heikkoudet. Pekka Eero Teemu Oskari Opin, että arkkitehtuurin suunnittelu on mahdotonta, jos ei tiedä mitä ollaan tekemässä. Lisäksi opin, ettei suurempia toiminnallisuuksia kannattaa lähteä toteuttamaan puutteellisilla tiedoilla, koska tämä johtaa lähes väistämättä turhaan työhön. Olemalla tiukempi ja kyseenalaistavampi olisin välttänyt turhaa työtä, mutta tämä olisi voinut aiheuttaa konflikteja. Koen ymmärtäväni nyt paremmin hybridiapplikaatioiden vahvuuksia ja heikkouksia. Opin hieman enemmän hybridapplikaatioiden tekemisestä ja varsinkin hybridapplikaatioiden heikkouksista ja rajoituksista. Android kehitykseen tuli hieman lisää rutiinia. Tutustuin ketterään ohjelmistokehitykseen ja sain käytännön kokemusta ohjelmiston kehityksestä. Opin myös käyttämään AngularJS:ää ja muita työkaluja. En kurssin alussa oikein tiennyt, mitä kurssilta haluan tai mitä tulisin kurssin aikana tekemään, joten listasin tavoitteisiini Android-kehityksen ja responsiivisten nettisivujen kehityksen sekä hybridiapplikaatioista oppimisen. Android-kehitystä kurssilla ei juurikaan tehty ja responsiivisten sivujen kehityksestäkään ei paljon tullut opittua. Hybridiapplikaatioiden ongelmista ja lähestymistavoista opin kuitenkin enemmän kuin odotin ja opin myös paljon AngularJS:ää. Odotan molempien alueiden tietojen tulevan hyvään käyttöön tulevaisuudessa. Tuomas Lauri Tulin kurssille olettaen että pääsisin opettelemaan pääasiasssa Android-kehitystä. Näin ei kuitenkaan käynyt mutta opin kuitenkin runsaasti erilaisista web-teknologioista, joista minulla ei kurssia ollut käytännössä mitään kokemusta. Lisäksi pääsin näkemään miten versionhallinta hoituu vähän isommassa projektissa Git:n ja GitHubin kautta. Kurssin alussa listasin tavoitteiksi oppia JavaScript-koodin järkevä jäsentäminen ja testaaminen sekä projektien kehittäminen Angular.js:llä. Näihin tavoitteisiin myös kurssin puitteissa mielestäni hyvin pääsin. Angular tuli tutuksi ja siitä sai hyvän työkalun myös tuleviin projekteihin. Oli myös mukava havaita Angular koodin testattavuus, vaikka itse testaamiseen en niin paljoa ehtinyt perehtyä kuin olisin halunnut. Kurssilla 9
tuli selväksi myös yhteisen devauspäivän ja GitHubin pull requestin hyödyllisyys. Joni Pääsin mielestäni hyvin kurssin alussa asettamiini tavoitteisiin, joissa kerroin tavoitteekseni oppia lisää HTML-, CSS- ja JavaScript-tekniikoiden käytöstä. Tämän lisäksi Gitiä tuli käytettyä kurssin aikana paljon ja kehityin sen käyttämisessä. 5. Kurssipalaute Palaute käytiin läpi suullisesti mentor tapaamisessa ja retrospektiivissä mentorin läsnäollessa. 10