Etusivu

Lataa PDF-versio

Sisällys:

  1. Johdanto
  2. Sulautettujen järjestelmien ketterät kehitysmenetelmät
  3. Tekniikkakatalogi
  4. Yritysesimerkit
  5. Lisätiedot

Keskustele ja kommentoi:

Yritysesimerkit

Nextfour

29251.png

Nextfour on sulautettujen järjestelmien suunnitteluun ja kehitykseen erikoistunut yritys. Nextfour kehittää tuotteita erityisesti lääketieteen ja teollisuuden tarpeisiin kattaen ohjelmisto-, elektroniikka- sekä mekaniikkasuunnittelun.

Nextfourilla tehtiin noin kahden kuukauden mittainen tuotekehitysprojekti, jossa kokeiltiin ketteriä käytäntöjä sulautettujen järjestelmien tuotekehityksessä. Projektiin osallistui kaksi elektroniikkasuunnittelijaa, neljä ohjelmistosuunnittelijaa sekä sisäinen asiakas.

Esiselvitysprosessi ja ketteryyden kehittäminen

Yrityksen lähtötilanne kartoitettiin haastatteluilla, kyselytutkimuksella sekä tutustumalla yrityksen prosesseihin. Esiselvityksessä keskityttiin käytettyyn tuotekehitysprosessiin, asiakasrajapintaan, testaukseen sekä palautteeseen. Tämän perusteella päätettiin lähteä selkeyttämään tuotekehitysprosessia, joka jo lähtötilanteeltaan oli melko ketterä, muttei riittävän selkeä tai yhtenäinen.

Projektin alussa yrityksessä oli jo käytetty ketteriä menetelmiä. Käytäntöinä iteraation suunnittelu oli tuttu ja projektinhallintatyökalu Trac oli yleisesti käytössä kehitysjonon hallinnassa. Tämän lisäksi projekteissa oli käytössä kolme erilaista kehitysjonoa, jotka ohjasivat tuotteen kehitystä.

Ketteriä käytäntöjä kokeiltiin syksyllä 2013. Käytäntöjä käytettiin kahden viikon iteraatioissa noin kahden ja puolen kuukauden ajan. Toteutettu projekti oli oma kokonaisuutensa. Ennen projektin alkua vanhaa kehitysprosessia muokattiin määrittelemällä uudet projektivaiheet. Käytännössä vanhaa prosessia selkeytettiin ja yksinkertaistettiin liittämällä tuotteen verifiointi kiinteäksi osaksi itse tuotekehitystä, kuten jo käytännössä oli aiemmin osittain tehty.

Pilotoidut käytännöt

Kehitystiimi otti käyttöön päivittäiset tilannepalaverit , jotka pidettiin joka päivä samaan aikaan. Palaveri pidettiin lyhyenä ja tekemisen etenemistä seurattiin päivittäin iteraatiokohtaisen edistymiskäyrän  avulla.

Jokaisen iteraation päätteeksi pidettiin katselmointipalaveri , jossa käytiin läpi iteraation aikana saavutetut tavoitteet. Palaverissa projektin etenemistä esiteltiin tuote­prototyypin avulla asiakkaalle silloin, kun se oli mahdollista. Vaatimuslista käytiin läpi asiakkaan kanssa ja lista priorisoitiin asiakkaan toiveiden mukaisesti kehitystiimin avulla. Vaatimukset suljettiin tai hyväksyttiin asiakkaan kanssa yhteisesti sovittujen kriteerien avulla. Projektin etenemistä seurattiin iteraation katselmoinnissa etappikehitysjonon avulla.

Iteraation suunnittelupalaveri  oli jo projektin alussa vakiintunut ja hyvin toimiva käytäntö. Siksi käytäntöön haettiin vain pieniä parannuksia. Jokaiselle vaatimukselle määrättiin omistaja, joka oli kyseisestä vaatimuksesta vastuussa. Omistaja jakoi vaatimuksen työtehtäviin ja arvioi alustavasti tehtävien suorittamiseen vaadittavan ajan. Tämä arvio täsmennettiin yhteisesti tiimissä ja käytettiin työmääräestimaattina suunniteltaessa iteraation kehitysjonoa.

Retrospektiivi  otettiin käyttöön uutena käytäntönä. Siinä keskityttiin tiimin työskentelytapojen parantamiseen. Tiimin jäsenet pohtivat, mitä tehtiin hyvin ja mitä käytäntöjä kannattaa jatkaa. Lisäksi arvioitiin, mitä pitäisi parantaa ja mikä estää tiimiä toimimasta parhaalla mahdollisella tavalla. Arviointien tukena käytettiin ketteryyden tarkistuslistaa . Listan avulla oli mahdollista käydä tehokkaasti läpi kaikki käytännöt, joita oli sovittu kokeiltavan tai joita harkittiin otettavan kokeiltavaksi.

Yleisesti tunnettujen tuote- ja iteraation kehitysjonojen  lisäksi projektiin oli jo valmiiksi vakiintunut käyttöön etappikehitysjono. Etappi- sekä tuoteen kehitysjonoon kerättiin tuotteen vaatimukset. Tuoteen kehitysjonosta otettiin osa vaatimuksista etappikehitysjonoon. Etappikehitysjonon aikataulu määräytyi ulkoisista tekijöistä, kuten yleisistä tuotteen esittelytilaisuuksista. Tällöin yhteen etappikehitysjonoon kerättiin ne vaatimukset, jotka olivat kyseisellä ajanjaksolla tärkeimmät. Iteraation kehitysjono tarjosi näkyvyyttä projektin etenemisestä iteraation sisällä.

Projektissa oli jo valmiiksi käytössä iteraatiokohtainen edistymiskäyrä. Merkittävä uudistus oli ottaa mukaan myös etapin edistymiskäyrä, jossa näkyi ainoastaan kyseisen etapin aikana suoritetut ja jäljellä olevat vaatimukset. Tämän avulla koko projektiin saatiin huomattavasti parempi näkyvyys.

Projektinhallintatyökalu ohjasi tiimin toimintaa vahvasti. Työkalua kehitettiin projektin aikana joustavammaksi ja yksinkertaisemmaksi käyttää. Merkittävin muutos työkaluun tuli projektin seurantaan liittyen; koko projektin näkyvyys vaatimustasolla edesauttoi ymmärtämään tehdyn ja tekemättömän työn määrän.

Havainnot ja kokemukset

Tiimin itseorganisoituvuus ei toiminut projektin alussa johtuen epäselvistä vastuun rajoista. Tämä esti tiimiä toimimasta tehokkaasti, eikä muutoksia saatu tehtyä hyvin projektin alussa. Projektin aikana tilanne muuttui ja tiimi pystyi tekemään itsenäisiä päätöksiä omista toimintatavoistaan. Tämän seurauksena oleellisimmat ja suurimmat muutokset saatiin projektissa tehtyä ja ne selkeyttivät tiimin toimintaa sekä lisäsivät tyytyväisyyttä tiimissä. Suurin muutos oli se, että työmäärää kyettiin seuraamaan koko projektin laajuudessa. Lisäksi säännölliset palaverit selkeyttivät projektin etenemistä ja iteraation katselmoinnissa asiakkaan tarpeet saatiin tehokkaammin tiimin tietoon.


Päivitetty: 22.01.15 13:33

Jaa: