Ketterä konsultti kertoo keveästi kehittämisestä ja kokonaisarkkitehtuurista
Lean-ajattelu ja ketterät menetelmät ovat tulleet vahvoina mukaan ohjelmistoprojekteihin, mutta laajempien kokonaisuuksien hallintaan ei vielä ole vakiintuneita toiminta-tapoja. Samoin ketterät menetelmät tuovat uusia haasteita kokonaisarkkitehtuurin tekemiseen.
Ketterä ohjelmistokehitys (Agile Software Development, ASD) nostaa asiakkaan tarpeen täyttämisen toimivan ohjelmiston kautta tärkeimmäksi arvoksi. Samalla ketteryys antaa asiakkaalle mahdollisuuden muuttaa mieltään ja hioa ratkaisua paremmaksi nopeilla toimituksilla. Toisaalta vastuu kokonaisuuden ymmärtämisestä jää pitkälti tuoteomistajan taakse.
Lean-kehitys (lean-development) taas tähtää kaiken turhan työ eliminointiin. Turhaksi työksi lasketaan myös ennenaikaisesti valmistuneet välituotokset. Toinen olennainen osa Lean-periaatteita on kokonaisuuden ymmärtäminen ja sen jatkuva kehittäminen. Lean on siis enemmänkin tapa ajatella asioita, kuin varsinainen menetelmä toteuttamiseen.
Kokonaisarkkitehtuuri (tai yritysarkkitehtuuri, KA) on työkalu jäsentää kokonaisuutta. Mielestäni KA-mallit ovat mainioita työkaluja tuon kokonaiskuvan rakentamiseen ja ylläpitämiseen, mutta kokonaisuuksista keskusteltaessa KA-kehys on aivan liian tarkka.
KA-kehyksestä kannattaa poimia toiminnan kannalta oleelliset kohdat ydinkaavioon (core diagram). Tämä yhden sivun kuva toimii mainiosti nemawashin, lean-ajattelun konsensuksen, rakentajana. KA-tuotokset on siis mahdollista esittää muutenkin kuin plunttana paperia. Toyotallakin, jota pidetään yhtenä Lean ajattelun merkittävimmistä kehittäjistä, päätökset tehtiin yhden A4:n perusteella, mihin oli tiivistettynä kaikki oleellinen.
Monimutkaisen kokonaisuuden puristaminen yhteen sivuun on työlästä. Usein tuntuukin kuin jokin oleellinen yksityiskohta jäisi kertomatta. Todellisuudessa asia on kuitenkin lukijan kannalta toisin, esiin nousevat vain tärkeät asiat, kun turha hälinä jää pois. Taustalla on tietysti paljon näkymätöntä työtä, jotta oleellinen on saatu tiivistettyä. Mutta näkymätön ei ole tarpeetonta. Oman kokemukseni mukaan juuri tuo työ on perusta sekä sitouttamaiselle että viestinnälle, joita kollegani Erkki (arkkitehtuurin arvo syntyy viestinnastä) ja Juha (mallinna pohdi sitoututa päätä) ovat omissa kirjoituksissaan kattavasti käsitelleet.
Ihannoi kevyttä, suunnittele rauhassa ja toteuta ketterästi.
Oman kokemukseni mukaan edellä mainitut menetelmät sopivat hyvin yhteen ja tukevat toisiaan. Menetelmät perustuvat laajalti samanlaisiin / samoihin ideologioihin ja perimmäinen tavoite asiakas- arvon tuottamisesta on sama. Menetelmillä on vain oma soveltamisalueensa, rajauksensa, jossa ne toimivat. Samoin kuin istutuslapio ja kaivinkone, molemmilla voi kaivaa, mutta ne eivät ole järkeviä samoissa töissä.
Itse olen jäsentänyt menetelmät seuraavasti. Aluksi tarvitsemme päämäärän eli missä haluamme olla pitkällä tähtäimellä. Seuraavaksi omista arvoistamme rakentuu linjaukset, kuinka haluamme päämäärän saavuttaa. Tälle tasolle voidaan nostaa myös kehittämisen ideologioita, kuten esimerkiksi edellä mainittu Lean.
Seuraavaksi tarvitsemme tietoa, tiedon keräämiseen käy oivasti KA-mallit, kuten esimerkiksi Kartturi. Malli antaa meille tukea tiedon jäsentämiseen järkeviksi kokonaisuuksiksi ja yleensä myös neuvoo millaista tietoa tarvitaan. Mallin avulla voidaan myös haarukoida kehitettävät alueet / kohteet.
Sitten se hankala kohta. Tarvitaan päätös mistä aloittaa. Korkean tason päätöksiin sopii pohjaksi hyvin ydinkaavio tai nemawashi-tyyppinen lähestyminen, jossa oleellinen tiivistetään ymmärrettäväksi, helposti kommunikoitavaksi kokonaisuudeksi yhdessä sidosryhminen kanssa. Yleensä nämä ’oleelliset asiat’ ovat juuri niitä, joiden kehittämistä halutaan ylätasolla seurata.
Okei, meillä on päätös, ja eikun tekemään. Tässä vaiheessa innostuneisuus tarttuu ja kaikki haluavat päästä tekemään ja kokeilemaan. Agile-menetelmät ovat tässä aivan mainioita, koska arvon tuottamisesta saadaan havaintoja jo hyvin varhaisessa vaiheessa.
Tässä tekemisen huumassa arkkitehtuurin ylevät periaatteet usein hämärtyvät, jopa unohtuvat. Agile-kehitys vaatii arkkitehdeiltä kurinalaisuutta; täytyy vahvasti pitää kiinni niistä oleellisista, tärkeistä päätöksistä, jotka alussa linjattiin. Toisaalta agilen työtavat vaativat vahvaa osallistumista, edestä johtamista. Ohjelmistokehittäjien heimo kun pitkälti noudattaa meritokratian periaatteista tekemisessään. Mikäli tuoteomistaja ei tässä vaiheessa huolehdi myös ratkaisun suhteesta kokonaisuuteen ollaan vaarallisilla vesillä. Yksittäinen projekti voi edelleen onnistua mainiosti, mutta se ei täytä paikkaansa kokonaisuudessa.
Fanfaarien soidessa juhlitaan kehitystyön tulosta. Kaikki ovat tyytyväisiä ja homma on valmis. Mutta hetkinen ei tämä ollut vielä tässä. Maljapuheissa on syytä katsoa peruutuspeiliin. Mitä opimme? Mikä meni hyvin? Mikä huonosti? Mitä voimme tehdä paremmin? Näiden oppien kanssa lähdetään taas uudelle kierrokselle Demingin ympyrää.
Lähteet:
Lean principles – http://en.wikipedia.org/wiki/Lean_software_development
The Agile Manifesto – http://www.agilemanifesto.org/principles.html
Jeanne W. Ross, Peter Weill, David Robertson, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution http://www.amazon.com/Enterprise-Architecture-Strategy-Foundation-Execution/dp/1591398398
Jeffrey Liker, The Toyota Way, http://www.amazon.com/The-Toyota-Way-Management-Manufacturer/dp/0071392319
Rodríguez Pilar, COMBINING LEAN THINKING AND AGILE SOFTWARE DEVELOPMENT HOW DO SOFTWARE-INTENSIVE COMPANIES USE THEM IN PRACTICE http://urn.fi/urn:isbn:9789526203324
Nemawashi – http://en.wikipedia.org/wiki/Nemawashi
Ronald D. Moen, Clifford L. Norman, Clearing up myths about the Deming cycle and seeing how it keeps evolving www.apiweb.org/circling-back.pdf
Guy Sereff, Orbus software, esitys, The Agile Enterprise Architect – Working effectively with Sprint Teams, Backlogs and Scrum Masters
