Hävitä oma ohjelmistoarkkitehtuuri
25.03.2009 | Lare Lekman | 2 Kommenttia
Oma ohjelmistoarkkitehtuuri on jätteen salakavala ilmentymä, jota tarvitaan todellisuudessa ehkä yhdessä projektissa sadasta. Ellei yrityksenne kehitä avaruussukkulan ohjelmistoa, pärjäätte todennäköisesti loistavasti alan parhailla käytännöillä ja tunnetuilla sovelluskehyksillä.
Pyörän uudestaan keksiminen on asiantuntijoiden märkä uni, mutta bisnekselle se voi olla tuhoisan kallista. Oma arkkitehtuuri sitoo ratkaisun kehittäjiinsä, joilta sitten vaaditaan tekninen arkkitehtuurikuvaus selvittämään kuinka viritys toimii. Kun joku ei sittenkään arvosta ratkaisun hienouksia, on vika tietenkin kuulijassa. Eniten rahaa poltetaan kehittämällä “joustavaa arkkitehtuuria”, josta murto-osa tulee lopulta käyttöön. Valtavan jätevuoren lisäksi kasvavat ylläpitokustannukset, jatkokehityksen monimutkaisuus ja dokumentoinnin sekä koulutuksen tarve.
Ketterä kehitys suhtautuu arkkitehtuuriin kriittisesti: Kaikki mikä ei tuota asiakkaalle lisäarvoa on jätettä. Yksinkertaisen määritelmän mukaan omaa ohjelmistoarkkitehtuuria kannattaa välttää kuin ruttoa. Arkkitehtuuria onkin opittu kehittämään ketterästi vain siinä laajuudessa, kuin on tarpeen kehitysjaksossa vaadittujen ominaisuuksien toteuttamiseksi.
Tuottavin vaihtoehto on hävittää oma arkkitehtuuri kokonaan. Tämä on mahdollista valitsemalla valmis sovelluskehys ja tunnettu arkkitehtuuri, joista löytyy kattava ja aktiivisesti ylläpidetty dokumentaatio. Näin oman arkkitehtuurin lisäksi katoavat teknisen perimätiedon ja dokumentaation tarve.
Esimerkiksi Ruby on Rails on MVC-arkkitehtuuria käyttävä sovelluskehys verkkopalveluiden nopeaan kehittämiseen. Jokainen sovellus sisältää identtisen hakemistorakenteen ja arkkitehtuurin ajatuksella convention over configuration, joten verkkopalvelun dokumentoimiseksi riittää periaatteessa tämän kappaleen linkit. Kehitystiimin tarvitsee vain sopia yhtenäisestä koodauskäytännöstä, jonka jälkeen voidaan keskittyä oleelliseen eli asiakkaiden lisäarvon tuottamiseen.
Ketterässä kehityksessä ohjelmistoja ei rakenneta helposti muokattavaksi vaan ne säilytetään yksinkertaisina ja helposti muokattavina. Hävitä rohkeasti oma arkkitehtuurisi, ellei sen kehittämisellä ja ylläpidolla saavuteta mittavaa lisärvoa.
Ketterää lukemista
02.03.2009 | Lare Lekman | Kommentoi
Henrik Knibergin Scrum and XP from the Trenches - How we do Scrum on monesta syystä suositeltava kirja aloitteleville sekä edistyneemmille ketterille tiimeille, ScrumMastereille ja tuoteomistajille.
Ensinnäkin kirja on kunnioitettavan lyhyt, vain 127 sivua suurella fontilla ja selkeällä kuvituksella. Kirja tulee siis helpommin luettua, varsinkin kun se pureutuu heti alusta mainostamaansa asiaan - “How we do Scrum”. Ketterien menetelmien toteuttamisessa ongelmana on harvemmin tiedon puute, vaan sinänsä yksinkertaisten menetelmien käytännön soveltaminen kehitystiimin, asiakkaan ja yrityksen parhaaksi. Tähän kirja on hyvä lääke erityisesti kehitystiimien osalta.
Henrik antaa runsaasti konkreettisia esimerkkejä, kuinka Scrum ja eXtreme Programming (XP) -menetelmät kannattaa käytännössä toteuttaa tiimitasolla. Vaikka yhden kehitystiimin ratkaisut eivät välttämättä sovellu kaikkiin ohjelmistokehityksen ongelmiin, antaa kirja mainion lähtökohdan oman ketterän kehitysformaatin ja -kulttuurin luomiseen.
Uusimman PDF-version voi ladata ilmaiseksi rekisteröitymällä InfoQ-käyttäjäksi. Suosittelen myös tilaamaan helpommin luettavan pokkariversion parilla kympillä esimerkiksi Amazonista.
