Ketterä kehitys: ainutlaatuinen prosessi

Ketterä kehitys tarkoittaa meillä sitä, että onnistunut lopputulos muodostuu viimeiseen asti hiotusta toimintamallista, joka mahdollistaa tehokkaan ohjelmistokehitystyön. Prosessimme perustuu kolmeen periaatteeseen, niistä voit lukea lisää alempaa.

Ketterä kehitys: prosessimme kolme periaatetta

1.

Maksumme perustuvat tehtäväpohjaisiin maksuihin. Emme käytä tuntihintoja, emmekä kiinteitä kuukausipalkkoja.

2.

Kaikesta projektiviestinnästä jää jälki. Koko kehitystiimi pysyy hyvin perillä työn etenemisestä. Kehitystyö on läpinäkyvää.

3.

Projektipäällikkö on vastuussa kaikesta – hän huolehtii, että kokonaisuus on teknisesti, aikataulullisesti ja kustannuksiltaan sovitunlainen.


Pitkälle automatisoitu

Ketterä kehitys: näiden ylempänä mainittujen periaatteiden noudattamiseksi ja ohjelmistokehityksen tehostamiseksi olemme luoneet automatisoituja robotteja, jotka auttavat projektinhallintaa. Robotit muun muassa avaavat uusia tehtäviä, osoittavat tehtävän sopiville ohjelmistokehittäjille ja käsittelevät maksut tehtävän sulkemisen yhteydessä.

Jotta projekti onnistuu, myös projektipäällikön rooli on aivan välttämätön. Tehokas projektin läpivienti vaatii kokonaisuudesta vastaavan ammattilaisen, joka on aina Devolutionin palveluksessa. Projektipäällikkö tekee keskeiset hankkeeseen liittyvät päätökset ja ohjaa tiimiä.

Ketterä kehitys nojaa tehtäväpohjaisiin maksuihin

Tärkein ero meidän kehitysprosessin ja staattisemman status quo -kehitystyylin välillä on se, kuinka korvaamme kehitystyön avustajillemme ohjelmistokehitysprojekteissa.


Devolutionin ohjelmistokehitysprosessi

Devolution Oy on kehittänyt ainutlaatuisen ohjelmistokehitysprosessin. Prosessi nojaa kolmeen perus eriaatteeseen:

  1. Palkanmaksu tulee tehdystä työstä
  2. Projektikommunikointi tapahtuu välineillä, joista jää jälki
  3. Projektipäällikkö vastaa kaikesta.

Ohjelmistorobotiikan ja läpinäkyvien käytäntöjen avulla olemme luoneet uuden tavan toteuttaa ohjelmistoprojektit. Ohjelmistorobotit huolehtivat kehitystehtävien hallinnasta, jolloin projektipäällikölle jää aikaa tehdä arvoa luovaa työtä. Älykkäät robotit myös mahdollistavat tehtävien pilkkomisen “mikrotaskeiksi”, mikä luo asiakkaalle läpinäkyvyyttä, selkeyttää kehittäjän työtä ja luo pohjan tehtäväperusteiselle palkanmaksulle.

Toisin kuin tavallisissa kehitysmalleissa, Devolutionin prosessissa kehittäjille maksetaan palkka suoritettujen tehtävien mukaan. Kehittäjät saavat palkkansa toteuttamalla tehtäviä, avaamalla uusia tehtäviä, löytämällä virheitä sekä pyytämällä selkeytystä annettuihin tehtäviin.

Kehitysprosessimme etenee siten, että projektipäällikkö kuvaa loppukäyttäjän käyttötilanteen sekä ensimmäiset tehtävät. Projektipäällikkö valitsee tehtäville tarvittavat osaamiskyltit, joiden perusteella ohjelmistorobotti jakaa tehtävät niiden toteuttajille. Toteuttaja luo pienimmän mahdollisen edistysaskeleen kohti toteutettavaa ominaisuutta.

Lisäksi hän merkkaa seuraavat askeleet TO DO-lipuilla. TO DO -lipuista ohjelmistorobotti luo seuraavat tehtävät, jotka menevät projektipäällikölle tarkistettavaksi. Projektipäällikkö voi halutessaan tehdä muutoksia tehtävään ja tarkentaa tehtävän kuvausta.

Kehittäjä saa palkkionsa, kun hänen koodinsa hyväksytään versionhallinnan master-haaraan. Olemme vieneet hyväksyntäkriteerit korkealle, mutta toisaalta olemme kirjanneet ne ylös kaikkien nähtäville taataksemme kehittäjien turvan sekä edistääksemme asiakkaidemme luottamusta.

Meillä kehittäjän ei tarvitse arvailla, mitä hän on tekemässä. Epäselvissä tapauksissa kehittäjä voi pyytää lisäselvitystä projektipäälliköltä. Vaikka projektipäälliköllä on kaikki valta, on hän myös velvoitettu perustelemaan ratkaisut ja kommunikoimaan näistä. Toinen periaatteemme sanoo, että projektikommunikointi on oltava jäljitettävissä.

Lue lisää

Ketterä kehitys on yhteistyötä. Ohjelmistoja tehdään ja kehitetään yleensä tiimeissä, joten kommunikaatio on ensiarvoisen tärkeää. Devolutionin mallissa kaikki projektikommunikaatio pitää olla näkyvissä. Informaatiokatkokset ovat yksi suurimpia syitä hukkaan ja epäonnistuneisiin projekteihin. Devolutionissa käytämme projektikommunikaatioon projektinhallintatyökalujamme. Pääsääntöisesti käytämme GitHubia projektinhallintaamme.

Koska projektipäällikkö on velvoitettu perustelemaan päätökset, hän pitää huolta, että kaikki ohjelmistoon liittyvä kommunikointi on helposti saatavilla ja löydettävissä. Agile-periaatteiden mukaan emme halua käyttää aikaamme dokumentteihin, joita kukaan ei koskaan lue, sen sijaan olemme integroineet viestinnän osaksi kehitysprosessiamme.

Ohjelmiston dokumentointiin käytämme automaattitestiä, arkkitehtuuriratkaisujen taustat löytyvät tehtäväkuvauksista sekä projektin wikisivulta. Vastatessaan asiakkaiden ja kehittäjien kysymyksiin, projektipäällikön on viitattava projektin dokumentaatioon. Jos dokumentaatiota ei ole, projektipäällikkö luo sen.

Usein on tarpeen, etenkin asiakaskommunikoinnissa, selventää asioita myös kasvotusten, puhelimella tai pikaviestintäalustoilla. Tällöin on vaarana, että luotu informaatio hukkuu. Sääntömme määrää tekemään tiivistelmän käydyistä keskusteluista projektinhallintatyökaluun. Ollaksemme täysin läpinäkyviä, myös asiakkaalla on pääsy projektinhallintatyökaluihimme.

Prosessimme rakentuu projektipäällikön ympärille. Vaikka teetämme suuren osan työstä ulkopuolisilla toimijoilla, jokaisessa projektissa on Devolution Oy:n oma projektipäällikkö.

Hän vastaa siitä, että projekti noudattaa Devolution Oy:n projektikäsikirjaa ja etenee asiakkaan kanssa sovittuun päämäärään. Projektipäällikön rooli vastaa osittain Scrumista tuttua tuoteomistajan roolia, mutta myös yhtä lailla ohjelmistoarkkitehdin roolia.

Suoriutuakseen tehtävästään, projektipäällikön on oltava teknisesti asiantunteva henkilö, mutta ennen kaikkea hänellä on oltava kyky delegoida ja pyytää apua. Koska oikeiden ratkaisujen valinta on edellytys ohjelmistoprojektin onnistumiselle, pitää projektipäällikön osata kysyä apua, eikä vain luottaa omaan näkemykseen.