#seminaarikannu

Lupaava otsikko. Jatkakaa!

Ohjelma löytyy täältä

Tänään klo 14:00 alkaen:

• Heikki Vesalainen, Ixonos : Vaatimusmäärittely ja vaatimustenhallinta erilaisissa projektityypeissä
• Anssi Rusanen, Tieturi: Testivetoinen kehitystyö (TDD) aseena ohjelmistojen laatuongelmia vastaan
• Katja Kuusikumpu, Qentinel: Miltä näyttää tulevaisuuden testaaja?
• Anne Isotalo, SOK Tietohallinto: Kipupisteitä tilaajan näkökulmasta toimittaja-yhteistyössä
• Paula Miinalainen, Arbor Vitae: Ostavat organisaatiot konsultin silmin

• Tarja Raussi, Tieturi: RUP-peli
• Reea Mynttinen, Työterveyslaitos / Aivot ja työ tutkimuskeskus: Onko organisaatiossa tilaa ihmiselle?
• Mitro Kivinen, University Alliance Finland / Global Venture Lab: Minkälainen on virtuaalinen projektitiimi?
• Petri Heiramo, Digia: Johdatus ketterien menetelmien kokeilemiseen
• Workshop: XP-peli
• Workshop: Käyttötapausten suunnittelu

Onko odotuksia näistä aiheista? Voin ottaa jo kysymyksiä vastaan ja kaiutella koosteet niiden pohdinnasta tänne. Itse en ehdi livepostailla, mutta pyrin koostamaan. Katsotaan, josko saadaan kuitenkin myös pientä rapoilua aikaan.

Ohjelmassa hämmentää sukupuolijakauma. Meidän toimistolla tuo jakauma on ihan erilainen.

Ai noita sanotaan suomeksi peleiksi? RUP-peli ja XP-peli?

@Ile aiheissa kiinnostavaa (järjestyksessä):

• Kuinka ketteräksi vaatimusmäärittely määritellään? Onko uutta vai perusjuttuja?
• Testivetoisuus kiinnostaa. Voiko sitä edes sanella ylhäältä?
• Testaajana minua kiinnostaa myös oma tulevaisuuteni. Bingo: automaatio, virtualisointi
• Osaako nykyaikainen tilaaja tilata? Tehdäänkö hankkeista liian pitkiä alkujaan?
• Konsulttinäkökulma edelliseen olis hyvä saada, kun peiliin on vaikea katsoa.
• Mikä ihme on ruppeli? :) Käyttääkö joku oikeasti RUP:ia? Tukehtuuko siihen?
• Ihmisten jaksamisen saisit vaikka nauhoittaa kokonaan.
• @Mitro:n määritelmä virtuaalisuudesta kiinnostaa myös. Onko se sama kuin hajautettu?

@pe3 Rational Unified Process-mallia ja ketterää kehittämistä kokeillaan ja harjoitellaan pelaamalla. Ihan fyysisesti ilman tietokoneita. Pelikortit, nopat, ilmapallot, jne. ja sillai. XP-pelistä lisää täällä: http://www.xp.be/xpgame.html

@pe3 en kerro missä sulla on xppeli

@ferrix RUPin haaste on siinä, osaako sieltä poimia ne muutamat jutut, jotka itselle toimii. Pelissä on tämä aspekti mukana, eli jos alat tekemään asiaa liian työläästi se kostautuu ja projekti kusee.

Me emme (mun töihin) koskaan otettu kaupallista RUPpia, mutta samoja ideoita on kyllä meidänkin mallissa.

Niin ja kiitos listasta! Palataan.. (vai miten ne BB:ssä sanookaan)

@mandri, otatko tarkistettavaksi tuon @ferrix:in bingorivin...
Tuleeko muita bingo-rivejä? Voin printata ne tarkistettavaksi! Voittajalle kaksi Finnkinon leffalippua.

Säännöt: 9 sanan bingorivi. Kun kaikki rivin sanat on mainittu perus- tai taivutusmuodossaan seminaarissa --> Bingo huudetaan sekä livenä että täällä ja bingorivin tekijälle lähtee leffaliput.

Minä olen päätuomari ja hylkään huonot ja triviaalit rivit...

Mun rivi on lyhyempi:

1. Petri Heiramo, Digia: Johdatus ketterien menetelmien kokeilemiseen
2. Mitro Kivinen, University Alliance Finland / Global Venture Lab: Minkälainen on virtuaalinen projektitiimi?

Itse toimin Jyväskylästä koodausporukan ollessa Helsingissä, meillä on halua kokeilla ketteriä menetelmiä, mutta ei aiempaa kokemusta, eikä halua maksaa maltaita mistään järjestelmistä ja konsultoinneista ihan heti kättelyssä. Eli mistä kannattaa lähteä liikkeelle?

@Ile: otin bingolapun talteen. Katsotaan, onko sen vahtimiseen aikaa.

@Ile ja @Mitro avasivat tilaisuuden.

Ensimmäisenä Heikki Vesalainen Ixonoksesta kertoo vaatimusmäärittelystä ja vaatimusten hallinnasta.

Määritellään termejä. Yleisö huuteli asiaan liittyviä sanoja.

@apoikola Kutsu mut kylään juttelemaan, ni mietitään yhdessä...

(siirto)

Pitäiskö tästä tehdä erillinen ketju?

@apoikola Jos haluat jossain vaiheessa kaikupintaa 100% hajautetusta firmasta tulleelta, turistaan joskus. Se on aika mielenkiintoinen ympäristö, jossa on ihan omat säännöt.

@apoikola ja @Mitro: JKL vai HEL? Voiko ruinautua mukaan?

@mandrl Mä olen tehnyt niin, että kullekin esitykselle oma otsikko / Qaiku ja sitten sisältöä sen alle kommentteina. Ehkä sitten seuraavasta...

@apoikola @pe3 @ferrix Jos Ferrix mukana, niin ehkä Hel, muuten Jkl käy. Mutta pitää sopia ajoissa, käyn siellä ehkä kerran kuussa... 23.9. ilta käy Jkl:ssä.

Hui, millaista tahtia tämä menee. Asia on jännempää kuin mun raporttini.

@Mitro ja @ferrix kiitos kaikupintatarjouksista! Erittäin mielelläni turisen aiheesta ja @pe3 on puolestani tervetullut joukkoon. Helsinki on varmaan helpompi vai? minä reissaan varmaan kerran kk stadiin. 23.9 olen kyllä täällä Jyväskylässä ja mielelläni voin silloinkin antautua juttutuokioon.

Mä olen Helsingissä ainoastaan arkisin. Muuten olen pääosin Espoossa. ;)

@ferrix tarkennahan tota sun kysymystä vaatimusmäärittelyn ketteryydestä...

@salainen Monesti vaatimusmäärityksen suhteen pyritään turhaan siihen, että määritellään kaikki heti alkuun ja sitten ne laitetaan jonnekin varastoon ja yritetään saavuttaa niitä vuosi, kun tarve muuttui jo kuukauden päästä määrittelystä. Dean Leffingwellin osuva typistys oli: "Requirements decay." Mikähän olisi suomeksi hyvä? Vaatimukset maatuvat?

Eli minua tuossa puheenvuorossa kiinnosti, että mitkä ovat puhujan ratkaisut tuohon ongelmaan.

Ja itse itselleni vastaten, raposta näytti siltä, että pääpaino on aluksi kunnolla tekemisellä.

Laitetaan vielä koostehengessä seuraavakin rapo Kuusikummun showsta.

@ferrix joo... itsekin olen tehnyt pari kertaa sen virheen, että kirjoitellut liian tarkkoja vaatimuksia ennen kuin edes asiakkaan business case on ollut selvä. Lopputulos on ollut kasa ainakin näennäisen turhia dokkareita, kun ko. vaatimuksia ei ole koskaan implementoitukaan. Toisaalta niiden dokkareiden työstämisen kautta kaikki prosessissa mukana olleet ovat kyllä varmasti oppineet jotain ko. domainista -- työ ei siis ehkä kuitenkaan ole ollut täysin turhaa.

Ihan äkkiä tohon ei ole mitään yleispätevää ratkaisua sen takia, että määrittely on pohjimmillaan ideointi- ja suunnitteluprosessi, eikä suinkaan mikään lineaarinen transformaatio. Toisaalta pitäisi tehdä synteesiä siitä, mitä ollaan tekemässä -- eli ymmärtää homman scooppi ennen kuin menee detaaleihin. Toisaalta taas analyysin kautta ymmärretään mistä se synteesi koostuu ja sitä kautta herää uusia ideoita. Jos homman yrittää tehdä toisin päin on vaarana analyysiparalyysi, eli se, että jäädään nysväämään yhtä detaalia loputtomiin.

Jos nyt sitten joku antaisi ohjeen, että ei saa analysoida (s.o. speksata detaaleja) ennen kuin vasta ihan viime tingassa, niin riskinä on se, että liian myöhään havaitaan jotain, mikä vaikuttaa radikaalisti kokonaisuuteen (ja tuloksena on paljon refaktorointia tai jopa koko projektin aloittaminen alusta). Jos taas tekee liikaa analyysiä "varastoon", niin tulee luultavasti tehdyksi paljon turhaa työtä.

p.s. taisi tulla aika ympäripyöreää käsien heiluttelua, mutta jatketaan tästä...

Tervehdys! Seminaari onnellisesti ohi ja kaikilla oli kivaa (huom! myös palautteen perusteella). Sen verran oli vauhdikasta toimintaa, että emme kauheasti ehtineet rapoilla. Kiitokset kuitenkin @mandri:lle ainakin noista parista linkatusta.

@mitro, @mandri @salainen, arvioidaanko, onko meillä bingossa voittajaa. Rivihän on
[[automaatio, virtualisointi, kompetenssi], [luovuus, innovaatio, stressi], [scrum, loppukäyttäjä, käyttäjäkertomus]]

Ainakin automaatio, stressi, scrum, innovaatio, loppukäyttäjä ja käyttäjäkokemus mielestäni löytyi..

@salainen Eri lähteistä keräämällä mulle on syntynyt sellainen nyrkkisääntö, että määritellään alkuun leikkikentän rajat ja sen verran vaatimuksia, että ne saa toteutettua 90 kalenteripäivässä. Työn etenemistä tarkastellaan 14-28 päivän sykleissä ja tänä aikana syntyy näkemys seuraavien 90 päivän tavoitteista.

@Ile rapoilun perusteella Kuusikumpu mainitsi automaation.

@Ile löytyi myös luovuus. käyttäjäkokemus -sanaa ei ole listalla. käyttäjätarina oli, ei sinänsä käyttäjäkertomusta Kuitenkin ehkä riittävän lähellä. _virtualisointi: ei esiintynyt. Tämähän ei ollut tietotekniikka, vaan softaseminaari.

@ferrix Kuulostaa hyvältä.

@salainen Tuosta viisas mies tietty otsalla näkee, että ei sais mennä hirveesti yli 90 päivän tuo vaatimusten vatulointi ensimmäiselläkään kerralla :)

@ferrix Se riippuu ihan siitä, mitä sä käsität vaatimusten vatuloinnilla ;-). Mulla on sellainen prosessi tohon määrittelyyn, joka koostuu kolmesta pääaktiviteetista:

• ongelman ja ongelmakentän ymmärtäminen, ongelma-analyysi
• ratkaisun määrittely, konseptointi
• tietojärjestelmän vaatimusmäärittely

ja toki siis "s/vaihe/aktiviteetti/g", eli korvaa edellisessä kaikki sanat "vaihe" sanalla "aktiviteetti" -- tarkoitus ei ollut sanoa, että noi asiat pitää suorittaa peräkkäin.

p.s. jostain syystä qaiku ei antanut mun muokata edellistä kirjoitusta (Send harmaa ja merkkilaskuri näytti miinusmerkkisiä lukuja).

@salainen Viimeiseen vaiheeseen erityisesti, mutta oikein pitkälle viety ketteryys edellyttäisi, että käyttäjästooreja sun muita voidaan hahmotella mockuppien ja protojen avulla. Eli yritetään ymmärtää domainia ja ihmisiä tekemällä juttuja ja kirjoittamisen sijaan piirtämällä. Parasta tietysti olisi, jos saadaan domainosaava tuoteomistaja lähelle tekijöitä. Joka tapauksessa tuo 90 päivää on sellainen aika, jossa maailma ei vielä ehdi muuttumaan kovin paljon, mutta siitä yli ollaan jo vaarallisilla vesillä.

Helpoin ja halvin tapa kommunikoida asiakkaan kanssa on pystyä lyhyessä ajassa ja pienellä työllä heittämään ensimmäinen esimerkki: "Ai jotain tähän suuntaan?" ja siitä parantaminen: "No mikä tässä on huonoa?".

@salainen Tuollaisessa selkeässä bugitapauksessa on hyvä huutaa esimerkiksi: ping @eholmila!

@ferrix , you summoned me my lord? @salainen , kurkataanpa tilannetta :)

@salainen Pitäisi toimia taas.

@ferrix Noin kyllä joo teoriassa, mutta aika paljon on tilanteita, jossa noin ei voi toimia.

Esim. ongelman ymmärtäminen ja sen analysointi ei välttämättä ole kirjoittamista sen paremmin kuin piirtämistäkään. Se voi, kuten sanoin, olla esim. haastattelemista ja workshoppaamista. Tietenkin on hyvä panna ylös jotain niistä haastatteluista jossain muodossa (vaikka piirtäämällä).

Viimeistään tässä vaiheessa lienee syytä määritellä, missä domainissa me käymme tätä keskustelua. Minun vankin kokemus on sellaisista yritysjärjestelmistä, jotka tukevat jotain liiketoimintaprosessia. En osaa sanoa, miten väittämäni pätee muihin ympyröihin.

Tuoteomistajan roolissa on mielestäni paljon ratkaisemattomia ongelmia kun puhutaan yritysjärjestelmistä. Yksi ongelma on tarvittavan domainosaamisen laajuus, t.s. domain on niin suuri, ettei yksi ihminen pysty hallitsemaan sitä kokonaan... tai ainakaan projektin alussa ei sellaista henkilöä vielä ole, eli projektin on itse kasvatettava oma tuoteomistajansa -- ja se vie aikaa. Esimerkkinä nyt vaikka fuusion jälkeinen yritys, jossa on useita eri samaa asiaa tekeviä yksiköitä ja jokaisella oma tapansa toimia. Sellaisen domain-osaajan löytäminen, joka tuntisi syvällisesti kaikkien näiden yksiköiden tarpeet, on varmasti vaikeaa. Asiaa ei varmasti helpota jos yksiköt ovat vahvasti eri mieltä siitä, mikä olisi paras tapa toimia jatkossa (tai ainakin luulevat olevansa).

Viimeinen asia, mikä on muistettava, on muutosjohtaminen. Määrittelyprosessi ei ole vain "lähtödatan tuottamista atk-suunnittelijoille" (yäh!), vaan myös tulevien käyttäjien valmistamista muutokseen. Jos meillä olisikin sellainen domain-osaaja, joka osaisi yksin kertoa meille, miten asiat tulee olla, ei se riittäisi. Käyttäjäryhmät pitäisi silti edes näennäisesti osallistaa uuden järjestelmän suunnitteluun, jotta heidät saadaan sitoutettua sen käyttöön jo heti alusta alkaen. Joku voisi ehkä ajatella, että osallistetaanhan heidät sitten kun eka iteraatio on ohi ja voidaan pyytää palautetta. Siinä vaiheessa saattaa kuitenkin olla jo niskakarvat pystyssä ja peli menetetty.

Joku voisi nyt palauttaa minut maan pinnalle sanomalla, että yllä kuvaamani ongelmat eivät ole enää softaprojektin tontilla ja ne voidaan jättää jonkun muun huolehdittavaksi. Mutta haluaisin kyllä vielä toistaiseksi väittää, että asiansa osaava määrittelijä olisi kyllä ainakin huolestunut näistä asioista.

@ile voisi ehkä osata kommentoida tota "monta yksikköä, eri tavat toimia" ongelmaa paremmin.

@salainen Nämä ovat vaikeita kysymyksiä. Minä olen kasvanut nopeasti toimitettavaan arvoon. Mutta kuten sanoitkin, nämä toiminnot voivat olla rinnakkaisia. Softaa tuottaessa tärkeää on, että joku lyö tahtia. Tuo 90 päivää on muun muassa Dean Leffingwellin ketteryyden skaalaamiseen liittyviä ydinseikkoja ja se on monessa firmassa lähellä tapahtumahorisonttia. On siis tärkeää, että näkyvää tulosta saadaan mahdollisimman pian, jotta ei mennä pitkiä aikoja autopilotilla väärään suuntaan.

Domainosaaminen on toki tärkeää, mutta paloina ne norsukki syyvään, joten prosessin vielä ollessa käynnissä voidaan kehittää jotain.

@ferrix Näkyvän tuloksen saaminen on myös tärkeä motivoinnin kannalta. Muiden, kuin ydinryhmän, mielenkiinto projektia kohden lässähtää, jos se ei saa tarpeeksi usein jotain näkyvää aikaiseksi.

@salainen Aivan näin. Tämä ajatus on motivaatio siihen korkeintaan neljännesvuoden aikajänteeseen. Tilanteen täytyy olla todellinen tietotaidollinen umpikuja, ettei neljännesvuosi riitä seuraavan neljännesvuoden suunnitteluun ja jopa jonkinlaisten prototyyppien toimittamiseen.

@Mitro Virtualisoinnista kyllä keskusteltiin paljonkin illalla baarissa, en vain huomannut huutaa bingoa. @ferrix Laita maapostiosoite osoitteeseen ilkka.pirttimaa -ät- gmail.com niin laitan voiton postiin!

Jee!

@ferrix @salainen Tuoteomistajassa on sekin ongelma, että usein määrittelytyössä kehitetään prosessia, ei tuotetta (toki lopputuloksena voi olla tuote, mutta usein jokin isompi kokonaisuus, jossa on vanhoja ja uusia tuotteita, niiden välisiä integraatioita sekä uudenlaisia rooleja/tehtäviä).

Tarvittaisiin prosessiomistajaa ja se taas vaatisi ihan uudenlaisen organisaatiomallin, jossa oikeasti voisi olla prosessiomistaja tuotteisiin katsomatta. Eli tässä "monta yksikköä, eri tavat toimia"-tapauksessa juurikin tuo monen erilaisen prosessin ymmärtäminen on haaste, johon yksikään tuoteomistaja ei välttämättä heti pysty vastaamaan. Se on totta, että määrittelytyön yhteydessä tällaisia osaajia (en kirjoita prosessiomistajia, koska se tosiaan vaatisi myös organisaatiorakenteiden muuttamista ;-) voidaan kasvattaa.

@tuula @ferrix, nyt on noi testausaiheiset kalvot saatavilla tällä sivulla.