Kandiohjelmat

Lappeenrannan teknillisessä yliopistossa tapahtuu. Aiempi osastojako muuttuu tiedekuntamalliksi, joka tarkoittaa sitä, että nykyisen usean osaston malli muuttuu kolmen tiedekunnan malliksi. Kauppatieteellinen tiedekunta muodostuu nykyisestä kauppatieteen osastosta, tietotekniikan ja tuotantotalouden tiedekunta muodostuu, yllätys yllätys, tietotekniikasta ja tuotantotaloudesta ja kolmas tiedekunta on tekniikan tiedekunta, joka koostuu sähkötekniikasta, kemiantekniikasta, konetekniikasta, ympäristötekniikasta ja energiatekniikasta.

Opiskelijatasolla käytännössä eroa ei varmastikaan aivan heti ainakaan huomaa. Muutoksella pyritään kahteen asiaan: Näytetään opetusministeriölle, että täällä tehdään muutoksia ja ehkä aivan oikeastikin pyritään yhdistämään hallintoa. Alkuperäinen ideahan oli keventää byrokratiaa ja kaikkea managerointia. Vähentää hallintoportaita. No niin ei todellakaan käynyt, vaan portaita tuli lisää, ja yksinkertaistumisestakin voi olla montaa mieltä. Tai oikeastaan ei.

Opiskelijana yllä oleva ei niinkään ole kiinnostanut. Taistelkoon. LTY on ollut aina byrokraattien taivas, jossa hallintotehtävissä on paljon ihmisiä. Mutta nyt. Rehtorilla on idea: yhdistetään tulevien tiedekuntien kandidaatinohjelmat.

Pikainen kertaus niille, jotka eivät ole tutustuneet nykyiseen koulutusmeininkiin tekniikan alalla. Tutkinto muuttui muutama vuosi sitten kaksiportaiseksi, ensin valmistutaan tekniikan kandidaatiksi (joksi en valmistu täksi jouluksi, ihanan englanninopettajan Jukka Taipaleen takia) ja sitten tekniikan maisteriksi, eli diplomi-insinööriksi. Tällä hetkellä muutos ei ole oikeastaan vaikuttanut opiskeluun mitenkään, ennen suoritettu kurssi Erikoistyö on nykyään nimeltään Kandidaatintyökurssi ja siinä se. Jokaisella opiskelusuunnalla on oma kandiohjelma, eli jokainen lukee omia aineitaan kandidaattiin.

Mutta ei enää, jos rehtori saa päättää. Kandiohjelmat haluttaisiin yksinkertaistaa siten, että jokaisella tiedekunnalla olisi vain yksi kandiohjelma. Eli syntyisi vaan katikandeja, tite-tutakandeja ja tekniikan kandeja. Kuulostaa järjettömältä, etenkin tekniikan osalta, mutta myös tite-tuta osalta. Kuinka motivoit tuotantotalouden osastolle tulleen opiskelemaan väkisin tietotekniikkaa, algoritmien suunnittelua ja niin edelleen? Ja mikä on tarkoitus? Nopeutetaanko tällä valmistumisaikoja? Entä kun haluat tulla opiskelemaan ympäristötekniikkaa, kuuluuko kandidaatinopintoihin silti myös konetekniikan opintoja?

Yllättäen kaikki osastot vastustavat erittäin voimakkaasti rehtorin ajatusta. Muutenkin LTY:n rehtori Markku Lukka ei tunnu oikein nauttivan kenenkään luottamusta. Mutta myös muilta suunnilta on kuulunut ajatuksia, että kandiohjelmia pitäisi vähentää. Iskulauseeksi voisi kehittää Yliopistosta yleissivistävä!

No, saa nähdä mitä tapahtuu. Työsuhteeni onneksi loppuu joulukuun lopussa ja opiskelutkin varmaan jossain äärellisessä ajassa. Pelleilköön.

Ketterät menetelmät

Jostain syystä blogosfäärissä (tyhmä sana, siksi juuri käytän sitä) on puhuttu viimeaikoina useissa eri paikoissa ketteristä menetelmistä. Esimerkkinä otetaan Perse-Janne (kuten lehdistö ko. jamppaa puhuttelee) ja MBnetin net.nyt. Kirjoittajat kyllä tietävät mistä asiassa on kyse, mutta monille lukijoille ketterät menetelmät eivät ole tuttuja tai edes kiinnostavia. Kuitenkin kandidaatintyöni käsittelee ketteriä menetelmiä, kuten myös tämä työnkuvani täällä LTY:llä, joten koin tarpeelliseksi itsekin sanoa jotain, selvittää hieman asioita ja kertoa ehkä jotain uuttakin.

Ketterät menetelmät ovat siis ohjelmistokehityksen tapoja, usein niitä kutsutaan ohjelmistotuotannon menetelmiksi. Ne poikkeavat perinteisistä (kutsutaan myös formaaleiksi) menetelmistä hyvin erilaisten lähtökohtien vuoksi. Softaa ei suunnitella kerralla loppuun, kehitystä tehdään iteraatioissa (pienissä ’hyppäyksissä’) ja kehityksen aikaista dokumentointia vähennetään tehokkaalla sisäisellä viestinnällä. Ja mikä tärkeintä, testausta tehdään koko ajan, periaatteessa joka yönä käännetään uusi toimiva (joskin ominaisuuksiltaan todennäköisesti vajaa) versio ohjelmasta.

Agile Manifesto vuonna 2001 toi menetelmät rysäyksellä suuremman yleisön tietoon. He esittelivät idean lyhyesti ja ytimekkäästi. On tärkeämpää tuottaa laadukas ohjelmisto ajoissa, kuin nyhrätä byrokratian kanssa ja tehdä samoja asioita yhä uudelleen. On parempi mukautua siihen, että ohjelmistovaatimukset muuttuvat, kuin yrittää runnoa väkisin muutosta vastaan.

Suomessa ensimmäisiä yrityksiä, joka on lähtenyt täysillä ketteriin menetelmiin mukaan, on F-Secure (lue juttu). Toki tuon tiedon ilmestymisen jälkeen löytyi ties minkä kiven alta puku-ukkoja, jotka väittivät olleensa ketteriä jo vuosikymmeniä, mutta unohdetaan heidät. VTT ajaa Suomessa voimakkaasti ketterien menetelmien kehitystä ja käyttöönottoa.

There’s no silver bullet kuuluu joku nörttiläppä. Ja oikeassa on. Valheellisesti uutisoinnissa annetaan sellainen käsitys, että ketterissä menetelmissä ei ole mitään ongelmia. On niissä. Mutta ongelmat ovat erilaisia kuin perinteisissä vesiputousmalliin pohjautuvissa. Ne ovat voitettavissa olevia.

Varsinkin näin tuoreen ideologian ja menetelmän (-tavan toimia) kanssa ovat ongelmina tietysti ihmisten asenteet, opitut tavat ja niiden pois oppiminen. Unohtaminen. Mikä ikinä olisikaan hyvä sana. Ihmisten vastuualueet ja työtavat muuttuvat merkittävästi, kun ohjelmistotiimi vaihtaa perinteisestä toiminnasta ketteriin menetelmiin. Tiimit ovat itseohjautuvia, projektipäällikkö ei ole enää se ruoskija, vaan se, joka huolehtii asiakaskommunikaatiosta, seuraa ohjelmiston kehitystä, mittaa sitä ja keskustelee ja palaveroi joka päivä ohjelmistokehittäjien kanssa. Ylipäätään koko ketterät menetelmät -ideologiaa kuvaa yhteisöllisyys ja yhteistyöhalu. Perinteiseen protect the barriers systeemiin ei haluta lähteä ja siihen yritetään löytää vastakeinoja.

Asiakkaan osuus koko projektissa kasvaa huomattavasti. Useimmat ketterät menetelmät (erilaisia menetelmiä jotka luokitellaan ketteriksi on useita, jopa kymmeniä. (ks. agile.vtt.fi)) haluaisivat pitää asiakkaan edustajan jatkuvasti läsnä (on-site). Tämä on toinen mittava ongelma. Kuinka moni asiakas on valmis lähettämään jonkun yrityksen keskijohdosta (koska asiakkaan edustajalla on oltava riittävästi valtaa tekemään päätöksiä) pitkiksikin aikaa ohjelmistoyritykseen. Lisäksi asiakkaan pitäisi olla yhteistyöhaluinen, eikä pitää prosessiin osallistumista pakollisena pahana. Tämä on ongelma, mutta esimerkiksi Mobile-D (ketterä menetelmä) ei vaadi asiakkaan jatkuvaa läsnäoloa.

Koodin tekemisessäkin on eroja. Extreme Programming (XP) esittää kahden koodaajan ideaa, eli koodia työstetään parityönä. Toinen varsinaisesti kirjoittaa ja toinen seuraa vierestä, antaa ideoita ja yrittää löytää virheet. Parikoodausta pidetään keskeisenä asiana ketterissä menetelmissä, vaikka se ei todellakaan ole sitä. Muita koodaamiseen liittyviä asioita ovat koodin omistajattomuus, eli kuka tahansa voi muokata mitä tahansa osaa ohjelmasta ilman massiivista sähköpostin lähettelyä. Se on helppoa, koska ketterissä menetelmissä painotetaan (suullisen) informaation liikettä, pyritään saamaan koko ohjelmistotiimi samaan avoimeen tilaan ja pidetään päivittäin edistymiskokouksia (kestoltaan noin 15min). Jotta kaikki tietäisivät mitä muut tekevät (tätä korosti myös Pirjo Ståhle tietojohtamisen kursseillaan).

Testaus on nostettu ajavaksi tekijäksi ohjelmistokehityksessä ketterissä menetelmissä. Ehkä suorastaan vallankumouksellinen idea kehittää ensin testit ja sitten ohjelmistot, jotka läpäisevät testit, on keskeisenä ketterissä menetelmissä. Tällä tavoin rajataan koodaajan innovaativisuutta väärässä paikassa (eli poistetaan featureviidakon mahdollisuus (featureviidakko = paljon ominaisuuksia, jotka ovat kehittäjän mielestä kivoja, mutta joista yhtäkään ei ole tunnistettu määrittelyssä / vaatimusten keräämisessä)) ja pysytään paremmin aikataulussa.

Yhteenvetona voidaan sanoa, että ketterät menetelmät ovat paljon kaikkea muuta kuin koodaustapojen muutos, joskin se muuttaa myös toteutustapaa. Testaus on tärkeää, johdon asema muuttuu ratkaisevasti, ohjelmistotiimille annetaan valtaa muuttaa oma-aloitteisesti toimintaansa parantaakseen tehoa ja niin edelleen. Perinteiset sudenkuopat, jotka johtuvat viime vaiheen testauksesta, pyritään välttämään jatkuvalla testauksella ja lyhyellä iteraatiovälillä.

Kirjoja ja julkaisuja ketteristä menetelmistä on kirjoitettu paljon ja niitä tulee kiihtyvällä vauhdilla. Jos kiinnostus tietää lisää heräsi, Google Scholar auttaa. Erityisesti voin suositella alkukatsaukseksi Abrahamssonin ja kumppaneiden julkaisua Agile software development methods