Takaisin blogosfääriin

 Perustin uuden blogin. Ajattelin kirjoittaa sinne ainakin kerran vuosikymmenessä.

SAFe saapui Vantaalle

Aloitin englanniksi kirjoitussarjan SAFesta (Scaled Agile Framework). Päätimme tänä vuonna ryhtyä levittämään ketteriä menetelmiä koko liiketoimintayksikköömme ja käytämme tässä apuna SAFe-mallia. Mielenkiintoisia kuukausia edessä!

Nyt myös englanniksi

Bloggaan nyt myös englanniksi, toistaiseksi vasta Windows 10 ‑narinoita, mutta kohta ehkä myös liiketoimintayksikkömme ketteröinnistä.

Bugit pois Lean Six Sigmalla?

Ensimmäinen Lean Six Sigma -harjoitukseni on loppusuoralla: jäljellä on enää vaikein osa eli parannusten keksiminen ja aikaansaaminen! Projektini aiheena on ollut ohjelmistovirheiden ehkäiseminen ja havaitseminen. Edellisissä vaiheissa kaivoimme dataa muutostietokannasta ja versionhallinnasta sekä tutkimme virheiden juurisyitä ja niiden esiintymistä ohjelmiston eri osissa.

Mitä mieltä olen Lean Six Sigmasta? Kokemuksen syvä rintaääni syntyisi vasta usean erityyppisen projektin myötä, mutta pari ajatuksenraakiletta sallittakoon:

DMAICin kaltainen vaihemalli tuo ryhtiä parannushankkeeseen: osapäiväiset projektit tuppaavat hiipumaan hiljaa pois alkuinnostuksen jälkeen, jollei niillä ole selvää rakennetta.

Päätöksenteon perustuminen faktoihin ja tilastotieteeseen eikä mieleenjuolahduksiin on kaunis periaate, mutta Six Sigman tilastolliset menetelmät jäivät omassa hankkeessani vähälle käytölle, koska dataa ei ollut ihan tarpeeksi. Lisäksi ohjelmistovirheet ovat alttiita tulkinnalle: Mikä on virhe, mikä puuttuva ominaisuus? Onko virheet kuvattu samalla tavalla kaikissa projekteissa? Miten erilaisia juurisyyanalyyseja syntyisi, jos saman datan antaisi analysoitavaksi kahdelle eri porukalle? Vähäinenkin data voi silti estää hyttysen ampumisen tykillä.

Käytänkö Lean Six Sigmaa seuraavassa parannushankkeessani? Aika näyttää.

Vihreän vyön metsästys

Olen viime aikoina tutkaillut Lean Six Sigmaa, jonka käyttö on laajentunut muualla firmassamme. Tämä menetelmähän on yhdistelmä japanilaislähtöistä lean-ajattelua sekä Motorolan ja GE:n kehittämää Six Sigmaa. Sillä pyritään parantamaan yrityksen toiminnan nopeutta ja lopputulosten tasalaatuisuutta, ja   loppujen lopuksi tietenkin myös asiakkaan ja osakkeenomistajan tyytyväisyyttä.

Onko kenelläkään kokemuksia Six Sigman käyttämisestä tuotekehityksessä? Oma vihreä vyöni on vielä hankkimatta, mutta pienen itseopiskelun perusteella näyttää siltä, että tämän menetelmän lean-osuutta on helpompi soveltaa tuotekehitykseen, esimerkiksi Scrum-tiimien työnkulun nopeutukseen. Six Sigmassa on iso työkalupakki erilaisia matemaattisia menetelmiä, mutta miten moni niistä sopii muuhun kuin tuotannon tehostamiseen?

Kaikki parannusmenetelmät ovat oikeastaan jonkin pelon torjuntaa. Mitä menetelmän valinta kertoo valitsijasta?

• CMMI vs. kaaos ja epärationaalisuus
• Lean vs. tuottamaton ajankäyttö
• Six Sigma vs. hutilointi
• Scrum vs. väärien asioiden tekeminen ja yhteistyön puute

My Excellency

How did Scrum affect different aspects of the project?

Vaihdoin maanantaina toimenkuvaa ja titteliä: melkein yhdentoista vuoden rupeama ohjelmistokehityspäällikkönä on ohi, ja keskityn nyt yksikkömme tuotekehityksen parantamiseen. (Mitä hieman koominen titteli R&D Excellence Manager voisi olla suomeksi?) Nyt pitää vain hillitä intoaan ja miettiä suurempia linjoja eikä vain syöksyä heti yksittäisten parannuskohteiden kimppuun.

Vantaan-yksikkömme on nyt muuttumassa nopeasti, kun kasvamme ja kehitämme Sonalleve MR-HIFU -tuotteen rinnalle uutta liiketoimintaa. Kaksi ohjelmistokehitystiimiämme on käyttänyt Scrumia vuoden ajan, ja kokemukset ovat olleet enimmäkseen myönteisiä: ensimmäisen projektin jälkeen kukaan ei olisi halunnut palata vanhaan toimintatapaan, vaikka Scrumin päivärytmi onkin välillä tuntunut liian intensiiviseltä vanhaan viikkopalaverikäytäntöön verrattuna. Nyt pääsen tarkastelemaan koko tuotekehityksen toimintatapoja ja miettimään niiden parantamista. Mielenkiintoisia aikoja edessä!

Scrum ja jäljitettävyys

Jäljitettävyys vaatimuksista versionhallintaan

Lupasin kirjoittaa Scrumin taipumisesta lääkintälaitteiden kehittämisessä vaadittavaan jäljitettävyyteen. Meillä on oltava vaatimustenhallinta-, riskinhallinta-, muutoksenhallinta-, versionhallinta- ja testauskäytännöt, joiden tuotokset on linkitettävä toisiinsa standardien ja viranomaisvaatimusten mukaisesti. Tärkeimmät jäljitettävyystyökalumme ovat DOORS, ClearQuest ja Subversion.

Kuvittelin tässä aiheessa olevan enemmän pureskeltavaa, mutta oikeastaan Scrum ei ole toistaiseksi muuttanut jäljitettävyysketjujamme miksikään, vaan vain tuonut niiden hallintaan uutta selkeyttä: vaatimuksia on päivitettävä sprintin tehtävälistan mukaan, ja ketjujen on oltava kunnossa joka sprintissä. Scrumin teemat ja käyttäjätarinatkin mäppäytyivät aika mukavasti vanhan muutostietokantamme kaksitasoiseen rakenteeseen.

Isoin haaste puhtaalle iteratiivisuudelle tuntuu olevan lääkintälaitealan mallien mukainen lopullisen tuotteen testaus. Sprinttien aikana testaamme tietenkin kaikki muutokset, mutta hankkeissamme on käytännössä pakko olla erillinen julkaisusprintti, jonka aikana periaatteessa julkaisuvalmis tuote käy vielä läpi kattavan regressiotestauksen. Onkohan kukaan lukijoistani (sikäli kuin teitä on :) löytänyt tähän kevyitä ratkaisuja? Testauksen automatisointi voi tietysti keventää taakkaa, mutta kaikkea emme pysty automatisoimaan.

Ensimmäinen sprintti takana

Eka neljän viikon Scrum-sprintti sujui paremmin kuin odotimme: kumpikin tiimi saavutti tavoitteensa, vaikka tarinoiden valinta ja pilkkominen ei mennytkään vielä ihan putkeen. Kehittäjät taisivat puhua tuotteen ominaisuuksista ja teknisistä ratkaisuista tämän kuukauden aikana enemmän kuin parin aiemman vuoden aikana yhteensä. Osa porukasta koki kuitenkin päivittäisen tehtävien läpikäynnin mikromanageeraukseksi ja tiimin itseorganisoituvan toimintatavan kaoottiseksi, ja tavat ovat selvästi vasta muotoutumassa: esimerkiksi Definition of Done oli tässä sprintissä vielä pikemminkin vanhan projektiorganisaation Scrum-tiimeille laatima tarkistuslista kuin tiimien omistama dokumentti.

Tarina on vasta alussa ja rotkokin ylitettävänä alkuinnostuksen jälkeen. Ensi kerralla muutama sana Scrumista ja lääkintälaitteiden kehityksessä vaadittavasta jäljitettävyydestä.

Ensikosketukseni Scrumiin

”Scrum = Variation of Evolutionary Delivery + some additional practices.” Näin tyhjentävästi analysoin Scrumin esityksessäni Äyritien ohjelmistoryhmälle elokuussa 2002.

Olin tavannut edellisessä työpaikassani Tom Gilbin, Obi-Wan Kenobia muistuttavan vaatimustenhallintagurun, ja tutustunut tämän Evolutionary Delivery -malliin, joka oli jonkinlainen ketterien menetelmien kantamuoto jo 1970–1980-luvulla. Kun sitten selailin Schwaberin ja Beedlen kirjaa Agile Software Development with Scrum, ihmettelin, mitä uutta tässä nyt oikein oli Evo-malliin verrattuna. Vasta paljon myöhemmin aloin ajatella, että inkrementaalinen ohjelmistokehitys taitaa vaatia toimiakseen juuri jonkinlaiset fiksut tiimikäytännöt. Ihmettelen silti vieläkin, miksei Gilbiä mainittu tuon Scrum-kirjan lähdeluettelossa.

Miksi aloimme siirtyä inkrementaaliseen ohjelmistokehitykseen vasta tänä vuonna? Olin kai laiska kärsivällinen enkä halunnut yrittää puskea mallia käyttöön ylhäältä annettuna vaan odottaa ensin kriittisen massan syntymistä kehittäjien joukossa. Lisäksi Philipsissä oli käynnissä aikaa ja energiaa vienyt CMM- ja CMMI-pohjainen prosessinkehityshanke. Mutta parempi myöhään!

Ensi kerralla vaikutelmia ensimmäisestä sprintistämme, joka päättyy parin viikon kuluttua.

Vanhakin nyt ketteröityy

Huomaan, etten ole kirjoittanut aikoihin ohjelmistotuotannosta, mutta tänä syksynä kertyy kerrottavaa. Kyllästyimme nimittäin keväällä ohjelmistoprojektiemme lopussa olleeseen stabilointihässäkkävaiheeseen ja mietimme, millä siitä pääsisi eroon. Oikealta lääkkeeltä vaikutti iteratiivinen ja inkrementaalinen ohjelmistokehitys, jossa hässäkät jaetaan pieniksi palasiksi matkan varrelle eikä julkaisukelpoisesta laadusta koskaan erkaannuta liian kauaksi.

Kesän aikana päätimme sitten nauttia seuraavassa projektissamme Scrumia suoraan purkista. Monen yrityksen Scrum-toteutus näyttää karahtaneen siihen, että mallista on otettu vain omassa firmassa helpoiten toteutettavat osat (esimerkiksi niin, että tuotteen omistajan roolia ei ole hoitanut yksi ihminen vaan sama komitea kuin ennenkin), mutta me päätimme lähteä liikkeelle ihan oppikirjatoteutuksella. Oman pikantin lisänsä tuovat lääkintälaitteen jäljitettävyysvaatimukset ja IEC 62304 -standardi, mutta oikeastaan niiden noudattaminen on monin osin helpompaa, kun projektin lopussa tapahtunut kiireinen dokumentointityö jakautuu tasaisemmin koko projektin ajalle. Veikkaan, että suurin haaste on vanhojen rakenteiden ja ajattelutapojen muuttaminen kuten missä tahansa muussakin ketteriin menetelmiin siirtyvässä yrityksessä.

En ole itse mukana Scrum-tiimissä, vaan roolini on enemmänkin sponsorin, mutta kerron silloin tällöin kokemuksiamme tässä blogissa. Tiimit on muodostettu, ensimmäiset pokerit pelattu Tukholmasta tilatuilla korttipakoilla ja Sonalleve MR-HIFU -ohjelmiston työlista hahmottunut, mutta ensimmäinen sprintti on vielä edessä. Mielenkiintoinen syksy tulossa!

Oulunkylän kirjasto uudistui

Kyllä minä niin mieleni pahoitin, kun kävin Oulunkylän kirjastossa remontin jälkeen. Kirjojen määrä on kai puolitettu, ja tilalle on kannettu matalia designhyllyjä, oleskeluryhmiä ja videopelejä. Vanhassa kirjastossa oli tämmöisen keski-ikäisen lukijan mukava samoilla kaikessa rauhassa korkeiden hyllyjen välissä kirjanselkämyksiä pää kallellaan tiiraillen, mutta tästä monitoimitilasta tulee heti kiire pois, ennen kuin joutuu nuorison pilkan kohteeksi.

Kyllä ei ainakaan Rikhardinkadun kirjastoon pidä päästää uudistajia mellastamaan.

Ps. Toki pipopäilläkin pitää olla joku vetelehtimispaikka, etteivät tee pahojaan kadulla.

Laatu alkaa kotelosta

Terve, Stephen Elop! Tässä on helppo projekti lokakuuksi: pane kuntoon Nokian kännykkäkotelot.

Kuvassa on Nokia E75:n kotelo vajaan vuoden käytön jälkeen. Sisustan liimaukset repsahtivat muutamassa viikossa, ja sivusauma alkoi irvistellä tänä kesänä. Kävisi muuten pienestä käsilaukusta, mutta hihna saisi olla jämäkämpi ja aukko yläpuolella.

Seuraavaksi sitten ohjelmistojen laadun kimppuun!

Sonalleve MR-HIFU

Monen vuoden mittaisen tuotekehityshankkeen jälkeen on hauska päästä vihdoin linkittämään oman yksikön tuotteeseen: Philipsin Sonalleve MR-HIFU sai oman kotisivunsa. Tuotteen ensimmäisenä käyttökohteena ovat kohdun myoomat (uterine fibroids). HIFU-menetelmästä voi lukea lisää vaikkapa Wikipedian artikkelista High-intensity focused ultrasound.

Parhaan yrityswikin metsästys

Olen viime päivinä vertaillut eri yrityswikiohjelmistoja. Yrityswikin tärkein ominaisuus vaikka MediaWikiin verrattuna on mielestäni se, että wikin eri osiin pitää pystyä asettamaan erilaiset pääsyrajoitukset. Lisäksi wikin pitää olla helposti muokattava myös niille, jotka eivät vapaaehtoisesti wikittäisi (WYSIWYG-vaihtoehto?). Liitetiedostojen fiksu käsittely on myös toivottavaa.

Australialaisen Atlassianin Confluence on käytössä monessa suomalaisessakin organisaatiossa ainakin yliopistomaailmassa. Atlassianin sivustoa selailemalla saa heti käsityksen, mitä on ostamassa, ja Confluencella pystyy nopeasti pystyttämään mukavan pikku wikin. Ohjelmistossa on kuitenkin joitakin ikäviä puutteita ja bugeja, joiden paikkaaminen tuntuu kestävän, esimerkiksi taulukoiden solujen yhdistäminen, sekoilut muokkaustilasta toiseen siirryttäessä ja Office 2007 -dokumenttien indeksoinnin puute. Onko ohjelmiston perusrakenteessa heikkouksia, jotka vaikeuttavat joidenkin ominaisuuksien lisäämistä? Miten Confluence skaalautuu, jos käyttäjämäärä kasvaa ja tarpeet lisääntyvät?

MindTouch oli minulle uusi tuttavuus. Ensi vaikutelma firman sivustosta oli puppusanojen paljous: ROI sitä ja enterprise class tätä, mutta missä voin nähdä ihan oikeasti, miltä se näyttää? Community Portal -wikistä löytyi onneksi vähän konkreettisempaa tietoa. Wiki vaikuttaa varsin asialliselta, ja laajennettavuus esimerkiksi mashup-tekniikoilla näyttäisi olevan MindTouchin vahvuuksia: se ei ole pelkkä wiki, vaan tarkoitettu yleiseksi intranet- tai ekstranetohjelmistoksi. Yllättävintä oli se, että wikissä ei ole omaa syntaksia, vaan sivujen sisältö tallentuu XHTML-muodossa. Mutta miksi en ole kuullut MindTouchista aiemmin?

TWiki on ilmainen, mutta sen hieman nörttimäinen olemus ja RCS-pohjaisuus mietityttävät. Olisiko oikea tietokanta kuitenkin luotettavampi vaihtoehto?

Myös Microsoft SharePointissa on olevinaan sisään rakennettu wiki, mutta ainakin Windows SharePoint Services 3.0:ssa se on kovin köykäinen: sivuja pystyy luomaan ja linkkejä lisäämään, mutta siinä (melkein) kaikki wikimäisyys. SharePoint on yhä ensisijaisesti Office-dokumenttien muokkaus- ja varastointipaikka.

Mikä olisi paras vaihtoehto nyt ja kolmen vuoden päästä? Ja olenko vielä huomannutkaan sitä parasta vaihtoehtoa? Pähkäily jatkuu.

Synonyymit taipuvat myös englanniksi

Microsoft kertoo Office Natural Language Team -blogissaan, että Microsoft Office 2010:een on tulossa taivuttava englannin synonyymisanasto. Kauan siinä menikin! Vastaava suomen synonyymisanasto, josta kirjoitin aiemmin, on ollut mukana Officessa jo 1990-luvulta asti, mutta se taisi olla edellä aikaansa, eikä Microsoft tainnut ominaisuutta silloin liiemmälti hehkuttaakaan.

Pihakirppis Koskelantie 29:ssä sunnuntaina 7.6.

Taloyhtiömme historian (tai ainakin tämän vuosituhannen) ensimmäinen pihakirppis järjestetään Koskelantie 29:n pihalla Helsingin Käpylässä sunnuntaina 7.6.2009 klo 10–13. Tavaraa lapsille ja aikuisille! Kahvia ja pullaa! Tervetuloa!

Lippu.fi jumissa, dinosaurukset asialla?

Yritin tänä aamuna ostaa lippuja dinosaurustapahtumaan, mutta muillakin taisi olla sama aikomus: Lippu.fi on ollut jo monta tuntia jumissa. Ilmeisesti koko palvelu pitäisi hajottaa atomeiksi ja rakentaa uudelleen pilven päälle, jotta tilapäinen kapasiteetin kasvatus onnistuisi? Hassua, että tapahtumanjärjestäjät valitsevat näin toimimattoman myyntikanavan, mutta kaipa heille on pääasia, että kaikki liput menevät kaupaksi.

Säästyvätpähän rahat (hinta oli suolainen), mutta tytär saattaa pettyä.

Minäkin huudan: Ei katua Kumpulanlaaksoon!

Kun kävelen kesällä Mäkelänrinteeltä kotiin, mutkan jälkeen eteen avautuu lempimaisemani: edessä leppoisa ruohokenttä ja vehreä Kumpulanmäki, oikealla Kumpulan kartano ja vasemmalla pienet puutarhapalstat. Mieli lepää ja stressi katoaa.

Mikä on idyllisen puistoalueen arvo? Kaupunginhallituksen mielestä viiden minuutin nopeutus yliopistoalueelle vievään bussilinjaan on tärkeämpää: lempipaikkani on halkaisemassa joukkoliikennekatu.

Onneksi en ole ainoa kitisevä esteetikko, vaan muutamassa päivässä on saatu aikaan jo ainakin Facebook-ryhmä Ei katua Kumpulanlaaksoon ja Laakson henki -blogi. Taistelu on alkanut, ja jollei muu auta, kuoritaan vaikka katu pois vaalien jälkeen!

Tämä sivusto voi vahingoittaa tietokonettasi

Google alkoi tänään yhtäkkiä ilmoittaa, että kaikki löytyneet sivustot voivat vahingoittaa tietokonettani. Onko Internet vallattu (”all your site are belong to us”?), vai onko joku nörttiparka vain kammennut vivun väärään asentoon Googlen konehuoneessa?

Ultraäänellä kasvaimia vastaan

En ole tainnut viime vuosina hiiskahtaakaan kehittämistämme tuotteista, mutta nyt Philips Healthcaren MR-HIFUsta on jo jonkin aikaa puhuttu julkisesti, joten uskallan raottaa salaisuuden verhoa: kehitämme terapialaitetta, joka tuhoaa kasvaimia kohdennetulla ultraäänellä. Toimenpidettä ohjataan magneettikuvauslaitteen avulla. Ensimmäisenä kohteenamme ovat kohdun myoomat.

HIFU-hankkeemme on mielestäni myös kiehtovimpia Suomessa viime vuosina tehtyjä ohjelmistokehitysprojekteja. Tällaisen lääketieteellisen laitteen kehittäminen vie vuosia, ja ohjelmiston koodirivien määrä taitaa kasvaa tälläkin kertaa seitsennumeroiseksi, joten tuotteen arkkitehtuurin pitää olla tiptopkunnossa. Hankkeen kuluessa on pitänyt ratkaista useita haastavia tieteellisiäkin ongelmia, ja lisäksi kaikissa suunnitteluvaiheissa on muistettava potilasturvallisuus. On tämä ollut mielenkiintoisempaa kuin jokin Facebook-kikkareiden kehittäminen (vaikka kaikki kunnia niille)!