Tehtävänanto (lyhennetty): Olet menestyvän KillerApp-ohjelmiston kehitystiimissä ja sinulle on annettu tehtäväksi kehittää jaksotettu (time-paced) ketterä ohjelmistonkehitysprosessi ohjelmistolle, jotta sen kehittäminen olisi ketterämpää ja ennustettavampaa kuin nykyinen ns. build-and-fix-and-react-to-whatever-marketing-wants-today -prosessi. Kirjoita ehdotus, kuinka toteuttaisit tämän ketterän ohjelmistokehitysprosessin. Essee arvosteltiin asteikolla 0-10 p. Essee oli osa Teknillisen korkeakoulun kurssin T-76.3601 Ohjelmistotuotannon perusteet suorittamista.

Essee 2 - Ohjelmistoarkkitehtuuri ja ketterä ohjelmistokehitys (Software Architecture and Agile Development)

Päätin uudistaa tuotteen ohjelmistokehityksen käyttämällä Pressmanin kirjassaan Software Engineering esittämiä ketteriä ohjelmistokehitysmalleja Extreme Programming (XP) sekä Scrum.

Kun tuotteen vaatimukset on ensin kerätty ja priorisoitu, järjestetään ne Scrum-mallin tapaan sopivan kokoisiin toteutuseriin. Toteutuserän kesto pidetään melko lyhyenä, esim. 3 viikkoa. Näin saadaan tuotteen kehitys jaettua pienempiin, helpommin hallittaviin osasiin. Toteutuserät asettavat myös selkeitä alitavoitteita, jotka motivoivat kehitystiimin jäseniä. Tavoitteena on aina lisätä edellisiin toteutuseriin uusia ominaisuuksia ja toimittaa asiakkaille testattavissa oleva tuote uusilla ominaisuuksilla. Tästä on hyötyä niin asiakkaille kuin kehitystiimillekin.

Asiakkaat voivat testata tuotetta ja antaa kehitystiimille palautetta, jonka perusteella voidaan tehdä muutoksia seuraaviin toteutuseriin. Asiakkaiden tyytyväisyys on aina etusijalla. Kehitystiimin on myös helpompi seurata ja ennustaa tuotteen kehitystä, kun toteutettavat ominaisuudet tehdään pienissä erissä. Tällöin voidaan tarkastella, kuinka monta haluttua ominaisuutta saatiin toteutettua edelliseen toteutuserään ja sen perusteella muuttaa tarvittaessa seuraavien toteutuserien työmäärää karsimalla toteutettavia ominaisuuksia. Näin saadaan huomattavasti enemmän ennustettavuutta projektin aikatauluun ja asiakkaille luvattu toimiva tuote voidaan toimittaa sovittuna aikana. Aikataulua ei muuteta, vaan tuotteen ominaisuuksia karsitaan, jos ollaan aikataulusta jäljessä. Ominaisuuksista karsitaan ensisijaisesti ne, joille on asetettu pienin prioriteetti. Karsitut ominaisuudet voidaan tehdä myöhempään julkaisuun, jos tuotetta edelleen kehitetään.

Toteutuserän aikana kyseisen toteutuserän vaatimukset pidetään jäädytettyinä, jotta tiimillä olisi työrauha. Seuraavien toteutuserien vaatimuksiin voidaan kuitenkin tehdä yhä muutoksia. Jokaisen toteutuserän lopuksi arvioidaan tilanne: mitä saatiin aikaan, ovatko seuraavien toteutuserien vaatimukset muuttuneet ja näiden perusteella suunnitellaan seuraavan toteutuserän aikataulu. Näin saadaan vastattua muutokseen paljon tehokkaammin kuin aikaisemman build-and-fix-and-react-to-whatever-marketing-wants-today -mallin mukainen sekasorto.

XP:n mukaisesti ennen varsinaisen ominaisuuden implementointia kirjoitetaan testit, jolloin ominaisuuden toimivuutta voidaan testata. Testien perusteella voidaan sanoa, milloin toteutettu ominaisuus toimii eikä saada vain summittaisia "joo, tää on ehkä noin 90 % valmis" -arvioita. Näin on helpompaa arvioida, milloin toteutettavat ominaisuudet ovat valmiina ja pitääkö joku ominaisuus jättää myöhemmäksi, koska sitä ei keretä nyt tekemään valmiiksi.

XP:n tukena päätin käyttää myös scrum-mallissa esitettyjä lyhyitä tapaamisia. Tarkoituksena on pitää joka päivä noin 15 minuutin mittainen tapaaminen kehitystiimin jäsenten kesken. Jokainen tiimin jäsen kertoo tapaamisessa, mitä on saanut aikaan, mitä tekevät seuraavaksi ja onko kehityksessä ilmentynyt jotain ongelmia. Kaikki saavat näin selvän kuvan, missä ollaan menossa ja voivat auttaa toisiaan ongelmissa. Tapaamiset luovat myös tasaisen rytmin ohjelmistokehitykseen ja auttavat tiimin sisäisessä kommunikoinnissa.

Lähteet:

• Pressman. 2005. Software Engineering: A Practitioner's Approach, 6th edition. McGraw-Hill. 912 s. ISBN 007-123840-9.