Your SlideShare is downloading. ×
CIOForum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

CIOForum

256

Published on

Agile in non agile environment

Agile in non agile environment

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • 18 millioner kall 1.desember i år.
    8000 klasser hvor på ca 5000 er involvert direkte i foretningen.
    Ca 8000 unittester.
    40 klienter og 50 backendsystemer.
  • En god scrummaster vil sørge for dette, men det kan være behov for eksterne. (prosesseiere)
  • En god scrummaster vil sørge for dette, men det kan være behov for eksterne. (prosesseiere)
  • Planningpoker er laget for å heve kompetansen på alle ..
  • Planningpoker er laget for å heve kompetansen på alle ..
  • Rører du scopet under sprinten forsvinner comittment umiddelbart. Bedre å avbryte sprinten eller eventuelt bytte ut oppgaver med
  • Rører du scopet under sprinten forsvinner comittment umiddelbart. Bedre å avbryte sprinten eller eventuelt bytte ut oppgaver med
  • Selvom mange av de som arbeidet på systemet var kosulenter hadde
  • Selvom mange av de som arbeidet på systemet var kosulenter hadde
  • Dette er noe av nøkkelen med agile: Selvjusterende metode.
  • Dette er noe av nøkkelen med agile: Selvjusterende metode.
  • Send de riktige folkene
    IKKE scrummaster.
    Funker sånn passe



    Kanbanmøter
    Big room planlegging.
  • Send de riktige folkene
    IKKE scrummaster.
    Funker sånn passe



    Kanbanmøter
    Big room planlegging.
  • Oppgaver er ferskvare.
    Ikke estimater, ikke retrospectives.
  • Transcript

    • 1. Erfaringer fra innføring av smidige metoder i store prosjekter Tobias K Torrissen CTO, Know It
    • 2. Tobias K Torrissen 6 års erfaring fra smidig utvikling Store prosjekter i telekom og transport Scrummaster, arkitekt og utvikler
    • 3. Stort mellomvaresystem som server et førtitalls klienter
    • 4. Stort mellomvaresystem som server et førtitalls klienter Del av lang verdikjede
    • 5. Stort mellomvaresystem som server et førtitalls klienter Del av lang verdikjede 4 releaser i året
    • 6. Stort mellomvaresystem som server et førtitalls klienter Del av lang verdikjede 4 releaser i året Vedlikeholdsteam
    • 7. Stort mellomvaresystem som server et førtitalls klienter Del av lang verdikjede 4 releaser i året Vedlikeholdsteam Flere prosjektteam
    • 8. Stort mellomvaresystem som server et førtitalls klienter Del av lang verdikjede 4 releaser i året Vedlikeholdsteam Flere prosjektteam
    • 9. Kortere time 2 market Endringsdyktighet Høyere kvalitet Lavere pris
    • 10. 2003 - Testdrevet
    • 11. 2003 - Testdrevet 2004 - Scrum
    • 12. 2003 - Testdrevet 2004 - Scrum 2005 - Flere Scrum team
    • 13. 2003 - Testdrevet 2004 - Scrum 2005 - Flere Scrum team 2007 - Strengere krav til team
    • 14. 2003 - Testdrevet 2004 - Scrum 2005 - Flere Scrum team 2007 - Strengere krav til team 2009 - Kanban i forvaltning
    • 15. Prosjektgjennomføring
    • 16. Prosjektgjennomføring 1 Forslag
    • 17. Prosjektgjennomføring 1 2 Forslag Analyse
    • 18. Prosjektgjennomføring 1 2 3 Forslag Analyse Impl og test
    • 19. Prosjektgjennomføring 1 2 3 4 Forslag Analyse Impl og test Prodsetting
    • 20. Prosjektgjennomføring 1 2 3 4 5 Forslag Analyse Impl og test Prodsetting Gevinst
    • 21. Prosjektgjennomføring Agile praksis 1 2 3 4 5 Forslag Analyse Impl og test Prodsetting Gevinst
    • 22. Erfaringer fra innføring av smidige praksiser
    • 23. Eierskap til prosessen Ildsjeler startet innføringen og passet på prosessen. Folk slutter - til tider hadde vi ingen som tok spesielt ansvar
    • 24. Eierskap til prosessen Prosessen bør være forankret. Noen bør sørge for at den følges. Ildsjeler startet innføringen og passet på prosessen. Folk slutter - til tider hadde vi ingen som tok spesielt ansvar
    • 25. Product owner Styringsgruppa er formelt eier. Prosjektleder / arkitekter fungerer til tider som eier.
    • 26. Product owner raskt. Uheldig med Viktig å kunne ta avklaringer “skybert” product owner. Styringsgruppa er formelt Ta avgjørelser på forskudd hvis du er trygg på eier. utfallet. Prosjektleder / arkitekter fungerer til tider som eier.
    • 27. Teamsammensetning Tverrfaglige team. Flere team med forskjellig fokus (mellomvare og kanal)
    • 28. Tverrfaglige team leverte veldig bra mtp Teamsammensetning funksjonalitet. Ulempen var at de forskjellige systemene som avga ressurser mistet kontroll Tverrfaglige team. og styring. Flere team med forskjellig Ekstrem fokus på leveranse fører til dårligere fokus (mellomvare og kanal) kodekvalitet. Motvirkende tiltak bør vurderes.
    • 29. Estimering Tradisjonell estmering Planningpoker Uforbredt Enkelte forbreder presentasjon av oppgaven.
    • 30. Estimering Planningpoker fungerte bra for oss. Hele teamet er commitet til estimatet og deler kunnskap om hva som skal gjøres. Tradisjonell estmering Planningpoker Uforbredt Enkelte forbreder presentasjon av oppgaven.
    • 31. Scope Til å begynne med rørte vi ikke scopet i sprinten -> Endring == avbrudd. Etter hvert begynte vi å jonglere med sprinten.
    • 32. Commitmentet til utviklerne kan forsvinne Scope dersom sprinten endres hyppig. Kjør kortere sprinter hvis dere ikke klarer å holde Til å begynne med rørte vi sprinten stabil. ikke scopet i sprinten -> Endring == avbrudd. Etter hvert begynte vi å jonglere med sprinten.
    • 33. Parprogramering ad-hoc Tvungen parprogramering Rullering Velge selv Ved behov og som substitutt for QA funket best
    • 34. Parprogramering Parprogramering fungerte best når det var komplekse problemstillinger, man hadde behov ad-hoc for opplæring eller som substitutt for QA. Tvungen parprogramering Rullering Velge selv Ved behov og som substitutt for QA funket best
    • 35. Kalender tid og tilgjengelig tid. Alle oppgaver inn i sprinten Estimere med lavere burn-rate.
    • 36. Kalender tid og tilgjengelig Sett av tid til arbeidsoppgaver som må gjøres tid.siden av. Estimer f.eks med at folk klarer å ved jobbe 6 timer pr dag med prosjekt. Alle oppgaver inn i sprinten Estimere med lavere burn-rate.
    • 37. Sprint demo Mellomvaresystem Ikke noe gui Funksjonelle tester Klienter med grensesnitt Demo av funksjonalitet
    • 38. Sprint mellomvaresystem fungerte dårlig. Demo av demo Demo av klienter fungerte ok, men diskusjonen dreide seg fort om utseende og ikke funksjon. Mellomvaresystem Behovnoe gui Ikke for styring av disse møtene. Funksjonelle tester Klienter med grensesnitt Demo av funksjonalitet
    • 39. Retrospectives Kjørte retrospectives etter hver sprint Sjeldnere etterhvert Til slutt kjørte vi ikke retrospectives
    • 40. Retrospectives som arena er viktig. Retrospectives Kjør dem hver gang. Hvis det ikke er noe å ta opp kan man bare avslutte. Kjørte retrospectives etter hver sprint Sjeldnere etterhvert Til slutt kjørte vi ikke retrospectives
    • 41. Sprint frekvens Sprinter rett etter hverandre Pauser mellom sprinter. Stabiliseringsprinter.
    • 42. Sprint frekvens Det er intenst å jobbe smidig. Det kan rett etter hverandre Sprinter være lurt å ha noen hvileskjær mellom sprintene. Pauser mellom sprinter. Stabiliseringsprinter.
    • 43. Oppskalering Scrum of scrums En fra hvert team møtes med jevne mellomrom. Look ahead kort planlegging av sprintene fremover.
    • 44. Scrum of scrums fungerte ikke så bra for oss. Oppskalering Look a head for å kompansere for sjeldne Scrum of scrums releaser fungerte bra. En fra hvert team møtes med jevne mellomrom. Andre tips: Samle alle i et stort rom for å planlegge kan også virke. Look ahead kort planlegging av sprintene fremover.
    • 45. Kanban Brukes av vedlikeholdsteam. Minimere tiden en oppgave er i systemet Lite work in progress
    • 46. 2 2 Backlog In progress QA Done
    • 47. 2 2 Backlog In progress QA Done
    • 48. 2 2 Backlog In progress QA Done
    • 49. Oppsummering. Smidige metoder gir: Målbart bedre produktivitet (for oss) Bedre forretningsforståelse hos utviklere. IT er et middel, ikke målet. Økt leveranseevne Større risiko for teknisk gjeld. Økt synlighet og bedre kommunikasjon.
    • 50. Oppsummering. Smidige metoder krever: Et dedikert team. At smidige praksiser faktisk benyttes
    • 51. Viktig å ikke glemme det vi tar for gitt... Kontinuerlig integrasjon Testdrevet utvikling Kodegjennomgang eller parprogramering

    ×