Successfully reported this slideshow.

Talent Base ja Nitor Creations: Pragmatic Agile

1,548 views

Published on

Pragmatic Agile:
Mikä se on?
Miten se toimii käytännössä?
Mitä asiakas siitä hyötyy?

  • Be the first to comment

Talent Base ja Nitor Creations: Pragmatic Agile

  1. 1. Pragmatic AgileTommi Laitila ja Mikko Mustakallio 
05.12.2012"
  2. 2. Pragmatic Agile"•  Mikä se on?"•  Miten se toimii käytännössä?"•  Mitä asiakas siitä hyötyy?"
  3. 3. Mikä se on?"
  4. 4. Miksi ketterä kehitys? "•  Perinteinen vesiputousmalli ja sen variantit eivät enää kyenneet vastaamaan vaatimuksiin" –  Järjestelmien koko ja monimutkaisuus teki etukäteen konseptoinnin (Big Design Up Front) haastavaksi" –  Isoissa hankkeissa ennustettavuus perinteisillä malleilla oli epätarkkaa" –  Aikatauluvaatimukset (Time-to-market) pakotti aikaistamaan toteutusta hankkeissa" –  Työntekoa piti tehostaa, johon ratkaisun toi itseohjautuvat tiimit ja jatkuva priorisointi"
  5. 5. Miksi Pragmatic Agile?"•  Työkalupakki liiketoimintajärjestelmien ketterään kehittämiseen"
  6. 6. Mitä Pragmatic Agile tuo lisää ketteräänkehitykseen "•  Hyvä takaisinmaksuaika (ROI) "•  Ilman elinkaarikustannusten (TCO) nousua"
  7. 7. Laadukas syöte kehityssykliin"•  Kehityssykli on kone, joka tuottaa ICT-järjestelmän" –  Ulos tulevan lopputuotteen laatu korreloi syötteen laadun kanssa"
  8. 8. Tuote-backlog pitää valmistella ennenkuin sprint commitment voi tapahtua"
  9. 9. Tarkoituksenmukaisen arkkitehtuurinvarmistaminen (lean)"
  10. 10. Toteutuksesta pienkehitykseen ja ylläpitoon"
  11. 11. Miten se toimiikäytännössä?"
  12. 12. CASE" Responsiivinenkuluttajaverkkopalvelu"
  13. 13. Asiakkaalle aivan uudenlainen sopimus"•  Lähdettiin rakentamaan uudenlaista luottamussuhdetta välille tilaaja-toimittaja"•  Puitesopimus pienen, ketterän toimijan kanssa, joka tarjoaa osaamisen liiketoimintakonseptista toteutukseen"•  Ainoastaan laadullisia mittareita sopimuksessa"•  Asiakkaan ja toimittajan tekijät nivoutuvat yhdeksi tiimiksi"•  Kvartaaleittain hankintatilaus, jonka pohjana tiimien tarvitsema optimaalinen roolitus tekemisen luonteeseen nähden"
  14. 14. Mitä luvattiin?"•  Oikea ketterän kehityksen malli, jota liiketoiminta voi ohjata omien prioriteettiensa mukaan"•  Itseohjautuvat Hero-tiimit"•  Aivan uudenlaista näkyvyyttä ja ennustettavuutta hankkeen etenemiseen"•  Automatisoida kaikki, mikä on järkevästi automatisoitavissa"•  Laatu aivan uudelle tasolle"•  Kova asenne ja vahva vastuuntunto paikalle"•  Elinkaarikustannusten hallittavuus"
  15. 15. Pragmaattinen malli" Business   Needs  &     Requirements   Produc;on   Solu%on   Architecture   design   IT   Resources   Infrastructure   Releases   Technology   Quality  &   Scrum   deployment   Enterprise   Architecture   Architecture  
  16. 16. KAPO = Konseptointi, Arkkitehtuuri, Prototyypitys, Operatiivinen malli"BUSINESS" Design" UI" Proto" Concept" Web dev" CMS dev" Testing" Architecture" Operational Process" Content"BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"
  17. 17. Hero Team –periaatteet"I.  Arkkitehtuuri ja ratkaisukonseptointi yhdessä: 
 Vahva arkkitehtuuri- ja ratkaisukonseptointiosaaminen tiimissä keskenään samassa tilassa. Liiketoimintatarpeet selkeytetään ja prosessoidaan tekniseksi ratkaisuksi ja tuotetaan Product backlog -itemit toteutustiimille. Operatiivinen optimointi suoritetaan osana ratkaisukonseptia."II.  Prototyyppi: HTML5-ulkoasu, CSS-tyylitiedostot, Javascript, grafiikat"III.  Toteutettu ominaisuus: Hero Team tuottaa ratkaisukonsepteista suoraan tuotantokelpoisia ominaisuuksia (Java-toteutus + CMS-integraatio) " –  Yhteinen vastuu, yhteiset työkalut"  Saumaton sykli: " –  Ratkaisukonseptoinnista prototyypin kautta operatiivisesti optimoituun tuotantovalmiiseen järjestelmään" Saumaton toiminnallinen laatu:" –  Konseptisuunnittelija vastaa lopputuotteen toiminnallisesta laadusta yhdessä kehittäjän kanssa (sign-off ennen hyväksyntätestausta)" –  Hero Team vastaa testiautomaatiosta ja koodikatselmoinneista"
  18. 18. Vähemmän tekijöitä mutta laajemmissarooleissa"•  Pieni, tehokas tiimi tarkoittaa, ettei tarvita dedikoituja henkilöitä kapeisiin “laput silmillä” -rooleihin"•  Laajemmat roolit tukevat kokonaisuuden ymmärtämistä ja vähentävät vastuurajojen epäselvyyttä"•  Vähemmän rajapintoja ihmisten/roolien välillä varmistaa saumattoman kommunikaation"
  19. 19. Miten lupaus pidettiin?" •  Asiakas vahvasti integroitu prosessiin" •  Konseptointi, arkkitehtuurin ohjaus ja protoilu esisprintissä, joka syötteenä toteutussprinttiin" •  Itseohjautuvat moniosaajatiimit (Hero Team)" •  Testilähtöinen kehitys konseptista ylempiin ympäristöihin" •  Automatisointi kehitykseen, asennuksiin ja testaukseen"BUSINESS" CAPO" DEVELOPMENT" CONTENT" TESTING & UAT"
  20. 20. Mitkä ovat asiakkaan hyödyt?"
  21. 21. Projektin tila nyt"I.  Pienemmällä porukalla tehdään isompia asioita nopeammin ja laadukkaammin"II.  Lopputuotos on täysin testaantuvaa ja design-velka minimoitu (vrt. perinteinen käsitys agile-malleista)"III.  Velocity on tasaantunut ja ennustettavuus parantunut"IV.  Liiketoiminnan ketterä ohjaus toimii: 
 liiketoimintavaatimus sisään, toimiva ominaisuus ulos "
  22. 22. Hard Facts* 1/4 – tiimin koko, 
 lähtötilanne vs. Nitor-TB haltuunotto" •  Vaikka projektin pääluku 70" (ml. konseptoijat, arkkitehdit, kehittäjät) on 60" laskenut 1/3-osaan, 50" ominaisuuksia 40" toteutetaan jopa Projektin pääluku yhteensä" Backlog-itemeita enemmän" 30" toteutettu" 20" 10" 0" Ennen" Nitor-TB"*Vertailun pohjana olevat luvut katsottu yhdessä asiakkaan kanssa kahdesta verrokkisprintistä. Ominaisuus tai backlog itempysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaan pikemminkin suuntaa-antava yksikkö.
  23. 23. Hard Facts 2/4 - kehittäjän panos per sprintti"•  Aika, jonka kehittäjät 8,0" nyt pystyvät 7,5" dedikoimaan itse 7,0" kehitystyöhön, on 6,5" kasvanut 15%" 6,0" Kehittäjän kontribuutio sprinttiin (htp)" 5,5" 5,0" 4,5" 4,0" Ennen" Nitor-TB"
  24. 24. Hard Facts 3/4 - kehittäjän käyttämä aika vs. toteutettu ominaisuus" •  Hero-tiimin osana toimivilta kehittäjiltä 8,0" menee nyt n. 60% 7,0" vähemmän aikaa 6,0" yhden liiketoiminnan 5,0" tarvetta vastaavan 4,0" HTP:tä / Backlog Item" ominaisuuden* 3,0" toteuttamiseen" 2,0" 1,0" 0,0" Ennen" Nitor-TB"*Ominaisuus tai backlog item pysynyt kutakuinkin saman kokoisena suureena muttei absoluuttinen luonnonvakio vaanpikemminkin suuntaa-antava yksikkö.
  25. 25. Hard Facts 4/4 - Tekniset parannukset(esimerkkejä)" 40" 35"•  Käännös ja automaattinen 30" testaus 1/10-osaan " 25" 20" Minuuttia" 15" 10" 5" 0"•  Järjestelmän rakennus ja Ennen" Nitor-TB" asennus (kehitysympäristö) 180" 1/20-osaan" 160" 140" •  Mahdollistettiin “build on commit”" 120" 100"•  Muut ympäristöt olivat 80" Minuuttia" manuaalisia ja nyt 60" 40" automatisoitu" 20" 0" Ennen" Nitor-TB"
  26. 26. Tekniset parannukset (näkyvyys)"•  Mitä mitataan näkyy kaikille"
  27. 27. Yhteenveto"•  Kehityssyklin lopputuote on syötteestä riippuvainen, saumaton yhteistyö varmistaa tehokkuuden ja laadun "•  Selkeät vastuut (DoD) ja saumattomat hand-overit varmistavat, että kehittäjät tekevät oikeita asioita eikä heidän työnsä keskeydy kesken sprintin "•  Asiakkaiden ei enää tarvitse ostaa isoja projekteja ja useita erilaisia mutta kapeita rooleja, vaan keskittyä moniosaajiin, jotka tehokkaasti tuottavat liiketoimintavaatimuksista toimivan järjestelmän"
  28. 28. Asiakkaamme kertovat" ”Oikeasti, hyvät tyypit ja rutkasti asiantuntemusta” “They stand out with their brilliant down-to- “They have good working moral earth, humble and always helpful attitude” and always look for the best “Talent Base and NitorCreations’ people interest of the customer.” stand out especially with subject matter expertise and mastering of their“I personally would prefer a small responsibility areas”service provider like NitorCreations to “Easy to approach with anya large service vendor with questions at any time, no mattercomplicated hierarchy and processes” what the issue” “If something isn’t clear to myself or others in the business, your guys patiently take the time to explain or bring in others who can help”
  29. 29. ☐ Clearly defined product owner (PO) ☐ PO is dedicated to the project and easily available to the team ☐ PO is empowered and has knowledge to prioritize ☐ PO has direct contact with team Pragmatic Agile check list v1.1 ☐ PO has direct contact with stakeholders☐ PO maintains a product backlog (PBL) ☐ Daily scrum (max 15 minutes) takes places daily at the same time ☐ PBL is prioritized by business value ☐ Whole team participates ☐ PBL is visible to the team ☐ Impediments surface and are dealt with☐ Top PBL items are well understood and ready for development ☐ Clearly defined scrum master (SCM) who is not PO ☐ Grooming takes place before sprint planning ☐ Team knows top impediments ☐ Bizcases have been approved ☐ SCM works actively to solve impediments ☐ Architectural implications to other systems have been agreed ☐ Escalated to mgmt. when team cannot solve ☐ UI mockups have been created an verified ☐ Items have been estimated by the team ☐ All code is automatically tested ☐ Items are small enough to fit in a sprint ☐ Continuous integration is used ☐ Unit tests are written and test coverage is followed ☐ Team understands architecture and goals of surrounding systems ☐ Acceptance tests are automated and created based on user stories ☐ Team receives architectural guidance when needed ☐ Team can bring up architectural issues and proposals ☐ Demos are held after each sprint before the next one starts ☐ Issues and proposals are managed transparently ☐ PO and the required stakeholders participate ☐ Useful feedback is received☐ Team has sprint planning meetings ☐ PO brings an up-to-date PBL with well-understood items ☐ Retrospective takes place after each sprint ☐ Whole team and PO participates ☐ The entire team including the PO participates ☐ Meeting is not longer than 4 hours ☐ Results in improvement proposals and some get implemented ☐ Team decides what fits into the sprint ☐ Team has a visible sprint backlog and a burndown chart ☐ Sprints of max 4 weeks ☐ Thee sprints always end on time☐ Team has a release burndown chart ☐ Team usually finished most items ☐ Teams estimate in story points rather than hours ☐ Team is not disrupted by other tasks ☐ Team velocity is measured and used for release planning ☐ Team possesses all skills required for completing itemsTHIS IS WHAT COUNTS: POSITIVE INDICATORS:☐ Team delivers working, tested software after each iteration ☐ Team is having fun and is being trusted by stakeholders☐ Team delivers what the business needs most ☐ Work generally takes place within the limits of normal working hours☐ Team is continuously improving its practices ☐ The atmosphere is open for discussing, experimenting and criticizing

×