hoikka ketterä
pilvipalvelu, Akva
suuntaa tulevaan
turvallisuutta
osaamista, viestintää
huumori suolaa
Akvan laivaseminaari Ketteryys ja pilvipalvelut 29.9.-1.10.2010 kokosi Vikingin auditorion täyteen innokkaita ict-ammattilaisia bongaamaan uutta tietoa ja verkostoitumaan. Tilaisuuden juontanut Jari Petersen-Jessen toivotti meidät tervetulleiksi ja kertoi Akvasta.
Avauspuheessaan Robert Serén Tietotekniikan liitosta korosti seminaarin ja ict-alan naisvaltaisuutta, ict:n roolia yhteiskunnassa ja julkishallinnon suurta osuutta koko Suomen ict-markkinoista.
Ketterästi pilvessä
Arto Saario Ixonokselta kertoi, miten pilvipalvelut mahdollistavat ketterän toiminnan. Menestyvillä yrityksillä on toimiva organisaatiokulttuuri, jatkuvan organisaatiomuutoksen sykli. Ketteryys näkyy muutostilanteissa: muutos tunnistetaan, selvitetään sen vaikutukset prosesseihin ja sidosryhmiin, koordinoidaan ja toteutetaan. Muutoksen monimutkaisuutta on vaikea ennustaa.
Perinteisesti palveluita on kehitetty eri yksiköille, vaikka horisontaalinen, kokonaisvaltainen kehittäminen palvelisi paremmin koko organisaatiota. Infrastruktuuri pilvipalveluna IaaS voisi olla sopiva ratkaisu. Alkuinvestointi on pieni, koska pilvipalvelu kestää mahdolliset käyttöpiikit. Pilvimarkkinan kotimaiset palvelut puuttuvat vielä.
Pilvipalveluiden oikeudellisia ongelmia
Pia Ek Asianajotoimisto Hannes Snellmanista valotti meille pilvipalveluiden oikeudellisia ongelmia. ”Insinöörien tehtävänä on keksiä ongelmiin ratkaisut, juristien tehtävänä keksiä ratkaisujen ongelmat.” Ulkoistus ei ole samaa kuin pilvipalvelut (vrt. juokseminen ja lenkkarit).
Jos rekisterinpitäjä on suomalainen, voidaan soveltaa Suomen lakia. Rekisterinpitäjä on osapuoli, joka määrittelee käsittelyn tarkoituksen ja keinot. Sen tulee valita sopivat henkilötietojen käsittelijät ja turvata rekisteröityjen oikeudet sopimusteitse: Miten tietoja käsitellään? Kuka pääsee niihin käsiksi? Missä maassa tiedot sijaitsevat? Lainsäätäjä olettaa, että yksi rekisterinpitäjä vastaa tiedoista. Henkilötietojen käsittelijä on ”mykkä toimija”.
Pilvipalvelut vähentävät suoraa kontrollia, mutta lainsäätäjän mielestä kontrollia pitää olla – vaikka tieto olisi päivällä jossain ja yöllä jossain muualla sen mukaan, missä milloinkin tiedon säilyttäminen olisi halvinta.
EU- ja ETA-alueen ulkopuolella tietosuojan kannalta turvallisia maita ovat Argentiina, Kanada ja Sveitsi. Yhdysvalloissa tietosuojaa ei ole juuri lainkaan. Siellä Safe Harbour -säännöksiin liittyneiden palveluntarjoajien kanssa tilanne on hiukan helpompi, mutta silti nyrkkisääntö on, että kannattaa käyttää ainoastaan sellaista pilvipalveluntarjoajaa, jonka tietokeskus sijaitsee EU- tai ETA-alueella. Kannattaa myös varmistaa, että sopimuksessa pilvipalveluntarjoajan kanssa käytetään komission hyväksymiä mallilausekkeita, ja ottaa huomioon mahdollinen alihankinta.
Palvelusopimusmaailman viidakosta löytyvät palvelutasosopimus (SLA), joka takaa palveluiden toimimisen sovitulla tavalla, vuokrasopimus esimerkiksi ASP-palveluissa, palvelusopimus ja ulkoistussopimus. Pilvipalvelut tarjoavat matalan kynnyksen sisäänpääsyn ja mitoitusmahdollisuudet, mutta monet julkisesti saatavilla olevista pilvipalvelusopimuksista rajoittavat tarjoajan vastuuta niin paljon, ettei se ole linjassa mahdollisen riskin kanssa. Mistä saadaan korvaus, jos ei päästä pilvessä olevaan kirjanpito-ohjelmistoon? Millaiset ehdot ovat asiakkaan kannalta? Voiko hintoja tarkistaa? Voiko niitä yksipuolisesti muuttaa?
Tarkastus- ja auditointivaatimukset on hyvä ottaa huomioon. Mihin fyysisesti menet auditoimaan palveluntarjoajan aineistoa? Mitä teet, jos palveluntarjoaja menee konkurssiin? Mitä lakia sopimukseen sovelletaan?
Pilvipalvelut ovat harmaita pilviä juristin näkökulmasta. Toimittaja haluaisi yhtenäistettyjä palveluita ja pitkäaikaisia sopimuksia, mahdollisuutta nopeaan hinnan tarkistukseen ja pakettiratkaisuihin ilman asiakaskohtaista palvelutasosopimusta. Asiakas taas haluaisi räätälöityjä, muokattavia palveluita, varmuutta ja joustavuutta, vakaata hinnoittelua.
Palvelusopimuksissa palvelu pitäisi kuvata selkeästi, palvelutasosopimuksessa määritellä palvelutaso sanktioineen. Onko sopimuksissa määritelty vasteaika, korjausaika ja korjauskeinot? Onko varmistettu tiedon erottelu pilvessä kolmansien osapuolien tiedoista? Mitä tiedoille tehdään, kun sopimus päättyy? Mikä on tietojen palautusstrategia? Pitäisi pyrkiä sopimaan, että oman maan lakeja sovelletaan, mutta onnistuuko se aina?
Pilvipalvelun hankkijan muistilistalla pitäisi olla:
- SLA:t sekä sopimuksen muodossa että käytännössä
- Sovellettavat standardit
- Kenellä on pääsy tietoihin? Alihankinta?
- Missä tietoja säilytetään? Mitä lakia sovelletaan?
- Miten ylivoimainen este on määritelty?
- Sopimuksen päättyminen ja tarjottavat palvelut tietojen siirtämiseen?
- Hinnoittelu?
Hoikka ja ketterä ohjelmistoturvallisuus
Antti Vähä-Sipilä Nokialta kertoi, miten turvallisuus ja laatu kulkevat käsi kädessä. Ohjelmistoturvallisuudessa avainasia on riittävä koulutus. Turvallinen ohjelmistokehitys sisältää uhka-analyysin, kontrollien valinnan ja jäännösriskien hyväksymisen. Aktiviteettilistoja on useita, esim. bsimm2, opensamm, ms, safecode.
Uhat analysoidaan vapaamuotoisesti keskustellen, ehkä musta hattu päässä miettien, mitä kaikkea voisi tapahtua. Askel askeleelta -prosesseja ovat tietovuoanalyysi ja STRIDE-malli, jossa kuvataan kaikki prosessit fläppitaululle ja mietitään kunkin uhat. Väärinkäyttötapausten-mallia käytetään vaatimustenhallinnassa: business caseihin lisätään käyttäjätarinoita siitä, mitä ei saisi tapahtua.
Lean tulee sanasta leanness, hoikkuus. Lean tarkoittaa, että kaikki pyritään tekemään mahdollisimman vähäisellä turhuudella. Miten riskienhallintasyklin osat voidaan jalkauttaa niin, etteivät ne riko hoikkuutta? Lean-periaatteen rikkominen rikkoo myös scrumin. Kaikki järjestelmään lisättävät asiat pitää lean-testata. Esimerkiksi hoikkuus rikkoutuu ja flow tuhoutuu, jos keskitetyltä tietoturvatiimiltä pitää hakea hyväksyntä jokaiselle tehtävälle asialle. Hyväksyttävät asiat kasautuvat ja käsiteltäväksi jää isoja möhkäleitä. Hoikkuus säilyy, jos jokainen tiimi hoitaa asian itse ”soihdunkantajan” johdolla käyttämällä valmiita malleja – ja pyytää neuvoa keskitetyltä tietoturvatiimiltä vain tarvittaessa. Soihdunkantaja, keskitetty tiimin sisäinen konsultti, on henkilö, joka kysyy juuri ne hankalat kysymykset.
Hoikkuus rikkoutuu, jos uhka-analyysit ja tietoturvatestaus tehdään muun ohessa, omassa sprint-työjaksossaan tai erikseen järjestettynä aktiviteettina, koska sellaista ei pystytä hallinnoimaan srcumilla. Tietoturvatyö kannattaisi aikatauluttaa samanlaisiksi backlog-tehtäviksi kuin muutkin työt.
Tietoturva pitäisi analysoida vaatimusmäärittelyssä ja suunnittelussa. Koodin mukana toimitetaan jäännösriski koodin vastaanottajan hyväksyttäväksi. Kukin hyväksyy jäännösriskin omalla tasollaan, jolloin epäonnistuminen ei ole katastrofi ja ylempänä on aina veto-oikeus. Virheellinen hyväksyntä hukkaa korkeintaan yhden sprintin työn, jos ylempänä todetaan toisin.
Ohjelmistokehityksessä erotetaan vaatimustenhallinnan ja toteutuksen taso. Edelliseen liittyvät käyttötapaukset ja bisness caset, jälkimmäiseen koodi ja bitit. Vaatimustenhallinnassa ohjelmistoturvallisuudesta huolehditaan niin, että tuotteen omistaja käy lävitse käyttäjäkertomuksia ja generoi niistä turvallisuuskertomuksia mallien pohjalta (jotka heijastavat yrityksen ongelmia) ja väärinkäyttökertomuksia (mitä ei saa tapahtua; hyökkääjänä en saa pystyä tekemään tätä ja tätä, jotta tätä ei tapahtuisi). Näitä voidaan käyttää toiminnallisina vaatimuksina tai testitapauksina. Turvallisuuskertomukset ovat toiminnallisia tietoturvavaatimuksia.
Ohjelmistoturvallisuus scrumissa tarkoittaa, että scrum-tiimi ottaa tehtävän backlogista ja katsoo, pitääkö tehdä uhkatarkastus; käsitteleekö tehtävä käyttäjätietoja tai luottokorttitietoja? Näin uhka-analyysitehtävät aikataulutetaan ja voidaan sanoa, onko ne tehty vai ei. Erillistä listaa kontrolleista ei tarvita vaan kaikki syötetään tehtäväjonoon.
Jäännösriski hyväksytään sprintin katselmuksessa, jossa päätetään, ovatko sprintin tehtävät valmiita. Tällöin tarkastellaan suorituskykyä ja tietoturvaa: Kun otetaan huomioon uhat, jotka olemme löytäneet, niin onko tehty työ kunnossa turvallisuusnäkökulmasta? Koodin mukana tuleva jäännösriski voidaan esittää esimerkiksi wikisivulla.
Ketterä ostaminen
Perttu Tolvanen Sinisestä meteoriitista pohdiskeli ketterää ostamista. Organisaatio voi hankkia uuden tiedonhallintojärjestelmän tai toiminnanohjausjärjestelmän, mutta miten se saa yksilöt työskentelemään yhteisillä alueilla henkilökohtaisten alueiden sijaan? Ihmisiähän ei voi pakottaa muuttamaan toimintaansa.
Tiedonhallintajärjestelmiä on tuotteistettu aktiivisesti yli 10 vuotta, niillä on tietynlainen filosofia, jonka mukaan ne toimivat, ja se vaikuttaa tuotteiden ratkaisuihin. Kuitenkaan ei ole vain yhtä oikeaa tapaa tehdä ryhmätöitä. Järjestelmiä ei voi määritellä kuoliaiksi: tärkeimmät käyttötapaukset selviävät ja hioutuvat vasta käyttöönoton jälkeen. Ensimmäiset kuusi kuukautta ovat ratkaisevia, niiden aikana uusi järjestelmä muovataan tutkemaan tietotyöläisten tarpeita.
Kustannustehokkuus ja hyvä käytettävyys syntyvät siitä, että tuotteita käytetään niiden filosofian mukaisesti, kun taas tuotteiden taivuttaminen filosofiasta eriäviin käyttötarkoituksiin on vaikeaa ja kallista. Järjestelmä pitäisi saada käyttöön mahdollisimman pian, jotta päästään keräämään käyttökokemuksia.
Korjauksiin pitää varautua heti käyttöönoton jälkeen ja tiedot virhetilanteista välittää toimittajalle heti. Jos niitä kerätään palaute-exceliin ja soitetaan toimittajalle, niin tämä ehkä löytää aikaa listan läpikäyntiin vasta kuukausien kuluttua, jolloin saattaa mennä vuosi ennen kuin käyttäjien ensimmäisenä päivänä havaitsemat virheet on korjattu. Tiedonhallinta- ja tuotepohjaisilla järjestelmillä pitäisi aina edetä pilotilla.
Asiakkaan pitää ottaa vastuu hankinnoistaan, tehdä riittävän hyvä esitutkimus ja priorisoitu vaatimusmääritys. Enää ei voida lähettää tarjouspyyntöjä toimittajille ja odottaa, että nämä vastaisivat jotain fiksua, ei myöskään lähettää pitkää ominaisuuslistaa ja kysyä, vastaako tuote niihin. Järkevämpää on selvittää, miten kentällä olevat tuotteet hoitaisivat kymmenen tärkeintä vaatimusta. Asiakkaan on valittava, haluaako hän valmiin tuotteen vai räätälöidyn tuotteen, ne eivät toimi filosofisesti yhdessä. Maailmassa on myyty miljoonia maksavia portaaliratkaisuja asiakkaille, jotka eivät olisi sellaista tarvinneet.
Ketterä hankinta
Petri Heiramo Agilecraftista totesi, että ketteryys on haastavaa ja tarjouspyynnössä luodaan pohja onnistumiselle tai epäonnistumiselle. Jos pyydetään vaiheittaista toimitusta, toimittaja ei voi toimittaa ketterästi. Hankintalainsäädännön mukaisesti on hankalaa tilata ketterästi, muttei mahdotonta. Ketterässä hankinnassa asiakas sitoutuu ohjaamaan projektia koko ajan ja ottaa siitä vastuun.
Ketteryys koskettaa koko organisaatiota ja johto määrittelee viime kädessä ketteryyden onnistumisen. Ongelmat on tunnustettava ja korjattava, muuten mikään ei muutu. Ketteryys tuottaa kustannussäästöjä pitkällä tähtäimellä, mutta alkuvaiheen kustannukset ovat isot.
Laatu ei ole parametri, josta voidaan neuvotella. Mitä enemmän on tehty purkkaa ja teknistä velkaa, sitä vaikeammaksi tulee tiimin ketteryys. Jos hyväksytään tavoitteeksi 95 %:n laatu, ei kasvateta nälkää tehdä hyvin.
Älä yritä liian suurta kerralla, koska ympäristö muuttuu jatkuvasti eikä isoa projektia ole helppo ohjata. Jos tuloksia ei tule, vaihda toimittajaa. Ketterässä projektissa budjettivastuu siirtyy asiakkaalle, tuotepohjaisessa pikselien viilaaminen on kallista. Jos tietoturva on tärkeää, siihen pitää käyttää aikaa ja rahaa. Tiimi voi kertoa, mitä oikeasti tapahtuu. Tiimillä pitäisi olla suora yhteys todellisiin käyttäjiin, ei vain tilaajaan. Vaatimusten tarkentamiseen ja priorisointiin tarvitaan aikaa.
Älä hajauta, jos se ei ole välttämätön pakko. Viestintä on ketteryydessä olennaista ja hajautus luo aina kynnyksiä keskustelulle. Jos ulkoistat Kaukoitään, niin vaikka työvoima siellä olisi paikallista halvempaa, kustannuksia syntyy ja yleensä alihankintatyöt ovat muita kalliimpia. Ainoat järkevät syyt ulkoistamiselle ovat joko se, että läheltä ei saa tarvittavaa osaamista tai että läheltä ei saa riittävästi kapasiteettia. Mikään ei muutu, jos mitään ei muuteta.
Allekirjoitus pilvessä
Kai Linnervuo Signomista totesi, että sopimuksia ja muita asiakirjoja tulostetaan ja allekirjoitetaan yhä vielä käsin, vaikka sähköinen allekirjoitus on teknisesti mahdollista. Perinteinen tapa sopimusten allekirjoittamiseen on tuttu: tulostetaan nippu sopimuksia, lähetetään ne postitse allekirjoitettaviksi, odotetaan, kysellään perään muutaman kuukauden kuluttua. Onko meillä todellinen varmuus siitä, että tietyllä henkilöllä on valtuudet allekirjoittaa ja onko allekirjoitus kyseisen henkilön? Kun sopimukset sitten tulevat allekirjoituskierrokselta, ne arkistoidaan mappeihin hyllyyn ja mahdollisesti skannataan arkistointijärjestelmiin.
Yritykset allekirjoittavat vuosittain satoja sopimuksia. Signom-tavassa sopimukset allekirjoitetaan luontevasti osana sopimusprosessia. Luotettavuus saavutetaan, kun kolmas osapuoli, patentti- ja rekisterihallitus, autentikoi sopimukset. Allekirjoittaja todennetaan vahvan tunnistamisen menetelmällä, tarkistetaan toimivalta ja varmistetaan allekirjoitettavan sopimuksen eheys. Järjestelmä on juridisesti vahvempi ja parempi kuin perinteinen.
Signomin allakirjoitusprosessissa vaihdetaan ja hiotaan sähköpostitse ensin doc-tiedostoja, kuten perinteisessäkin prosessissa. Kun sopimuksen lopullinen sanamuoto on valmis, sopimus muutetaan pdf-muotoon. Toinen osapuoli lataa sopimuksen Signomin palveluun ja kertoo toisen osapuolen, valitsee kielen ja maksutavan, esim. sopimuksen lähettäjä maksaa vastaanottajan puolesta kuten perinteisissä vakuutusyhtiön ja asiakkaan välisissä sopimuksissa ”vastaanottaja maksaa kulut” -vastauskuorineen. Järjestelmä tarkistaa lähettäjän oikeudet ja lähettää sopimuksen kryptatulla varmenteella vastaanottajalle. Vastaanottaja voi allekirjoittaa sähköisesti, mutta halutessaan hän voi tulostaa sopimuksen ja allekirjoittaa sen perinteiseen tapaan.
Jos allekirjoittajia on useita, palvelu tarkistaa, että allekirjoitetut versiot täsmäävät. Kun sopimus on allekirjoitettu, jokainen osapuoli saa viestin ja voi vuorokauden sisällä ladata allekirjoitetun sopimuksen itselleen. Sopimus poistetaan järjestelmästä, mutta sopimusloki jää jäljelle, jotta riitatapauksessa vuosien kuluttua voidaan nähdä, kuka on allekirjoittanut ja millaisin tunnuksin.
Tavoitteena on, että Signomin sähköinen allekirjoitus olisi standardi vuoteen 2016 mennessä.
Muistan hyvin perinteisen allekirjoitusprosessin Tietie-yhteistyön ja Virtuaaliammattikorkeakoulun sopimuksista 2000-luvun alkupuolelta. Itsekin kannoin sopimuksia rehtorillemme allekirjoitettavaksi, postittelin niitä muihin oppilaitoksiin ja soittelin perään, kun sopimusnippu oli kesälomalla juuttunut jonkun pöydälle.
Elisan pilvet
Kari Terho Elisalta kertoi eCloud-palveluista. Asiakas saa tarvitsemansa kapasiteetin ja maksaa vain siitä. eCloud joustaa myös alaspäin. Palvelimet saa käyttöön minuuteissa, virtuaalisen tietokonekeskuksen perustamiseen menee noin puoli tuntia, kun perinteisen konesalin perustamiseen menisi useita viikkoja.
Yrityspilvi – EnterpriseCloud, sisältää intergrointipalvelut ja vahvan tunnistuksen. Pilven ohjelmisto on auditoitavissa, sitä voi tulla vaikka taputtelemaan. Kari Terho vakuutti myös, että Elisa ei mene konkurssiin.
Tulevaisuuden pilvipalvelut
Janne Järvinen F-Securelta kertoi Tivitin kanssa käynnissä olevasta tutkimushankkeesta, jonka tavoitteena on luoda uudenlaista suomalaista liiketoimintaa. Tunnistettuja haasteita ovat kasvavat käyttäjävaatimukset, nopeus vaihtaa palvelusta toiseen ja palvelutason jatkuva nostaminen. Avoimet palvelut tulevat ja niitä voidaan yhdistää pilvessä, mutta kuka vastaa tietoturvasta?
Perinteisen ohjelmistotuotannon sijaan painopiste on pilven ohjelmistokehityksessä. Millaisia olisivat tulevaisuuden pilvipalvelut? Organisaation pitäisi olla huipputehokas ja sen pitäisi tavoitella kestävää kehitystä, ylivertaista käyttäjäkokemusta ja tietoturvaa. Millainen olisi hoikin ja ketterin ict-organisaatio? Lean-konferensseissa kehitetään hoikkia arvoketjuja toiminnan tehostamiseksi, mutta ohjelmistoalan yrityksiä siellä ei juurikaan tapaa.
Projektin laajuuden arviointi
Paula Männistö Qentineliltä puhui projektin työmääräarviosta, joka perustuu vaatimuksiin. Projektin laajuuteen vaikuttavat halutut ominaisuudet ja niiden toteuttamiseen tarvittava työmäärä. Kohdealue nähdään usein pilvenä. Kuinka tarkasti pitäisi määritellä, ettei määriteltäisi kuoliaaksi?
Vaatimusmäärittelyä tarvitaan tarjouspyyntöön ja tarjoukseen ja testaukseen. Jokaisen pienen käyttäjän tarpeet pitäisi selvittää, samoin yhteydet muihin järjestelmiin. Vaatimusten kerääminen ja kirjoittaminen eivät ole helppoja tehtäviä, mutta ilman niitä ulkopuolisen toimittajan on vaikea laatia tarjousta. oskus kuvaus voi olla niin sekava, että oikeiden asioiden löytäminen on vaikeaa. Joskus taas vaatimuksia kirjoitetaan testausvaiheessa, jotta pystytään testaamaan. Mitenkähän järjestelmä on rakennettu ilman vaatimuksia?
Kumpi tärkeämpää, asiakkaan vai toimittajan osaaminen? Keskustellaanko paperinipun kanssa vai keskustelevatko ihmiset keskenään? Kaikki toimittajat pitäisi saada saman pöydän ääreen. Jos projektin alkupäässä hommat viivästyvät, niin pidetäänkö silti kiinni sovitusta valmistumisajankohdasta? Muutosten hallintaan liittyy vaatimusten hallinta, jossa sekä asiakas että toimittaja oppivat.
Paula Männistö havainnollisti tilannetta kolmiolla, jonka kärjissä olivat osaaminen, prosessi ja esitystapa ja jonka keskellä oli viestintä ja yhteistyö.
Keskustelussa pohdittiin, haluaako tilaaja oikeasti tietojärjestelmää vai jotain ihan muuta. Onnistuneissa projekteissa tavoitteena on yleensä jokin toiminnan muutos, ja tietojärjestelmän kehittäminen on vain osa toiminnan muutosta. Valitettavan usein kuitenkin tilataan vain tietojärjestelmää eikä toiminnan muutos näy toimittajalle asti.
Prosessien kuvaukset helpottavat kokonaistilanteen hahmottamista. Käyttäjien ja roolien avulla pitäisi löytää vaatimukset. Tilaajan vastuulla on tehtävien jatkuva priorisointi, toimittaja ei priorisoida.
Ketteryys Itellassa
Pipsa Ylä-Mononen kertoi ketteryydestä Itellassa, jossa scrumia on käytetty nelisen vuotta aikatauluvaatimusten vuoksi. Vaatimukset syvenevät, niitä arvioidaan ja todennetaan jatkuvasti. Toteutustapa on testauslähtöinen ja liiketoiminta pääsee konkreettisesti iholle, vaikka liiketoiminnan edustajat eivät pääse ulkoistamaan vastuutaan.
Projekteja katselmoidaan säännöllisesti kahden viikon iteraatioissa. Varttitunnin mittaisia scrum-kokouksia pidetään päivittäin. Projekteissa tarvitaan avointa ja jatkuvaa viestintää. Parhaiten se onnistuisi samassa työhuoneessa, mutta joskus tiimin edustajat ovat eri kaupungeissa. Jos asiantuntijat eivät saa vaatimuksia paperille, joudutaan lypsämään, työstämään ja esittämään hypoteeseja siitä, miten asia voisi olla.
Projekti eri vaiheissaan onnistuu parhaiten tasaisesti työskennellen ja huumorilla ammatti- ja viestintätaitoisten ihmisten kanssa. Jos ostetaan ulkoa, kuvataan prosessit ja niiden muutokset sekä käyttötapaukset. Jos tehdään itse, kootaan ryhmä omia suunnittelijoita eri taloista, koodataan parityöskentelynä ja valvotaan laatua sisäisesti.
Scrum ei tee tai automatisoi määrittelyä tai tahtotilaa, ei hyväksymis- tai käyttöliittymätestausta eikä arkkitehtuuri- ja teknologiavalintoja. Tilaaja päättää, onko järjestelmä valmis. Scrumiin liittyvät käsitteet täytyy kouluttaa, jotta ihmiset ymmärtävät, mistä on kyse. Taannoin joku tuli puolen vuoden kuluttua kysymään, mitä inkrementti on, kun siitä oli koko syksy puhuttu. Käsite olisi pitänyt selittää ja avata heti alussa.
Onnistumisen edellytyksiä ovat jatkuvan ja avoimen tiedonkulun varmistaminen, riittävä suunnittelu, sprintin ulkopuolisten tehtävien vaatiman työajan ennakointi ja tiimin itseohjautuvuus. Liiketoimintayksiköistä tarvitaan riittävää resurssointia, sitoutumista ja priorisointia. Jos sama henkilö on ydinasiantuntija yli kymmenessä projektissa, miten hän jakaa aikansa? Lojaalisuus ja ymmärrys järjestelmien linkittymisestä toisiinsa on uskomatonta kavereilla, jotka ovat olleet talossa kymmeniä vuosia, mutta mitä tapahtuu, kun he jäävät eläkkeelle?
Tekemällä oppii, muutaman sprintin jälkeen tekeminen lähtee kunnolla käyntiin. Testaus on osa sprinttiä. Joka sprintillä on oma bugibudjettinsa, jotta virheet eivät kasaantuisi. Bugittomia tarinoita seurataan. Kun sprintti meni ilman bugeja, jaetaan kakkua kaikille, kun bugeja tulee paljon, istutaan töttöröhattu päässä – idea oli suunnittelijoiden oma. Olennaista kuitenkin on, ettei haeta syyllisiä vaan tehdään uutta ja katselmoidaan se, ettei tarvitsisi myöhemmin ihmetellä.
Itellassa tiimille hankittiin oma valkotaulu ja pöytä – josta sai aika pitkään keskustella arkkitehdin kanssa. Tiimihengen luominen ja motivaatio on tärkeää, jotta tiimi toimisi itseohjautuvana asianomistajana ja kehittäisi laatua oma-aloitteisesti.
Ketterä testaus
Maaret Pyhäjärvi Ilmarisesta kertoi ketterästä testaamisesta. Testauksessa on yleensä rajallinen budjetti, kohteena monimutkainen ja laaja kokonaisuus, jossa tulee vastaan yllättäviä ongelmia ja jatkuvaa muutosta, jolloin on mahdotonta suunnitella mitään yksityiskohtaisesti etukäteen.
Maaret Pyhäjärvi havainnollisti testausta 20 kysymyksen budjetilla, videolla 14 koripalloilijasta sekä wordpadin fonttidialogiin syötetystä luvusta 1639. Videon katselu osoitti, miten perinteinen testaus tekee sokeaksi emmekä huomaa olennaisia virheitä, joita emme osaa odottaa. Wordpadin fonttidialogista Maaret Pyhäjärvi totesi, että testauksessa pitää olla hauskaa, bugeista pitää nauttia, kun niitä löytää. Testaukseen tarvitaan riittävästi vapausasteita, jos halutaan todellisia tuloksia.
Tutkivan testauksen guru on twiitannut: ”Miksi kutsutaan ammattitaitoista lääkäriä? Lääkäriksi. Entä ammattitaitoista testaajaa? Tutkivaksi testaajaksi.”
Testaaja osaa kertoa omasta työkentästään. Maaret Pyhäjärvi kertoi kysyvänsä muutaman kerran viikossa testaajilta, mihin heidän aikansa on kulunut ja trendi on mielenkiintoinen. Toimittajien testausmallien muuttaminen vienee kuitenkin vuosia.
Ketterässä tiimissä testaus on ketterää. Testaajilla on vastuu kokonaislaadusta; ei eletä päiväunissa vaan katsotaan, että päiväunet toteutuvat. Sprintin aikana käytetään automatisoituja testejä. Yksikkötestaus pitäisi määritellä ennen toteutusta. Testiohjattu koodaus ei sovi kaikille, joillekin se aiheuttaa ahdistusta, joten muitakin toimintatapoja sallitaan.
Virheet ja vaatimusmuutokset pitää suhteuttaa hintalappuun. Bugi on bugi, mutta ketterässä kehityksessä se voi löytyä jo alkumetreillä eikä vasta lopussa. Suorituskyky pitää testata niin, että tiimi saa siitä myös palautteen.
Ketterää kehitystä ei tehdä ilman määritystä. Vaatimukset voidaan kirjoittaa vaikka valkotaululle ja kuvata eri värein ja täydentää ja lopuksi muokata parempaan muotoon. Palautemekanismi, tuotebacklogi ja muutosten hallinta ovat olennaisia.
Kaikki tiimissä testaavat ja testaaja on tiimin jäsen. Lyhyet sprintit alkuun ovat hyviä, koska ne edistävät oppimista. Tiimi paranee jokaisen sprintin aikana.
Onnistumisen mahdollisuudet lisääntyvät, kun ihmiset saadaan lähemmäs toisiaan ja keskustelemaan. Testaus on osaavien ja tahtovien ihmisten yhteistyötä, jonka edellytyksinä ovat sopiminen ja sopimukset, työrauha ja luottamus.
Ulkoistaminen
Katriina Joki Tiedosta kertoi ketteristä menetelmistä ja ulkoistamisesta. Vaatimusmääritys tehdään edelleen samalla tavalla kuin aikaisemminkin. Odotusten pitää olla realistiset: Suomen työeläkeosaaaminen on hankittu vuosien aikana eikä sitä hetkessä siirretä muualle eivätkä hinnat putoa heti kun ulkoistetaan. Jokainen suomalainen tietää, mikä on lapsilisä ja millainen ongelma syntyy, jos sen maksu viivästyy – mutta intialainen ei ymmärrä.
Ulkoistamiseen liittyy vastarintaa ja epäluuloja. Monet asiakkaat haluavat dokumentoida suomeksi ja on osa-alueita, joilla ei kunnollista englanninkielistä termistöä olekaan. Ihminen saattaa pelätä menettävänsä työnsä; muualla tehdään sitä, mitä tein aikaisemmin! Voidaanko luottaa siihen, että poissa näkyvistä oleva etäprojektilainen tekee sitä mitä häneltä odotetaan? Entä mitä etäjohtaja tekee, jos jossain työtehtävässä ei voida edetä?
Projektin henkilöstölle pitäisi viestiä selvästi, mitä he ulkoistamisesta hyötyvät. Projektibudjetissa pitää varautua koulutukseen ja matkustamiseen. Matkustaminen ei ole niin kallista kuin miltä se ensin tuntuu, koska toimittajan ja asiakkaan kohtaaminen on tärkeää ja projektiin osallistuvien pitää oppia ymmärtämään muiden osapuolten mallia. Liiketoimintatukeen ja selvittelyyn tarvitaan tavallista enemmän resursseja, työnohjaukseen pitää kiinnittää huomiota ja aikatauluissa pitää varautua tekstien kääntämiseen. Miten projektin organisointi muuttuu, kun maailman ympärillä muuttuu? Miten käännösprosessi etenee, kun määritys ja toteutus iteroidaan?
Kulttuurieroja ei pidä kieltää. Intiassa vaihtuvuus on suurta, ja kuitenkin ihmiset pitäisi sitouttaa projektiin. Intialaisten on vaikea myöntää ongelmiaan, tarvitaan ilmapiiriä, jossa ongelmista voidaan puhua.Tarvitaan myös jämäkkyyttä ja herkkyyttä, erilaisuuden sietämistä ja tasaista työkuormaa, tuska ja kiitos täytyy jakaa kaikille.
Älä hajauta
- jos et osaa laskea hajauttamisen kustannuksia
- jos sinulla ei ole työkaluja kokouksiin
- jos et kouluta ja sitouta henkilöstöä
- jos laiminlyöt viestinnän etkä kerro, mitä ihmiset hajauttamisesta saavat
- jos et ole valmis kohtaamaan uutta ja erilaista.
Nextdoor
Marko Taipale Huitaleesta kertoi nextdoor.fi-verkkopalvelusta, josta kuluttajat voivat ostaa kotitalouspalveluita. Tuotteen rakentamiseen meni 20 miestyöpäivää. Ensimmäisenä päivänä hankittiin tietokone, 70 päivää meni toiminnallisuuden ja 50 päivää käyttöliittymän rakentamiseen ja hiomiseen. Tuotteen elinkaaren eri vaiheissa syntyi erilaisia käyttöliittymiä.
Mikään kuluttajatuote ei elä verkossa yksin. Nextdoorin Facebookin sivulla on 30 000 vierailijaa kuukaudessa ja yli 2000 aktiivista käyttäjää, ilmoitustaulu, 300 avointa ilmoitusta ja 3 päivän vastausaika.
Nextdoorin verkkopalvelua monitoroidaan automaattisesti. Liiketoimintaraportit ja varmuuskopiot tuotetaan päivittäin. Verkkopalveluun imetään Uranuksesta keikkailmoituksia, jotka saavat entistä laajempaa näkyvyyttä.
Verkkopalvelun kehittämisessä teemat selvitetään kahden tunnin istunnossa, jossa kerätään liiketoimintaraportteja, kilpailija-analyyseja ja käytettävyyteen liittyviä pyyntöjä. Teemoista poimitaan kolme, joita halutaan parantaa. Tämän jälkeen parin vuorokauden ideamyrskyssä nostetaan esiin konkreettisia ominaisuuksia, joilla on liiketoiminnallista arvoa ja jotka asetetaan jonoon. Kehitystyö kestää kuusi päivää, joiden päätteeksi tehty ominaisuus testataan varttitunnin automaattiajolla. Ominaisuuden julkaisemiseen menee minuutti.
Ominaisuuden matka ideasta tuotantoon kestää siis kahdeksan päivää. Jos tuotejonossa on seitsemän ominaisuutta, läpimenoaika = (7*8)/2 = 28 päivää.
Ongelmatiimi kuvaa ongelman, jonka ratkaisutiimi ratkaisee. Aiemmin ominaisuus ei mennyt tuotantoon, jos sitä ei hyväksytty. Nyt se menee tuotantoon, jos prosessia ei keskeytetä. Järjestelmästä ajetaan tilastoja ominaisuuksien käytöstä ja poistetaan ne ominaisuudet, joita ei käytetä. Minkä tahansa lapun voi ottaa pois, lapun seinältä tai keskeneräisen tai valmiin palan sovelluksesta.
Huitaleen blogista löytyy yksityiskohtainen kuvaus siitä, miten scrum tähän taipui.
Ketterä ostaminen
Ralf Sontag Huoltovarmuuskeskuksesta kertoi ketterästä ostamisesta. Projektin alussa koulutettiin kaikki projektin organisatioon kuuluvat. Tarjouspyynnössä painotettiin järjestelmäarkkitehtuuria, jossa kuvattiin, mitä ainakin pitäisi saada ja mitä lisäksi voisi olla. Tarjouksen jättäneet koottiin yhteiseen palaveriin, jotta kaikkia kohdeltaisiin tasa-arvoisesti.
Käyttäjätarina kehittyi projektin aikana kumulatiivisesti ja sprinteittäin. Kun määrittely oli karkealla tasolla, ei ollut yllätys, että löytyi tarkennettavia asioita. Gartner Groupin verkkopalvelussa on ketterien menetelmien vastaväitekokoelma.
Akva, 30-vuotias nuorukainen
Loppupuheenvuorossaan Akvalle, 30-vuotiaalle nuorukaiselle, Robert Serén korosti, että ict-alan palkat ovat naisten ja miesten välillä tasa-arvoisempia kuin monella muulla alalla. IT-barometri 2010 -tutkimus kertoo mm., että ict-projektien lopputulokset vastaavat yleensä sovittua, mutta projekteista iso osa ei pysy aikataulussaan ja ict-hankintojen tavoitteista saavutetaan vain puolet. Kaikesta ei tarvitse tehdä hypeä; asiat voidaan pitää yksinkertaisina.