Blogi

Uuden vuosikymmenen kunniaksi aloitin kirjoittaa ketteryydestä omassa erillisessä blogissa, joka löytyy osoitteesta http://ketteryys.fi.

Tervetuloa lukemaan, kommentoimaan ja kehittämään ketteryyttä.

Onko ohjelmistokehityksenne toistuvasti myöhässä tai lopputulokset muuten vaan epätyydyttäviä?

Syynä voi olla hapantunut kehitysprosessi tai ohjelmistokehitystä ymmärtämätön johtoporras. Resiinan ilmainen Ohjelmistokehityksen katsastus selvittää ongelmat muutamassa minuutissa 25 kysymyksen patterilla, jonka täyttämiseen kuluu ajastasi 5-10 minuttia.

Viiteen kategoriaan jaettuihin kysymyksiin vastataan neljällä eri vaihtoehdolla. Tulossivu kertoo selkeästi saavutetut pisteet (suurin pistemäärä 100) sekä sijoituksen muihin katsastettuihin yrityksiin nähden. Testin suorittaneiden nimet pidetään luonnollisesti täysin luottamuksellisina.

Ohjelmistokehityksen katsastusta hyödynnetään myös Resiina-Pikahuollon™ asiakkaiden lähtötason mittaamiseen.

Ketteryyttä ei kannata rajoittaa ohjelmistokehitykseen ja yritysjohtoon vaan hyödyntää myös verkkosovellusten infrastruktuuri-tasolla. Erilaiset pilvipalvelut ovat joissain käyttötapauksissa huomattavasti perinteisiä hosting-ratkaisuja hyödyllisempiä.

Juuri julkaistu Resiinan Ohjelmistokehityksen katsastus toimii Heroku-alustalla. Heroku on ketterä sovellusalusta Ruby-pohjaisten verkkosovellusten ajamiseen. Se tähtää nopeuteen ja helppouteen sovellusten pystytyksessä ja ylläpidossa. Heroku standardoi tietyt peruspalaset verkkosovelluksen ajamiseen, ja kunhan nämä palaset sopivat kehitettävälle sovellukselle, on Herokun käyttäminen todella virtaviivaista. Lisäksi Amazonin skaalautuvaan infrastruktuuriin pohjautuminen mahdollistaa verkkosovellusten ajamiseen käytettävien resurssien säädön kätevästi suoraan Herokun verkkopohjaisesta hallintapaneelista.

Uuden verkkopalvelun julkaisu Heroku-alustalla onnistuu muutamalla komentorivikomennolla:

→ heroku create katsastus
→ git add .
→ git commit -m "Initial commit"
→ git push heroku
→ heroku open


Aluksi luodaan uusi Heroku-projekti. Sitten lisätään projektin tiedostot versionhallintaan, minkä jälkeen heroku open-komento avaa julkaistun projektin oletusselaimessa.

Herokun rakenne ylläpidettynä palveluna itse kontrolloidun järjestelmän sijaan tekee siitä joillain tavoin rajoittuneen, mutta se tukee jo mainiosti erilaisia tuotantojärjestelmiltä vaadittuja ominaisuuksia kuten SSL-suojausta, varmuuskopioita, erillistä tietokantaserveriä ja tehtävien tausta-ajoa.

Tutustu Herokuun ja Resiinan Ohjelmistokehityksen katsastukseen.

Japaninkielinen sana kanban on suomeksi näkyvä taulu.

Kanban-menetelmä sisältää vain kolme sääntöä, jotka voi osin ajatella Scrumin laajennuksena. Samalla tavalla pariohjelmointia (XP) ja testivetoista kehitystä (TDD) on jo vuosia käytetty täydentämään Scrumin kolmea roolia, kolmea seremoniaa ja kolmea dokumenttia.

Kanbanin kolme sääntöä:

• Pilko työt sopivankokoisiin tehtäviin
• Kirjaa kukin tehtävä paperilapulle ja kiinnitä laput kanban-tauluun
• Kuvaa taulun sarakkeilla missä työvaiheessa kukin tehtävä on

2. Määritä WIP (work in progress) taulun jokaiselle sarakkeelle. WIP tarkoittaa suurinta määrää tehtäviä, joita kyseisessä sarakkeessa saa kerrallaan olla, jottei sarakkeeseen kasaantuva työ hidasta muita työvaiheita.

3. Laske tehtävien läpimenoajat (Lead time, keskimääräinen aika yhden tehtävän valmistumiseen). Optimoi sitten prosessia ja kokeile erilaisia WIP-arvoja läpimenoajan ja ennustettavuuden parantamiseksi.

Scrumin ja Kanbanin ero on siinä, ettei Kanban sisällä kehitysjaksoja, vaan suunnittelupalavereita pidetään aina tarvittaessa ja ohjelmistosta julkaistaan uusi versio heti kun pienin markkinoitava ominaisuusjoukko valmistuu. Näin Kanban-taulu ei koskaan tyhjene vaan pysähtyy viikonlopuksi kuin liukuhihna.

Kanban sopii mielestäni luontevimmin tilanteeseen, jossa jatkuvasti muuttuvaa työn sisältöä on mahdotonta lukita edes yhdeksi viikoksi. Esimerkiksi ohjelmiston ylläpidossa voitaisiin Kanbania käyttää reagoimaan lähes välittömästi käyttäjien vikailmoituksiin. Tästä esimerkistä tosin herää kysymys kannattaisiko laatuun kiinnittää huomiota jo kehityksen aikana…

Ennen Kanbanin toteutusta kannattaa arvioida tarvitseeko muutoksiin todella reagoida päivittäin, ja mitä suoria ja epäsuoria vaikutuksia tällä on. Jos samalla luovutaan Scrumin tasapitkistä jaksoista, saatetaan kadottaa osa työn tavoitteellisuudesta, kun kehitysjaksolle määriteltävä tavoite ja ajan loppumisen tunne jäävät pois. Suunnittelu- ja arviointikokouksiin voi myös olla vaikeampaa osallistua, kun kokousaikaa ei etukäteen voida varata, ja julkaisuaikoja voi olla hankalaa ennustaa suuremmalle projektille. Tuoteomistajan tulee lisäksi olla ketterä kuin gaselli sopeutuakseen töiden jatkuvaan “syöttämiseen”, ellei Selected-sarakkeen työjonoon (kts. kuva alla) aseteta niin korkeaa WIP-arvoa, että tuoteomistaja ehtii välillä tehdä muutakin.

Haasteista huolimatta Kanbanille löytynee käyttökohteita. Hopealuoti Kanban ei kuitenkaan ole ja ennen sen toteutusta kannattaa ketterän kehityksen perusteet harjoitella kuntoon vaikkapa Scrumilla.

Kuva on Henrik Knibergin loistavasta PDF-kirjasta Kanban vs Scrum, joka on toiminut tämän kirjoituksen pohjana. Kiitos Henrik.

Resiinan ensimmäinen verkkopalvelu on henkilökohtainen automaattisesti päivittyvä osoitekirja, joka julkaistaan myöhemmin osoitteessa osoitella.com.

Osoitella eroaa muista osoitepalveluista kolmella merkittävällä tavalla. Näistä kolmesta eroavaisuudesta julkaistaan tarkempaa tietoa Resiinan blogissa syys-lokakuussa. Pysy siis kanavalla!

Lisäämällä sähköpostiosoitteesi julkaisulistalle saat kertaluonteisen sähköpostin, kun Osoitellan ensiversio julkaistaan. Sähköpostiosoitteita ei käytetä mihinkään muuhun.

Tervetuloa mukaan : )

Resiinan kehitystiimi

Metropolia-ammattikorkeakoulusta valmistunut verkkoviestinnän medianomi Vesa Vänskä (os. Nieminen) siirtyi Resiinan osakkaaksi ja työntekijäksi 1.9.2009.

Aiemmin Vesa työskenteli osa-aikaisena Star Wreck Studios Oy:llä kehittämässä palkittua  Wreckamovie.com -elokuvapalvelua Ruby on Rails -sovelluskehyksellä, jota Resiina hyödyntää verkkopalveluhankkeissaan.

“Vesa tuo Resiinalle rautaista osaamista, asennetta ja pumppukättä”, sanoo toimitusjohtaja, ketteryyskouluttaja Lare Lekman.

Resiina jatkaa edelleen läheistä yhteistyötä Star Wreck Studiosin kanssa.

Ideoiden tuotantoyhtiö Idealist Group ja Resiina Oy aloittavat yhteistyön. Idealist Groupin perustajina ovat Broadcasters-tuotantoyhtiön perustajat Saku Tuominen ja Juha Tynkkynen sekä Katja Lindroos ja Jaakko Kievari.

“Idealist ideoi, toteuttaa ja auttaa muita ideoimaan ja toteuttamaan. Yhtiön missiona on parantaa maailmaa yksi idea kerrallaan. Pelkkä idea ei kuitenkaan yksin riitä, vaan lisäksi tarvitaan erinomainen toteutus”, sanoo Saku Tuominen.

Resiinan urakkana on toteuttaa Idealistin ja sen asiakkaiden ideoimat digitaalisen median konseptit. Näin Resiinan palvelut laajenevat ketterien kehitysmenetelmien valmennuksesta ja huollosta vuorovaikutteisten verkkosovellusten tuottamiseen. Tähän lanseerataan palvelu, jolla ideasta tuotetaan käyttövalmis verkkosovellus kymmenessä työpäivässä.

Yhteistyön myötä Resiina Oy muuttaa Idealist Groupin kanssa yhteisiin toimitiloihin Helsingin keskustaan.

Lisätietoja antavat Resiinan toimitusjohtaja Lare Lekman, 040-849 5117 ja Idealist Groupin toimitusjohtaja Jaakko Kievari, 050-554 3551.

Siluettitaiteilija Sirkka Lekman leikkaamassa siluettia Idealist Groupin toimitusjohtajasta Jaakko Kievarista Esplanadilla.

Käytämme usein englanninkielisiä sanoja, vaikka hyviä kotimaisiakin on tarjolla. On jotenkin hienompaa tai kansainvälisempää tehdä bisnestä, pitää presentaatio, esittää agenda, lähettää meiliä ja olla agile. Esimerkkejä riittää.

Scrumin osalta voisimme siirtyä selvään suomenkieleen. Alla muutamia käännöksiä, joita olemme makustelleet Resiinan koulutuksissa ja yhteistyökumppaneiden kanssa. Tuleeko mieleesi paranettavaa?

Agile Finlandin aiempaa keskustelua »

Ketterän Pikakurssin™ suorittaneet kommentoivat päättynyttä kurssia.

Valmentaja voi vain vahvistaa yksimielisen havainnon…

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.

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.

The Scrum Game on Bill Waken ja Mike Cohnin vuonna 2007 kehittämä lautapeli Scrum-tiimien valmennukseen.

Peli kuvaa kymmenen päivän kehitysjaksoa, joka voitetaan tai hävitään aina joukkueena. Yhteistyö on siten yhtä tärkeää kuin todellisessa Scrum-projektissa.

Pelin tavoitteena on sulattaa 300 tuntia työtä ennen jakson päättymistä. Työmäärä voi pelin aikana myös lisääntyä, joka kuvaa työmääräarvioiden tarkentumista ylöspäin jakson aikana.

Osuttaessa mustaan yö-ruutuun merkitään jäljelläoleva työmäärä jakson työmääräkaavioon ja siirretään pelilaudan päivämerkkiä eteenpäin. Voittaakseen pelin tulee pelaajien saada työmäärä vähintään nollaan ja kiirehtiä Sprint Review -ruutuun ennen 10-päiväisen jakson päättymistä.

The Scrum Gamen pelilauta, nopat, kortit ja pelinappulat.

Pelin henki piilee tapahtumakorteissa. Punainen Impediment-kortti pysäyttää pelaajan etenemisen realistisilla ongelmilla, joita muut pelaajat voivat yrittää poistaa sinisillä työkalukorteilla, uhraten auttamiseen oman siirtovuoronsa.

Kultaiset Opportunity-kortit kuvaavat suurempia mahdollisuuksia tai ongelmia, joihin tulee keksiä yhteinen ratkaisu alle viidessä minuutissa. Jos pelaajat saavat Opportunity-kortin ratkaistua, he ansaitsevat yhden lisänopan noppasarjaansa, jonka summalla jakson työmäärää sulatetaan vihreissä ruuduissa. Näin tiimin tuottavuus kasvaa voitetuista haasteista saadun kokemuksen kautta.

Muutaman pelikerran palautteen perusteella The Scrum Game on opettavainen ja hauska peli, joka sopii hyvin Ketteryysvalmennukseen. Yksi peli kestää pelaajamäärästä (suositus 2-6 hlö) riippuen noin tunnin, kunhan joku opettelee pelin selkeät säännöt etukäteen. Peli helpottuu pelaajamäärän kasvaessa.

Työmääräkaavio pelille, jossa työt saatiin loppumetreillä valmiiksi.

Valmistuin sukelluskouluttajaksi pari kuukautta kestäneen kurssin päätteeksi. Kiinnostuin laitesukelluksesta kokeiltuani lajia Kreikassa vuonna 2001.

Yksi kouluttajakurssin opeista oli teorialuennon aloittaminen hätkähdyttävällä kysymyksellä, joka saa kuulijat hereille.

Vaativan kouluttajakurssin täkynä on lupa itsenäisesti kouluttaa ja sertifioida sukeltajia. Lisäksi opin tehokkaita koulutusmenetelmiä joista on hyötyä Resiinan palvelutuotteiden kehittämisessä, vaikka pysymmekin kuivalla maalla.

Jännittävä kaksipäiväinen Instructor Examination alkoi lauantaina 27.9. norjalaisen Astrid Ter Jungin johdolla Veikkolan Sukellusareenalla, jossa suoritimme teoriakokeet, opetuskokeen sekä allaskoulutuskokeen. Sunnuntaina suoritimme vielä Hangossa avovesikoulutuskokeen sekä pelastuskokeen, jotka onnistuivat suuremmitta kommelluksitta. Lämmin kiitos hyvästä opetuksesta ja valmennuksesta omalle kouluttajalleni JP Vuoriolle.

Touko-kesäkuussa 2009 koulutan todennäköisesti yhden Open Water Diver -peruskurssin sekä Advanced Open Water Diver -jatkokurssin viikonloppuisin pienille muutaman hengen ryhmille. Mikäli hauska, seikkailullinen ja turvallinen harrastus kiinnostaa, ota yhteyttä.

Star Wreck Studiosin Wreck-A-Movie voitti MindTrekin pääpalkinnon €20 008 sekä World Summit Awardsin Suomen edustuksen eCulture & Heritage -sarjassa.

Wreck-A-Moviessa kuka tahansa voi koota yhteisön oman elokuva- tai muun audiovisuaalisen projektin ympärille ja pyytää apua erilaisissa tuotantoon liittyvissä tehtävissä. Palvelu ei erottele “ammattilaisia” ja “amatöörejä”, vaan tärkeintä on halu osallistua.

Tunnelma Tampereen Ylioppilastalon MindTrek-iltajuhlassa oli mahtava. Star Wreck Studiosin tiukasta rahoitustilanteesta huolimatta olimme onnistuneet kehittämään voittoisan palvelun, joka on muutamassa kuukaudessa saavuttanut tuhat rekisteröitynyttä käyttäjää.

On nautinnollista tehdä yhteistyötä innovatiivisten, innostuneiden ja rautaisten osaajien kanssa. Erityinen kunniamaininta kuuluu Vesa Niemiselle, joka on kirjoittanut leijonanosan Wreckamovien koodista. Yhteistyö Vesan ja koko tiimin kanssa on mutkatonta ja samalla olen päässyt verryttelemään koodaustaitojani.

Wreckamovie on toteutettu Ruby on Railsilla, joka on nopea työkalu verkkopalveluiden kehittämiseen. Yhdistämällä tuottava kehitysympäristö ketterään Scrum-projektinhallintaan saatiin parissa kuukaudessa aikaan tärkeimmät toiminnot sisältävä palvelu, jonka kehitys jatkuu edelleen.

Kiitos kaikille käyttäjille ja kehitykseen osallistuneille. Tästä on hyvä jatkaa!

Onnelliset MindTrek 2008-voittajat: Vasemmalta Samuli Torssonen, Peter Vesterbacka, Timo Vuorensola, Vesa Nieminen, Atte Joutsen ja Lare Lekman.

On hyvä erottaa menetelmät ja niistä saatavat hyödyt. Muuten voi käydä kuten entiselle jääkauppiaalle, joka teki komean konkurssin myymällä sinnikkäästi jäätä kilpailijoiden jo siirryttyä jääkaappeihin. Asiakkaille hyöty oli ruoan säilöminen, ei jään kanssa lutraaminen.

Mitä hyötyä ketteristä menetelmistä sitten on?

Tuottavuuden kasvattaminen on vanhemmilla teollisuudenaloilla arkipäivää. Ohjelmistokehityksessä suurempi tuottavuus mahdollistaa mm. enemmän parempia ominaisuuksia, vähemmän virheitä, normaalit työajat, paremman myyntikatteen ja suuremmat palkat. Puhumattakaan kehitystiimin viihtyvyydestä, kun kehitysformaatti on virtaviivainen, toistuvat rutiinit on automatisoitu ja voidaan keskittyä asiakkaiden lisäarvoon.

Resiinan tuottavuuskuvio (PDF) esittää, kuinka ketterä kehitys voi jopa tuplata tuottavuutesi. Dokumenttia saa vapaasti tulostaa, jakaa ja kommentoida.

Lisäävätkö ketterät menetelmät työn tehoa vai tuottavuutta?

Wikipediassa ja peruskoulussa opetetaan, että teho on käytetyn energian määrä jossain ajassa.

Tehon määritelmä sopii hyvin koneille, jotka toistavat samaa tehtävää väsymättä. Siksi koneen tuottavuus on suoraan verrannollinen sen tehoon.

Ihmisille tehon käsite ei sovi, koska kaikki työaikana kulutettu energia ei automaattisesti muutu tuottavaksi työksi. Osa energiasta kuluu esimerkiksi torkkumiseen tai sellaisiin työtehtäviin, jotka ovat näennäisesti tärkeitä mutta eivät tuota firmalle tai sen asiakkaille lisäarvoa. Tällaista työtä kutsutaan hyvästä syystä jätteeksi.

Ohjelmistokehityksessä teho on erityisen hankala käsite, koska alan suurin haaste on building the right thing. Vaikka koodia vääntää täydellä teholla, projekti voi päättyä huonosti jos ratkaistaan väärää ongelmaa. Oikeaa ongelmaa ratkaiseva ohjelmistokehittäjäkin on useimmiten osa enemmän tai vähemmän energiaa vuotavaa prosessia. Työteho on siis puutteellinen käsite.

Wikipediassa opetetaan, että tuottavuus on tuotoksen määrän ja laadun suhde käytettyjen tuotantopanosten määrään ja laatuun.

Tuottavuus on ihmisen työskentelylle sopivampi määritelmä, koska se sisältää vapaan määrän muuttujia. Näin tuottavuus huomioi esimerkiksi ketterästä kehityksestä tutun priorisoinnin edut, jotka voivat ratkaista projektin onnistumisen tai epäonnistumisen.

Keskitytään siis tuottavuuden parantamiseen ja jätetään tehokkuus koneille.

Wordpressin asennus vaatii noin päivän työn. Tämän jälkeen paluuta staattisten verkkosivujen ylläpitoon ei ole, ainakaan ilman hyvää syytä.

Käyttöönoton pienet ongelmat selvisivät nopeasti palveluntarjoajan ja ystäväni Horppanan avulla. Suosittelen Wordpressiä lämpimästi verkkosivujen pyörittämiseen.