Uusi blogi www.ketteryys.fi
06.01.2010 | Lare Lekman | Kommentoi
Uuden vuosikymmenen kunniaksi aloitin kirjoittaa ketteryydestä omassa erillisessä blogissa, joka löytyy osoitteesta http://ketteryys.fi.
Tervetuloa lukemaan, kommentoimaan ja kehittämään ketteryyttä.
Ohjelmistokehityksen katsastus™ julkaistu
05.10.2009 | Lare Lekman | 1 Kommentti
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.
Ketterät palvelut: Heroku
05.10.2009 | Vesa Vänskä | Kommentoi
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.
Mikä ihmeen Kanban?
26.09.2009 | Lare Lekman | Kommentoi
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.
Scrum on suomeksi Rinki
13.09.2009 | Lare Lekman | 6 Kommenttia
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?
| Scrum | Rinki |
| Daily Scrum | Päivän rinki |
| Sprint | Jakso |
| Sprint Planning Meeting | Jakson suunnittelukokous |
| Sprint Review Meeting | Jakson arviointikokous |
| Sprint Goal | Jakson tavoite |
| Retrospective | Jälkiviisastelu |
| Sprint Burndown Chart | Jakson työkaavio |
| Product Burndown Chart | Tuotteen työkaavio |
| Sprint Backlog | Jakson työjono |
| Product Backlog | Tuotteen työjono |
| Backlog Item | Työ |
| Task | Tehtävä |
| Product Owner | Tuoteomistaja |
| Refactoring | Uusintapuuhastelu |
| ScrumMaster | Rinkimestari |
| Scrum Team | Rinkiryhmä |
| User Story | Käyttäjätarina |
| Velocity | Nopeus |
| Focus Factor | Nopeuskerroin |
Agile Finlandin aiempaa keskustelua »
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.
The Scrum Game
15.10.2008 | Lare Lekman | Kommentoi
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.
Kasvata tuottavuuttasi
19.09.2008 | Lare Lekman | Kommentoi
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.
Teho vs. tuottavuus
19.09.2008 | Lare Lekman | Kommentoi
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.