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.
Osoitella.com päivittää yhteystietosi
23.09.2009 | Lare Lekman | Kommentoi
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
Vesa Vänskä Resiinan kahvaan
23.09.2009 | Lare Lekman | 2 Kommenttia
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.
Idealist Group ja Resiina yhteistyöhön
16.09.2009 | Lare Lekman | Kommentoi
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.
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 »
Resiina on ketterin!
10.09.2009 | Lare Lekman | Kommentoi
Ketterän Pikakurssin™ suorittaneet kommentoivat päättynyttä kurssia.
Valmentaja voi vain vahvistaa yksimielisen havainnon…
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.
