Korjattu yksi typo, ja lisätty uusi tiedosto alustavaksi pohjaksi.

[vugi]

Onko muilla kommentteja näihin ehdotettuihin muutoksiin?

[hessuvi]

vaatimukset.md tiedostoon liittyen: On tunnettu scrumin antipatterni eli huono idea käyttää Product Owneria vastaavassa roolissa tilaajan edustajaa. Projektin tärkeimpiä osallisia ovat loppujen lopuksi varsinaisen työn tekijät ja korkein päätösvalta sen suhteen, mitä tehdään, pitäisi olla heidän edustajallaan. Näin isossa projektissa kannattanee tosin soveltaa Product Owner Team patternia (http://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/product-owner-team). Tässä tuoteomistajien ryhmässä kannattaa olla tilaajankin edustajia tai ainakin henkilöitä, joilla on hyvät ja kiinteät vuorovaikutussuhteet järjestelmän tulevien käyttäjien kanssa.

[keskival]

Meillä on käytännössä joka projekti feilannut, joissa on product ownerina käytetty toteuttajan omaa edustajaa. Tämä siksi, että tällä ei ole oikeasti käsitystä siitä mitä halutaan ja tarvitaan.

Onko sinulla jotain viitteitä tuosta antipatternista?

[keskival]

Jos se on antipattern, niin on outoa, että meillä on tyypillisesti tavattu tehdä asiat juuri niin, ja silloin asiat ovat toimineet. Tietysti se vaatii sitä, että product owner on teknisesti kompetentti henkilö.

[keskival]

Mutta tosiaan, tilaajan edustajia ja toteuttajan edustajia product owner teamiin on hyvä idea.

[keskival]

Ja tässähän tietysti puhutaan aliprojektin konfiguraatiosta. Tottakai kokonaisprojektiinkin voidaan konfiguroida jonkinlainen Scrum-tyyppinen integrointiryhmä.

[keskival]

http://www.scrumalliance.org/resources/1603

Täällä ei mainita Scrum anti-patterniksi sitä, että asiakas on product owner. Päinvastoin, product owner määritellään eksplisiittisesti niin, että asiakas voi olla product owner.

Product owner teamista mainitaan, että siellä täytyy olla yksi chief product owner, tietenkin, ettei tiimillä ole montaa kuunneltavaa ääntä.

[keskival]

Mainittava on myös, että toteuttajan vastuulla on esitellä metodologiansa, ja nämä ovat vain suuntaa antavia ohjeistuksia.

[hessuvi]

Laitosraportin muodossa tarinaa scrumista ja sen taipumisesta käyttöön: http://dspace.cc.tut.fi/dpub/handle/123456789/20718.

Loppujen lopuksi PO:n rooli on varsin ristiriitainen. Viitatussa artikkelissa kuva 9 kertoo, mikä PO:n aseman pitäisi olla. Silloin on kaiketi vähän maku asia, kummalta puolelta PO:ta raja vedetään. Mielestäni se luonnollisin ajatusmalli menee niin, että PO tekee strategisia päätöksiä ja toimittaja vastaa yhteisönä näistä päätöksistä tilaajalle. Eikä minusta tuntuisi erityisen vakuuttavalta, jos narikka luovuttaisi strategista päätösvaltaa jollekin ulkopuoliselle.

[keskival]

Sinne on nyt joka tapauksessa korjattu tuo product owner tiimi -asia, joten tämä alustava pull request voitaneen hyväksyä, että saadaan edes jossain määrin keskustelua oikeille urille ohjattua.

[hessuvi]

Yleisellä tasolla pari juttua vielä lisää.

Ketterät menetelmät eivät ole mikään kaikki ongelma ratkaiseva hopealuoti. Niiden tarina alkaa siitä, että DoD:n pomot eivät aikanaan jaksaneet lukea kuin kaksi ensimmäistä sivua W. W. Roycen paperista Managing the Development of Large Software Systems (http://leadinganswers.typepad.com/leading_answers/files/original_waterfall_paper_winston_royce.pdf) ja syntyi vesiputousmalli. Vesiputousmallissa unohdettuja asioita on tuotu mukaan ketteryyden manifestilla, mutta homma meni hiukan yli ja lisäksi sekaan eksyi turhan paljon kaupallista hypeä. Muutamia ketteryyteen liittyviä ongelmia sekä ketteryyden kaytännön soveltamista esitteli Esko Hannula testauksen teemapäivillä 2010: http://www.cs.tut.fi/tapahtumat/testaus10/Hannula.pdf.

Toiseksi olen äärimmäisen kiinnostunut kaikista tekniikoista, joilla keskustelua saa ohjattua ja pidettyä oikeilla urilla sekä kommunikoitua ja dokumentoitua esitettyjä ajatuksia tehokkaasti. Jeffrey K. Likerin hyvin ansiokkaasta ja myös ketteryyden syvintä olemusta valaisevasta kirjasta The Toyota Way pisti silmään A3-prosessiksi kutsuttu menetelmä http://www.coe.montana.edu/ie/faculty/sobek/a3/index.htm. Menetelmän nimi tulee siitä, että ajatustyön lopputulokset esitetään yhdellä A3-kokoisella sivulla. Se saattaisi sopia hyvinkin apuvälineeksi potilastietojärjestelmän hankintaprosessin suunnitteluun ja hankintaprosessista päättävät saattaisivat jopa jaksaa lukea sen kokonaan.

Minun puolestani voidaan siirtyä eteenpäin. Tässä vaiheessa on tärkeintä saada kaikki mieleen tulleet ideat kirjattua talteen.

[MikkoPaltamaa]

Itse olisin hyvin varovainen ketterien menetelmien kanssa. Niitä noudattamalla ilman todellista ymmärrystä aihepiiristä on mahdollista mennä tosi pahasti metsään.

Kannattaa huomata, että ketterissä menetelmissä on joitakin pahoja puutteita:

1) Extreme Programming -menetelmän pohjana on ajatus siitä, että asiakkaiden vaatimukset muuttuvat aina projektin aikana, joten projektit epäonnistuvat aina enemmän tai vähemmän. Tästä on päädytty johtopäätökseen, että kun joka tapauksessa tehdään vääriä asioita, niin tehdään ne mahdollisimman kevyesti ja joustavasti.

Väitän, että lähtöajatus on väärä. Ihmisten ja organisaatioiden tarpeet muuttuvat ajan myötä, mutta eivät yleensä kovin nopeasti tai radikaalisti. Taitavat tekijät pystyvät selvittämään todelliset tarpeet ja suunnittelemaan niihin aikaa kestävät ratkaisut. Olen nähnyt tästä lukuisia esimerkkejä. Ja niin kauan kuin tehdään oikeita asioita, niin ne voidaan tehdä yhtä hyvin ketterällä prosessilla tai vesiputousmallilla.

On siis paljon hyödyllisempää keskittyä alusta lähtien siihen, että tehdään oikeita asioita, kuin että tehdään mitä tahansa asioita tietyn prosessin mukaan ja toivotaan parasta.

2) Hyvin usein ketterissä projekteissa unohdetaan aihepiiriin perehtyminen ja huolellinen suunnittelu, joko laiskuuden tai taidon puutteen takia. Sen sijaan syöksytään tekemään vääriä asioita nopealla aikataululla. Ongelma johtuu kai pitkälti siitä, että ohjelmistoala on nuoruutensa takia vielä aika kehttymätön.

Verrataanpa tätä rakennusten rakentamiseen. Aika harvassa isommassa rakennusurakassa jätetään arkkitehdin työ tekemättä sillä perusteella, ettei siihen ole rahaa tai aikaa. Kyllähän rakennusinsinöörit varmaan saavat jotakin aikaan ilman arkkitehdin suunnitelmia, mutta lopputulos on todennäköisesti aika erilainen. Eikä varmastikaan yhtä hyvä.

3) Ketterissä projekteissa on usein tapana jättää suunnittelu sen tahon vastuulle, jolla on siitä vähiten osaamista: asiakkaalle. Sellainen johtaa lähinnä katastrofiin. Asiakkaalla on toki eniten tietoa sovellusalasta, mutta se ei vielä tee kenestäkään hyvää suunnittelijaa.

Riittävä tieto sovellusalasta on huomattavasti helpompaa hankkia kuin riittävä osaaminen suunnittelusta. Tämän takia järkevissä projekteissa suunnittelijat selvittävät tarvittavat tiedot sovellusalasta asiakkaalta ja loppukäyttäjiltä ja suunnittelevat sen jälkeen hyvät ratkaisut heidän todellisiin tarpeisiinsa.

[MikkoPaltamaa]

Ja mitä tulee product owneriin, rationaalisesti asiaa lähestyen sopivin henkilö product owneriksi täyttää ainakin seuraavat ehdot:

1) Product ownerilla tulee olla motiivit mahdollisimman hyvän lopputuloksen aikaansaamiseen käytössä olevilla resursseilla.

Julkisissa hankinnoissa tämä on hankalaa. Yritysasiakkaalla on periaatteessa aina nämä motiivit, mutta julkisella puolella ei välttämättä. Järjestelmätoimittajalla on yleensä päinvastaiset motiivit, eli minimoida oma työmäärä ja maksimoida lisätyötilaukset. Ulkopuolisella suunnittelijalla tai muulla kolmannella osapuolella olisi nämä motiivit ainakin siinä tapauksessa, jos niistä saa jotakin hyötyä projektin valmistumisen jälkeen.

2) Product ownerilla tulee olla mahdollisimman hyvä näkemys siitä, millainen järjestelmän tulee olla täyttääkseen tarkoituksensa. Eli toisin sanottuna riittävästi tietoa aihepiiristä ja osaamista suunnittelusta.

Asiakkailla on paljon tietoa aiheesta, joten siltä kannalta he olisivat hyviä. Toisaalta, asiakkaat ovat normaalisti huonoja suunnittelijoita, eikä heillä ole tietoa siitä mitä voidaan tehdä ja mitä muualla tehdään. Järjestelmätoimittajalla saattaa olla tai saattaa olla olematta hyvää osaamista suunnittelusta ja tarpeiden selvittämisestä, firmasta riippuen. Yleensä kuitenkin huonoa. Suunnittelufirmalla todennäköisesti olisi hyvää osaamista tästä aiheesta.

Kohdasta 1 vielä: Hyvin järjestetyssä hankinnassa kaikki osapuolet hyötyisivät sitä enemmän, mitä parempi lopputulos on. Tällöin kaikilla osapuolilla olisi intressit järjestää projekti parhaalla mahdollisella tavalla ja tuottaa hyvää laatua. Tämä asia pitäisi siis aivan erityisesti varmistaa kaikkien osajärjestelmien hankinnoissa. Jonkinlainen bonuspalkkiosysteemi ja lisätilaukset toiminevat parhaiten, ainakin jos vendor lock-in on saatu vältettyä.

[keskival]

Agile-menetelmät ei ole mikään hopealuoti, eikä sillä ole tarkoitus tappaa ihmissusia. Se nyt on vaan niin, että julkishankinnoissa sitä pitäisi käyttää. Se on kyllä speksattu ihan tavoitteeksi generaalilla tasolla, mutta nämä, jotka hankintoja tekevät, eivät aina osaa ja uskalla formuloida tarjouspyyntöjä niin kuin ne pitäisi ohjeistuksien mukaan tehdä. Siksi tässä kiinnitetään siihen huomiota. Isoissa projekteissa, joilla on riski mennä metsään, agile menetelmät lisäävät tilaajan kontrollia ja projektin näkyvyyttä, joka on äärimmäisen tärkeää.

[keskival]

Eli käytännössä vaihtoehdot ovat: a) agile-menetelmät, ja b) olemassaolevien julkishallinnon best practicessejen ja ohjeistuksien vastainen kilpailutus.

[keskival]

Lisäksi on tietysti hyvä pitää mielessä kun noita projekteja ruvetaan toteuttamaan, nämä Scrumin antipatternit. Käytännössä agile-menetelmät menestyvät kaikilla mittareilla paremmin ja tehokkaammin kuin vastaavat perinteiset mallit, että tässä ei siis varsinaisesti ole mitään kilpailua olemassa.

[MikkoPaltamaa]

Jees, samaa mieltä tuosta. Minusta on kuitenkin erittäin tärkeää määritellä suunnittelu- ja toteutusvaihe erikseen, koska muuten ensin mainittu jää tekemättä. Iteraatioihin perustuvassa mallissa tämä voi tapahtua vaikkapa siten, että ensimmäiset 5 iteraatiota ovat pelkkää suunnittelua, minkä jälkeen vasta alkaa toteutus.

Lopputestauskin kannattaisi ehkä määritellä erikseen, vaikkapa niin että viimeiset iteraatiot ovat testausta tms. Testaus jää hyvin usein tekemättä järjestelmätoimittajan laiskuuden takia, ellei sitä erikseen vaadita ja pakoteta siihen.

[keskival]

Kokonaisarkkitehtuurialiprojekti pitäisi mainita erikseen, mutta nyt en ehdi sitä muotoilla. Aliprojektien sisällä, tarjoaja kuvaa menetelmänsä, ja sen uskottavuus arvioidaan. Niitä ei speksata etukäteen, vaan se on jopa arvokasta tietoa selvittää tarjousvaiheessa osaako ja pystyykö tarjoaja suunnittelemaan viabiilin projektin.

[keskival]

Tämä pull request pitäisi vihdoin hyväksyä, että muutkin voivat tehdä siihen korjausehdotuksia. Alkaa pikku hiljaa näyttämään siltä, että koko työ täytyy forkata, jos administraattorit ovat nukkumassa.

[pe3]

Hyväksyin tämän vaikkakin hieman sekavin mielin sen suhteen miten meidän pitäisi ratkoa näkemyseroja. Olet @keskival siinä kyllä oikeassa, että requesteja nyt vaan pitää hyväksyä. Se on joka tapauksessa parempi kuin hieroa asioita täällä kommenteissa.