Huomaa että Ossi ei ole tämän ohjelmistokehityksen konsultti Muuten nimittäin tietäisi, että tuota vesiputousmallia ruvettiin välttämään sen kankeuden takia jo kauan sitten, 80-luvulla. Sen jälkeen sitä on käytetty paljon vähmemän kun yleensä uskotaan, varsinkin itse viimeinen vesiputousmalli-projekti oli vuonna 93 tms.

Sen jälkeen on ollut spiraalimallia jne. Nyt viime aikoina tietysti ovat tulleet ketterät menetelmät, joista scrum on yksi hyvä, mutta ei kuitenkaan paras tai ainoa esimerkki.

Ossin pointti hinnoittelusta on sen sijaan osuva, ja olen siitä samaa mieltä. Ohjelmistot monimutkaistuvat muutenkin niin paljon, samalla kun alan historia on todella lyhyt. Tämä johtaa pakostakin hankaluuksiin kustannusarvioissa. Alalle ominainen kusetus on kuitenkin törkeää ja siitä pitäisi päästä eroon.

Yksi hyvä idea ketterän ohjelmistokehityksen hinnoitteluun on tunti+könttähinnoittelu. Eli ensin tehdään puolet projektista tuntityönä ja sen jälkeen kun ohjelmiston ja ongelman laajuus alkaa olla selvillä jollain tasolla voidaan tehdä lopullinen arvio projektin hinnasta.

Mielestäni hinnoittelun tai määrittelyn vaikeus ei saisi estää ketterien menetelmien käyttöä (eikä ainakaan suosia vesiputousmallia), vaan toimintatapojen on muututtava. Niin vaikeaa kuin se tilaajan onkin ymmärtää ettei tiedä mitä haluaa.

Näitä sopimusmalleja on hiottu jo jonkin aikaa. Yksi lista, josta voi asiaa tutkailla lisää:
http://agilesoftwaredevelopment.com/blog/peterstev/10-agile-contracts

Suomessa tiedän muutamien ketterien alihankintatoimitusten sopimuspohjan olleen Time&Materials-mallin mukainen.

Vielä mainos mukaan: Olen mukana järjestämässä Scan-Agile konfrenssia, johon suosittelen kaikkia ketteryydestä kiinnostuneita tahoja osallsitumaan. Tilaisuus (maksullinen, 350€ / 2 päivää) järjestetään Finlandia-talolla 15-16 päivä lokakuuta. Lisää tapahtumasta: http://www.scan-agile.org

Yleensä kun lähdetään tekemään hinta-arviota pitää olla selvillä myös vaatimukset. Kehittäjät ovat yleensä aika hyviä arvioimaan paljon johonkin tiettyyn asiaan menee aikaa ja näin ollen osaavat arvioida työmäärän jonka pohjalta sitten hinnan arvioiminenkin sujuu suht helposti.

Itse kehittämismenetelmähän (srum/vesiputous) ei niihin työmääriin vaikuta kuitenkaan.

Kaimani Anonyymi ei ole tajunnut, että scrum-projekteissa nimen omaan vaatimukset koko ajan muuttuvat. Eli kun vaatimukset eivät ole selvillä, on aika vaikeaa antaa hinta-arviota.

Itse asiassa kehittäjät – kuten muutkin ihmiset – ovat järjestäen mahdottoman huonoja arvoimaan absoluuttisia aikoja. Tehtävien asioiden vaatiman työmäärän tai monimutkaisuuden suhteellisessa arvioinnissa ihmiset ovat jonkin verran parempi.

Mikäli verrataan työn suorittavan asiantuntijaporukan tekemää arviota itse työtä tekemättömän ihmisen hatusta vedettyhin arvioihin on ero melkoinen. Verrattuna asioihin oikeasti kuluvaa aikaa molemmat arviot ovat metsässä.

Koska arviointi on niin pirun vaikeaa Scrumissa ja muissa ketterissä menetelmissä pyritään suhteellisiin arvioihin ja/tai työn etenemisen mittaamiseen (“empirical process vs. prescriptive process”).

Tässä aiheesta yksi tutkimus:

M. Jørgensen, and S. Grimstad. The Impact of Irrelevant and Misleading Information on Software Development Effort Estimates: A Randomized Controlled Field Experiment, Submitted to IEEE Transactions on Software Engineering, 2009.

http://simula.no/research/engineering/publications/Simula.SE.299/simula_pdf_file

Mitä sopimusmallehin tulee, on esitetty että koko ajattelutapa missä ohjelmisto ostetaan hyödykkeenä on poskellaan. Pikemminkin pitäisi pyrkiä ajattelumalliin missä asiakas ostaa kokemuksen missä hänen ongelmansa ratkaistaan yhteistyössä toimittajan kanssa.

Standish Groupin usein siteeratun tutkimuksen mukaan 70% keskivertoohjelmistoprojektin vaatimuksista muuttuu projektin aikana.

Vaikkei tutkimukselle paljoa painoa laittaisikaan, vaatimusten ennakoinnin tekee haasteelliseksi mm. seuraavat seikat:

1) Käyttäjät eivät järjestäen osaa kertoa tarpeitaan. Se mitä he luulevat tarvitsevansa eroaa usein siitä mitä he tarvitsevat.

2) Ohjelmiston tai IT-järjestelmän käyttöönotto muutta käyttäjien ja organisaatioiden tapoja toimia. Muuttuneet toimintatavat johtavat muuttuneisiin tarpeisiin joita vaatimusmäärittelyssä ei osattukaan ottaa huomioon.

3) Määrittely-, analyysi- ja suunnitteluvaiheissa voi sattua virheitä ja väärinymmärryksiä.

Loppujen lopuksi harvassa projektissa vaatimukset ovat koskaan selvillä ja vaikka ovatkin, ne muuttuvat. Ainut varma tapa toimittaa järjestelmä joka täyttää käyttäjien oikeat tarpeet on kokeilla järjestelmää tosielämässä ja muuttaa järjestelmää oikeasta käytöstä saadun palautteen perusteella.

Vesiputous on ainoa vaihtoehto kun hanke on suuri (esim hinta yli 1 M€) ja hankinta toteutetaan kiinteähintaisena. Muussa tapauksessa epäonnistuminen on lähes taattu.

Pääsääntöisesti aasiakas ei tiedä riittävän tarkasti mitä on ostamassa ja määrittelyvaiheessa, kun speksit pitäisi prosun ja sopparin mukaan hyväksyä ja kiinnittää tulee niihin lukematon määrä muutoksia. Aasiakas näkee muutokset vain tarkennuksina ja toimittaja näkee samat asiat muutoksiana.

Yleensä prosussa ja sopimuksessa on kuvattu mikä on muutos ja mikä on tarkennus mutta jostain kumman syystä aasiakkaan silmissä niillä ei näytä olevan mitään merkitystä… Tällöin vaaditaan toimittajalta suurta tarkkuutta ja tiukkaa otetta. Tästä määrittelyjen täsmennyksestä tulee poikkeuksetta aina riita.

Jos määrittelyissä antaa aasiakkaalle periksi on sama kun antaisit pirulle pikkusormen: määrittelyjä ei koskaan saada hyväksytyksi kun sisältö paisuu ja mieli muuttuu.

Vasta kun määritykset on hyväksytty ja jäädytetty voidaan alkaa suunnittelu ja toteutus. Ei sekuntiakaan aikaisemmin.

Näiden jatkuvien muutoksien ja priorisointien osalta saadaan vesiputousmalli näppärästi käännettyä iteratiiviseen kehityshankkeeseen jolla ei ole loppua: kustannukset ja aikataulut paukkuvat. Loppupelissä toimittaja vielä maksaa kunnon sanktiot viivästyksestä.

Toteutusvaiheessa muutoksia voidaan ottaa vastaan vain kun tilanne on aasiakkaan osalta ehdottoman välttämätön. Loput muutokset tehdään mieluiten käyttöönoton jälkeen takuuaikana tai takuuajan jälkeen.

Yleensä ostaja ei ole ammattilainen (vaikka niin luulevat) ja asiakkaalla ei ole mitään käsitystä miksi hankkeessa on muutoshallinta. Toimittajan pp:t ovat usein myös liian helposti taipumassa aasiakkaan tahtotilaan eivätkä ymmärrä tai muista että hanketta ohjataan yhdessä sovitulla prosulla ja sopimuksella.

Scrum-mallit ja ketterät menetelmät ovat paikallaan vain ja ainoastaan silloin kun aikataulu ja budjetti joustavat.

Jos ostajana haluaisin hyvän ja toimivan ratkaisun ilman jatkuva riitelyä, ostaisin ratkaisun time&material –pohjalta ketterillä menetelminä tehtynä (iteratiivinen, inkrementaalinen, protoilu, scrum, whatever …). Tällöin luovuudella olisi tilaa ja lopputulos olisi varmasti hyvä. Vastaavasti jos hanketta ohjataan budjetin kautta, niin osto tehtäisiin kiinteähintaisesti. Tällöin kyllä varaisin todella paksun lompakon juristien käyttöön, jotta oma perse ei pala…

Tekisi mieli kirjoittaa kirja ja väikkäri näistä IT-hankkeista, julkisesta hankintalaista (,joka on täysin huuhaata) /toimittajien ja aasiakkaiden osaamattomuudesta.

Mistä saisin tietoa ja referenssejä Scrumista?

@kädeton win-only-ylläpitäjä: mitä tietoa ja minkälaisia referenssejä tarvitset?

@Marko: “Kädetön” on trolli. Älä ruoki sitä.

Isot projektit tulevatkin jo oletuksena epäonnistumaan, niin turha niissä on kehitysmenetelmistä stressata. Otetaan vaikka seuraavanlainen lainaus osoitteesta http://www.it-cortex.com/Stat_Failure_Rate.htm:

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

Ja lopultahan jokin seuraavista yleensä joustaa: budjetti, aikataulu, ominaisuudet tai laatu.

Mistä saisin tietoa ja referenssejä “trollista”?

Sitten tähän liittyy myös lainsäädäntö, esim. siinä että tietyn hintaluokan julkiset hankinnat on kilpailutettava. Ja aika vaikeaa kilpailuttaa tai tietää jonkin hintaluokkaa, jossei tiedetä vielä, mitä halutaan? Eli siinä mielessä kyllä tietty vaatimusmäärittely on tarpeen myös jatkossa ja näissä ketterissä menetelmissäkin. On myös huomattava se että fiksusti tehty vaatimusmäärittely ei ota kantaa juurikaan tekniseen toteutusratkaisuun, vaan määrittelee sen ja eri teknisten toteutusvaihtoehtojen “yläpuolella” sen, mitä järjestelmän halutaan (jollain tavalla) tekevän.
Hyvin ja oikeaoppisesti tehty vaatimusmääritely on teknologia-riippumaton ja myös kestää ajassa pidempään. Mutta toki asiaan liittyy myös arkkitehtuurin eri näkökulmia, eri aikajänteillä.
Ketterät menetelmät sopivat näissä osaan tekemisestä, osaan sopivat vähän toisenlaiset menettelyt.
Yleensähän uutta teknologiaa, jota ict-puolella tulee eteen koko ajan, myös koestetaan ensin jossain koe/pilottiprojektissa, jotta opitaan siitä.
Myös ei-julkisella puolella suunnitellaan liiketoimintaa ja sitä varten tarvittavia ict-ratkaisuja eri tavoin, niiden koon ja erinäisten muiden asioiden valossa, eikä vähäisempinä kriittisyys liiketoiminnassa, miä ei mitenkään välttämättä korreloi aina muiden asioiden kanssa.

Ensin ei ollut menetelmää, sitten tuli häslätään spagettia menetelmät, vesiputous, iteroiva ja limitetty vesiputous (spiraali), ketterät menetelmät scrummeineen ja tdd:een ja seuraavan aletaan hehkuttamaan leania.

Kyllähän näitä on nähty ja tullaan näkemään. Kaikilla mennään metsään, jos itse menetelmästä tulee se pääasia projektissa. Lean on tästä oikeastaan piristävä poikkeus. Siinä vain halutaan valmista mahdollisimman “nopeasti” ja halvalla, eli poistetaan kaikki hukka.

Oikeastaan on hyvä sopia, että vedetään tämä projekti tällä mallilla ja sitten noudattaa sitä tarpeen vaatiessa löyhästi. Etenkin jos kyseessä on isohko kehittäjäporukka, on toivotonta odottaa, että jokaiselle heistä sopisi esim. Scrummin vaatima tapa raportoida tekemisistään joka päivä. Toisia tämä motivoi tekemään paljon ja toisia demotivoi, koska he “kuvittelevat” sen olevan niskaan hengittämistä.

Joku päivä kun olen itse päässyt niin korkealle asemalle, että voin näihin vaikuttaa kehitän “ihmiskeskeisen ohjelmistokehityksen mallin”. Siinä mallissa jokaiselle annettaan rauha työskennellä oman tyylinsä mukaan hirttäytymättä johonkin tiettyyn malliin, unohtamatta kaikkia kehityksen tärkeitä malleja.

Tämä oikeastaan toimiikin jo.. open source puolella.

Mielestäni oleellista ei ole menetelmä, vaan se että liiketoiminta tietää ja saa sen mitä se haluaa jatarvitsee. Kaikki lähtee liiketoiminnan ydinprosesseista ja niiden kehittämistarpeista. Yhdelläkään järjestelmällä ei ole olemassaolon oikeutusta ilman liiketoiminnallista funktiota. Niin ja puhun tässä siis tietojärjestelmistä, en ohjelmistoista tai tuotteista.

Suurin osa tietojärjestelmän elinkaaren aikaisista kustannuksista muodostuu sovellushallintavaiheessa ei suinkaan suunnittelu tai toteutusvaiheessa. Tästä syystä erityisen tärkeää on kaiken kattava ja reaaliajassa ylläpidettävä dokumentaatio järjestelmän toiminnasta. Dokumentaatio, jonka notaatio muodostaa katkeamattoman ketjun ydinliiketoimintaprosessikartasta komponenttikuvauksiin saakka.

Miten ihmeessä kaikki nämä uusinta hienoa fiilistelevät höyrypäät saataisiin tuottamaan tälläistä jälkeä agile-menetelmiä käyttäen tai edes jotain menetelmää käyttäen.

Varsinkin jos kysymys on lakeihin perustuvista järjestelmistä, joissa tuotantoonsiirto voidaan tehdä vasta kun AIVAN KAIKKI IHAN VARMASTI toimii niin kuin laki edellytää…

Keisarin uudet vaatteet. Scrum on hieno nimi sille tavalle tehdä softaa, mitä käytettiin ennen vesiputousmallia

Agilea jo kokeiltu ja niin myös perinteistä vesiputousta. Molemmissa on hyvät ja huonot puolensa.
Agilen tuominen ymäristöön, missä 30 vuotta on tehty vesiputousmallilla töitä, on suorastaan painajainen.
Arkkitehdit pois, systeemisuunnittelu pois, projektipääliköt pois, dokumentointi pois. Tilalle päivittäiset 15 min palaverit, backlog josta kukaan ei ota tolkkua, kaaoksenomainen tuotteenhallinta, kokeilemalla koodaaminen, jatkuva ympäristön muuttuminen, kaikki koodaa kaikkea. Lisäksi ohjelmistotyökalut ja vanha koodipohja 80-luvulta ei tue tällaista ketterää toimintaa.

Ainakin konsulttifirmat tekevät agilen avulla tiliä.

Ketterän projektin voi paketoida ja myydä vesiputouksen tapaan könttäsummalla, jos asiakas sellaista kaipaa. Eli tehdään asiakkaan antaman speksin mukaisesti niin hyvä arvio ominaisuuksien toteutushinnoista kuin pystytään. Tässä voidaan käyttää esim. Scrumin arviointimenetelmiä, jotka yleensä antavat paremman tuloksen kuin pelkkä yhden analystin tekemä mutu.

Kun se ketterä työmääräarvio on sitten saatu valmiiksi (Scrumin mukaan siis IET-yksikköinä, jotka kerrotaan tiimin aiemman toiminnan perusteella muodostuneella nopeuskertoimella), ja läiskitään kavereiden tuntihinta mukaan, saadaan suhteellisen uskottava toteutushinta. Sitten lisätään siihen sopiva marginaali yllätysten varalle (20%? 50%?) ja pistetään tarjous menemään.

Jos tarjous sitten voittaa, voidaan sanoa, että “Hei, me tehdään tätä ketterästi. Te saatte kerran kuussa proton arvioitavaksi ja saatte muuttaa speksiä jos niin haluatte. Mutta jos ei kiinnosta, niin nähdään sitten 18kk:n päästä valmiin softan kanssa.”

Kiinteän summan tarjous kulkee ketterissä piireissä nimellä “highest cost, latest delivery”. Eli se on selvästi kalliimpi ja hitaampi kuin jos homma tehtäisiin ketterästi tuntiveloituksella, koska asiakas todennäköisesti olisi ennen 100% feature-toteutusta jo tyytyväinen tulokseen. Noin mm.

Tarmo, tuo esimerkkisi ei ole tästä maailmasta.

Yksikään itseään kunnioittava ja ammattitaitoinen ohjelmistotoimittajatalo ei KOSKAAN lähde tarjoamaan kiinteähintaista projektia, jos projektin määrityksissä on epäselvyyksiä. Ja näitä on lähes aina, ellei speksiä ole todella tarkasti hierottu etukäteen kuntoon.

Mitä jos Agile Oy:n speksianalyysissä on ymmärretty merkittävässä määrin pieleen tarvittavat ominaisuudet (silta joen yli ei riitäkään, oikeasti tarvitaan koko kaupungin joukkoliikennejärjestelmä)? Ja samaan aikaan on sitouduttu jo kiinteähintaiseen toimitukseen. Kusessa ollaan.

Aina pitää myös varautua siihen, että asiakas katsoo Agile Oy:n bluffin ja sanoo: “Okei, menkää ja tehkää. Maksu seuraa kun softa täyttää speksit täydellisesti”.

Määrittely kuitenkin tehdään joka tapauksessa. Alkuvaiheessa pitää tietää suunnilleen mitä halutaan ja pitää osata kuvata se jollain tasolla. Ei voi olla niin, että alkurajaus esittää yhtä mutta myöhemmin paljastuu, että mitä halutaankin onkin moninkertaisen työn takana. Eli määrittelyjen ja alkurajausten tulee kyetä vastaamaan todellisuutta jossain määrin. Mikäli vastaavuus on hakusessa, niin silloin määrittelyn elementit ja alkeistekijät ovat hakoteillä.

Toisin sanoen, kun määrittelyitä tehdään, niiden pitää perustua paitsi tavoitteisiin niin myös tulevaan toteutukseen. Esimerkiksi jos ollaan määritelty rakennettavaksi talo, niin “talo”:n käsitteen pitää olla määritelty ensin. Tarkoittaako talo ihan mitä tahansa rakennusta vai omakotitaloa? Määrittelyssä ei voi olla että rakennetaan talo, jos talon käsite on auki. Ja tuleeko talo metsään vai kaupunkiin.

Kun järjestelmää lähdetään sitten toteuttamaan, myös yksittäisten piirteiden määrittelyjen käsitteiden tulee vastata todellisuutta jo ennen toteutusta. Ei voida määritellä järkevästi, että järjestelmä ratkaisee jonkin ongelman, jos ei ole selvyyttä siitä, että ongelma on teknisesti ratkaistavissa.

Vaatimukset muuttuvat matkan varrella, mutta kun järjestelmää rakennetaan, tulee ottaa huomioon myös toteutuksen haasteet. Jos jo tehtyjä toimintoja jatkuvasti muutellaan, niin lisäähän se kustannuksia. Mikäli järjestelmän helppo ylläpidettävyys ei ole ollut yhtenä suunnittelutekijänä, sitä vaikeampaa se ylläpidettävyys sitten on. Projekteissa tulee kiinnittää enemmän huomiota yleiseen laatuun, määrittelyiden toteutuksellisuuteen ja ohjelmistokehitysprosessiin muutenkin. Tämä taas helpottaa työmääräarvioita.

>Yksikään itseään kunnioittava ja ammattitaitoinen >ohjelmistotoimittajatalo ei KOSKAAN lähde tarjoamaan >kiinteähintaista projektia, jos projektin määrityksissä on >epäselvyyksiä.

Valitettavasti tilanne ei tämän osalta pidä paikkansa. Lähes kaikki julkisen sektorin (puhumattakaan yksityisestä sektorista) suurimmat hankinnat tehdään tällä hetkellä kiintähintaisena – sisältäen määrittelyn ja toteutuksen. Tarjouspyynnön yhteydessä on vain vaatimusmäärittely – ja sekin alustavana. Työmääriä arpoessa helpottaa merkittävästi jos ymmärtää asiakkaan liiketoimintaa hyvin ja jos pystyt uudelleenkäyttämään joitakin osia aiemin tehdyistä järjestelmistä, vaikka puoliväkisi.

Jos taas nämä isot hankkeet hinnoitellaan toimittajan osalta mitenkään turvaavasti, niin varmasti häviät kilpailun.

Kilpailu johtaa siihen tilanteeseen, että vain isot IT-talot voivat ottaa suuria riskejä näissä kiinteähintaisissa hankkeissa ja pikkuputiikit ovat ulkona kisasta. Projektien jälkeisessä ylläpidossa ja kehityksessä, joka on turvallista rahaa, voi sitten jossakin määrin pyrkiä kompensoimaan projektin tuomia tappioita.

Viimeisessä isossa kilpailussa jonka tuloksia selasin, oli sellainen tilanne että voittajan kustannus ja työmäärä oli alle kolmasosa kalleimman tarjouksen työmäärästä ja hinnasta. Ja tiedän että voittaja tekee tällä hankkeella useamman miljoonan tappiota.

Tuollaisessa valmiiksi tappiollisessa projektissa onkin sitten kiva kiristellä hampaita ja laskea tappioita. Toivottavasti maksumiehiksi tässä keississä ei joudu ko organisaation ruohonjuuritaso.

> Yksikään itseään kunnioittava ja ammattitaitoinen ohjelmistotoimittajatalo ei KOSKAAN lähde tarjoamaan kiinteähintaista projektia, jos projektin määrityksissä on epäselvyyksiä

Tässä kohdalla tuli lauantai-olut nenästä röhönaurun myötä.