Ketterä hankintakäytännössäPetri Aukia28.5.2013
Hyviä neuvoja vaikea noudattaa
Ideaalimaailmassa
Vanhoista tavoista on vaikea luopua
Pahimmat pulmat
Suurimmat riemut
Pahimmat pulmat
Luottamus tärkeintä
Luottamusvaihe alkuun
Kirjalliset vaatimukset?
Asiakkaan panos
Samassa huoneessa
Kalaporrasmalli
Laadusta neuvottelu
Käyttöliittymän laatu
Osaanko ostaa?
Nyrkkisääntö: 1/2
Kenen tarpeet?
Yksinkertainen on kaunista
Entä jos ei onnistu?
Asiakkaan oppimiskokemus
Työmäärän arviointi
Kenen sana on lopullinen?
• Luottamus-sprint 0• Vaatimusmäärittely backlogiin• Riittävä asiakkaan panos• Pakolliset vaatimukset eivät vie koko budje...
Kuvat: flickr.com / CC• Johnson_cameraface• Legoloverman• Jamie in Bytown• 4nitsirk• Frank3.0• Goarmyphotos• Leshaines123•...
Upcoming SlideShare
Loading in...5
×

Miten ketterän hankinnan ongelmat vältetään, Petri Aukia

338

Published on

Kuinka ostaa ketterästi julkishallinnossa III
Codenton aamiaistilaisuus 28.5.2013

Miten ketterän hankinnan ongelmat vältetään
Petri Aukia, Codento

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
338
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Neuvoista Hyvät neuvot tuntuivat huuhaalta Helposti noudatettavat neuvot olivat loppujen lopuksi turhia Uusi toimintamalli vaatii muutoksia sopimuksissa sekä toimintatavoissa. Päälleliimattu ketteryys on tyhjää huonompaa.
  • Ideaalimaailma Valtuutettu tuoteomistaja Joustava backlog Kaikki samassa huoneessa Budjetissa varaa iterointiin Kokeneita Kehittäjiä Tuoteomistaja Scrum master
  • Kitkaa Kitkaa tulee ketterän maailmankatsomuksen ja totutun hankintaprosessin välillä. Puhun siitä, miten tätä kitkaa olemme hallinneet. Osa haasteista on siis väliaikaisia Silti ketterän menetelmän puolestapuhuja joutuu vetämään kovaa, jotta muiden maailmankatsomus saadaan muutettua Vetämisessä onnistuneet hankkeet ovat kullanarvoisia
  • Pahimmat pulmat Hankkeet jotka eivät valmistu Budjettiylitykset Laatuongelmat, havaittuna liian myöhään Suorituskyky Skaalautuvuus Tietoturva Integrointi Tuotantoonvientivaikeudet Vaikeudet seuraavan version teossa
  • Parhaat riemut Läpinäkyvyys Homma kerralla kuntoon Tehokkuutta Puhe ja koodaus järjettömien dokumenttinippujen sijaan Nopeutta Kehittämistä ilman pitkää suunnitteluvaihetta Pikaprojektien mahdollisuus Sitoutumista Ei vaihtuvia kehittäjäporukoita Ammattiylpeyttä Vaikeita osioita voidaan suunnitella ja kypsytellä pitempään
  • Pahimmat pulmat Hankkeet jotka eivät valmistu Budjettiylitykset Laatuongelmat, havaittuna liian myöhään Suorituskyky Skaalautuvuus Tietoturva Integrointi Tuotantoonvientivaikeudet Vaikeudet seuraavan version teossa
  • Luottamus Kaikki tietojärjestelmähankkeet mahdottomia ilman luottamusta Sopimus ei juuri vaikuta luottamukseen Myös vesiputousmallissa Älä ota epäluotettavia tarjouksia huomioon Luottamusta voi vahvistaa… lisää tästä seuraavilla kalvoilla
  • Alkuun luottamusvaihe Kutsutaan myös nimellä 0-sprint Asiakas selittää kaiken juurta jaksaen toimittajalle Esimerkkejä Esimerkkisaitteja julma määrä Näyteään muita ohjelmistoja Annetaan vaikka oppikirjoja terminologian selittämiseksi Paperiesimerkkejä Excursio jonkin loppukäyttäjän luokse Suoritteita Tiimi näyttää osaamistaan Yhteistyötä Budjetoitava Jaettu maailma tavoitteena Luottamusvaihe on leivottava sopimuksiin. Ei saa käydä niin, että luottamusvaihe kulutetaan teknologiaympäristön asentamiseen
  • Jos kirjallinen vaatimusmäärittely sopimuksen pohjana Suosittelen vaatimusmäärittelyn yhdessä uudellenmäärittämistä backlogiksi Sopimuksellisesti siis ensimmäinen yhdessä hyväksytty backlog korvaa mahdollisen vaatimusmäärittelyn. Lopullisesti. Tekee tiedonjaon näkyväksi Toimittajan ymmärrettävä mitä tehdään Mukaan myös ei-funktionaaliset vaatimukset
  • Asiakkaan panos, eli veri, hiki ja kyyneleet Ketterän hankkeen asiakkaan työmäärä on merkittävä 20% nyrkkisääntö pienissä hankkeissa Puolet asiakkaan tuoteomistajan tekemää Loppukin pitää saada … jos ei muita saa, saa hankkeen rikki Kymmenen hengen tiimi tarvitsee täysipäiväisen tuoteomistajan
  • Samassa huoneessa Hankkeen alussa kaikki joka päivä samaan huoneeseen Myöhemminkin koko kehitysporukka päivittäiseen palaveriin samaan tilaan Jos kehittäjät eivät osaa/voi/uskalla puhua asiakkaalle päivittäin, rahaa palaa varmasti hukkaan ja laatu kärsii Usein kannattaa yhdessä skissata paperille, mitä on tarkoitus tehdä Yllättävän usein puhe tulee väärinkäsitetyksi
  • Kalaporrasmalli Jos hankkeen koko budjetti menee etukäteen suunniteltuihin pakollisiin osiin hanke ei ole ketterä Ketteryyden simulointi … kivuliasta ja kallista Laatu voi silti olla näin tehtynä parempi kuin ei-iteratiivisesti tehtynä Tuskin kuitenkaan edullisin tapa edetä Vaatii piinkovan projektipäällikköparin toimittajalta ja asiakkaalta Ketterissä malleissa kun tarkoitus on tehdä suunnitelmien muuttaminen mahdollisimman helpoksi
  • Laadusta neuvottelu Luottamus ei riitä, tarvitaan mustaa valkoisella Itse suosittelen, että ohjelmiston näkyvät laatukriteerit kuvataan sopimusliitteeseen ja lyödään lukkoon hankkeelle luontevassa vaiheessa, viimeistään arkkitehtuurisuunnittelun yhteydessä Näitä ovat muun muassa: Suorituskyky Esim “98% sivuista saadaan ladattua alle sekunnissa” Tai “ Maksutapahtumista 99% tapahtuvat tuotantoverkossa alle viidessä sekunnissa ” Skaalautuvuus Esim “ Palvelinten määrän nelinkertaistaminen tuo kolminkertaisen avoimien yhteyksien määrän ” Virheettömyys Esim “ Ei yhtään kriittistä tai merkittävää virhettä tuotantoon viedessä ” Käytettävyys Esim “80% testikäyttäjistä saa tehtyä ensimmäisen matkalaskunsa auttamatta alle viidessä minuutissa” Tai “80% testikäyttäjistä löytävät päätoiminnallisuudet auttamatta ensimmäisen tunnin aikana” Tietoturva Tuotteelle on tehty OWASP Top-10 tarkastukset Tuote läpäisee tietoturvatarkastuksen, joka toteutetaan menetelmällä … Tuotteessa on kaikki sen kirjastojen tietoturvapäivitykset Selainyhteensopivuus Tuote toimii selainversioilla x,y,z Matkapuhelinyhteensopivuus Tuoteen yksikään sivu ei ylitä leveydeltään iPhone Safari-selaimen ikkunaa matkapuhelimella katsottuna Huom. Monet tärkeät vaatimukset ovat lähinnä ylläpitoa ei kehitystä koskevia Tuotteen sisäistä laatua koskevat vaatimukset eivät niin luontevia sopimuksessa Ylläpidettävyys, testattavuus, joustavuus Specific, Measurable, Atteinable, Relevant, Traceable http://scaledagileframework.com/nonfunctional-requirements/
  • Käyttöliittymän laatu Kerralla tehty Kolmen iteraation Viiden iteraation käyttöliittymät
  • Osaanko ostaa? Usein asiakkaan kannattaa tilata joku, joka osaa varmistaa, että softa tehdään oikein Täsmärekrytointi? Hankintakonsultti? Ketterässä mallissa vaatimuksia hierotaan koko hankkeen ajan Konsultille on tarvetta koko hankkeen ajan Väärien alussa tehtyjen ratkaisujen purkaminen voi olla mahdotonta Aloittamisen kiirehtiminen tulee kalliiksi
  • Ensimmäinen nyrkkisääntö Hyvä projekti: 1/2 budjetin kohdalla hankkesta on riittävä toiminnallisuus ja laatu saavutettu, jotta tuote olisi toimituskunnossa jos on pakko Näin palaute alkaa aikaisessa vaiheessa laadukkaasti Näin rahat eivät lopu kesken Näin kukaan ei pääse olemaan liian optimisti Usein ei onnistu … hanketta seurattava tarkemmin
  • Vaikeinta on päättää keiden tarpeet ovat tärkeitä tässä vaiheessa Asiakkaan tuotepäällikön työ on todella vaikeaa Budjetti ei todellisuudessa riitä kaikkien osastojen tyydyttämiseen Jaetaan tuskaa Tulee kaikille huono sovellus Tärkeää olisi kyetä rajaamaan kokonaisia osastoja pois 1.0-versiosta. “ Raportit 1.1 versioon ”
  • MVP + Ketterä = 😄 MVP = minimum viable product. Suomeksi käännettävissä muotoon “ yksinkertaisin elinkelpoinen tuote ” Ketterät menetelmät toimivat loistavasti silloin kun kaikki pyrkivät välttämään turhia toiminnalisuuksia Ja tuottavat iisakinkirkkoja jos hankkeeseen saa kaataa uusia vaatimuksia loppuun saakka Mitä enemmän integrointeja sitä vähemmän MVP
  • Ei ketterää hanketta, ellei oikeuksia Ketterässä mallissa asiakas voi aina lopettaa hankkeen Jos hankkeen lopussa koodi ei jää asiakkaalle on uhka keinotekoinen En ikinä tekisi ketterää hanketta jossa koodi jää vain toimittajalle Vaikka todellisuudessa koodin siirtäminen on useimmiten kuollut kirjain
  • Asiakkaan oppimiskokemus Ensimmäisissä ketterissä hankkeissa asiakkaalle tulee usein yllätyksenä Kuinka paljon kysyttävää tiimillä on Kuinka monessa kohdassa vaatimuksia on vaikea löytää Kuinka nopea vastaaminen säästää rahaa ja hikeä Kaikille kokeneille kehittäjille suora yhteys asiakkaaeseen Toiseen hankkeeseensa asiakkaan tuotevastaava usein varaa enemmän aikaa!
  • Työmääräarviot Ketterät mallit toimivat helposti, jos kerralla tehdään vain 3-4 kk kehittämistä Työmääräennuste on nopanheittoja, jos: Käyttöliittymää voidaan vielä muuttaa Jos skaalautuvuuskriteerit ovat ilmassa Tietoturvavaatimuksia ei ole asetettu Jos tietorakenteisiin voidaan vielä kajota
  • Kuka saa antaa palautetta Laaja-alainen palaute devaajille tilaajalta tuotaa kalliimman sovelluksen Hyvin valittuna, laatu voi olla parempaa Huonosti … tulee kameli Kustannukset rajoittuvat kun palaute suoraan tuotepäälliköltä “ Kysyn Annalta ” tai “ Makella ja Penalla voi olla tähän sanottavaa ” -> ei enää yksi palautteenantaja Marilyn Monroe –malli Tuoteomistaja maailman napa
  • Miten ketterän hankinnan ongelmat vältetään, Petri Aukia

    1. 1. Ketterä hankintakäytännössäPetri Aukia28.5.2013
    2. 2. Hyviä neuvoja vaikea noudattaa
    3. 3. Ideaalimaailmassa
    4. 4. Vanhoista tavoista on vaikea luopua
    5. 5. Pahimmat pulmat
    6. 6. Suurimmat riemut
    7. 7. Pahimmat pulmat
    8. 8. Luottamus tärkeintä
    9. 9. Luottamusvaihe alkuun
    10. 10. Kirjalliset vaatimukset?
    11. 11. Asiakkaan panos
    12. 12. Samassa huoneessa
    13. 13. Kalaporrasmalli
    14. 14. Laadusta neuvottelu
    15. 15. Käyttöliittymän laatu
    16. 16. Osaanko ostaa?
    17. 17. Nyrkkisääntö: 1/2
    18. 18. Kenen tarpeet?
    19. 19. Yksinkertainen on kaunista
    20. 20. Entä jos ei onnistu?
    21. 21. Asiakkaan oppimiskokemus
    22. 22. Työmäärän arviointi
    23. 23. Kenen sana on lopullinen?
    24. 24. • Luottamus-sprint 0• Vaatimusmäärittely backlogiin• Riittävä asiakkaan panos• Pakolliset vaatimukset eivät vie koko budjettia• Laatuvaatimukset kirjallisesti sovittuna• Oikeudet asiakkaalle• Yksinkertainen 1.0 tuottaa paremman lopputuloksenYhteenvetona
    25. 25. Kuvat: flickr.com / CC• Johnson_cameraface• Legoloverman• Jamie in Bytown• 4nitsirk• Frank3.0• Goarmyphotos• Leshaines123• Sean_alexander• Frederic Poirot• Wildcat Dunny• Moonify UI• Debaird• Dunechaser• Nickwheeleroz• Ucumari• Chris hunkeler• YakobusanPetri AukiaTwitter: @aukiaBlog: http://petri.aukia.comTel: +358 400 438610petri.aukia@codento.comPetri AukiaTwitter: @aukiaBlog: http://petri.aukia.comTel: +358 400 438610petri.aukia@codento.com

    ×