Your SlideShare is downloading. ×
0
Effektive
  samarbeidspraksiser for
     kravhåndtering

Hans Gallis                Kjetil Moløkken-Østvold
Symphonical   ...
Viktige momenter ved denne
sesjonen
 BOF = Diskusjonsbasert sesjon.
 Stor variasjon i bakgrunn og roller hos deltakere.
 A...
Er kravhåndtering viktig?
 Kravprosesser (og brukertesting) krever:
    Struktur og langsiktighet.
    Godt samarbeid mell...
V-modellen
 Brukerkrav                                           Produksjonssetting
                                      ...
Oppgave: Forretningsmål
 Bakgrunn: Uavhengig om du er på
 leverandørsiden, kundesiden eller i en annen
 rolle.

 Spørsmål:...
Dagens budskap

              Effektive
             Prosjekter

          Bedre estimering,
          kravhåndtering og
 ...
Kommunikasjon
    Studier har vist at opptil 70% av total tid i IT-prosjekter
    benyttes til kommunikasjon¹.
    Hyppig ...
Kommunikasjonsfrekvens
           Boxplot of BREBias by Contact frequency
    2,0

                                       ...
Eksempel 1: Sprint


                                 Sprint 1: 3 uker
  Krav
           Estimering                       ...
Eksempel 2: Release
             Release 1

                              Release 2

                                     ...
Effektive praksiser for
kravhåndtering og
forretningsprioritering
Frustrerende samarbeid!
Presisjon



                                                 Abstraksjonsnivå


                                         ...
Presisjon



                                                 Abstraksjonsnivå


                                         ...
Forretningsmål
 Avhengig av (eksempelvis):
   Type prosjekt.
   Kunde.
   Prioriteter.
 Eksempler:
   ”Portere eksisterend...
Behov
 Hva er behovene man søker å løse?
 Tenk behov (arbeidsprosess) fremfor ”features”
   Features SKAL kunne linkes til...
Innovasjon
 I nivå 1 og 2 bør det være rom for innovative konsepter.
 Dette må leverandøren utfordre kunden på.
 Utfordren...
Presisjon



                                                 Abstraksjonsnivå


                                         ...
Kravhåndteringsprosess
 Gjelder for ideer (krav) som har blitt prioritert inn i et
 prosjekt eller delprosjekt.
    Denne ...
Kravhåndteringsprosess forts.
 En brukerhistorie kan suppleres med mer detaljerte parametere:
    Andre aktører (tilgangss...
Presisjon



                                                 Abstraksjonsnivå


                                         ...
Oppgavehåndteringsprosess
 Løsningsansvarlig og utviklere deler opp ”user
 stories” (krav) i håndterbare oppgaver.
 IKKE b...
Oppgavehåndteringsprosess forts.
 Identifiser mulige løsninger.
   Alle krav har minst to løsninger?
 Utvikleren identifis...
Diskusjon
 Hvilken størrelse er ”passe” for oppgaver?
   En uke, tre dager, en dag, fire timer?
Effektive praksiser for å
samarbeide om estimering og
planlegging
Estimering bør være en integrert
del av kravprosessen
 Estimering og prioritering av krav gir nye
 innfallsvinkler og konk...
Metoder for kombinasjon av
estimater                    Struktur
                             Struktur
                   ...
Presisjon



                                                 Abstraksjonsnivå


                                         ...
Eksempel fra in-house utvikling
     Kundesiden prioriterer viktighet og rekkefølge på krav.
1.

     Utviklingsteamet dis...
Noen fordeler ved kombinasjon av
estimater
 Kombinerer kunnskap fra flere kilder.
 Ekstreme utslag kan bli moderert.
 Synk...
Mulige ulemper ved
gruppeestimering
 Kan være utfordring med passive deltakere.
 Avhengig av valgt metode: politisk press
...
Planlegging av iterasjoner
 Timeboxing: Lærer hva tidsintervallet betyr for deg.
    Eksempel: faste to ukers iterasjoner....
Avslutning
Studie om prosjektprosesser
    Et studie fant signifikante forskjeller i gjennomsnittlige
    overskridelser av estimert ...
Mulige årsaker?
 Økt interaksjon med kunden øker muligheten for
 å oppdage feil eller mangler på et tidlig
 tidspunkt.
   ...
Debatt om prosesser
 Er smidige prosesser svaret?
 Hva må man ha av kunnskap om
 prosesselementer?
 Hvordan kan man velge ...
Effektiv kravhåndtering!
 Tenk korte iterasjoner og hyppige leveranser.
    Enklere å håndtere.
    Enklere å lære.
 Bli e...
Spørsmål?
 hans@symphonical.com


 www.symphonical.com
 www.conceptos.no
Upcoming SlideShare
Loading in...5
×

Effektive samarbeidspraksiser for kravhåndtering

762

Published on

Presentasjon fra JavaZone 2008, sammen med Hans Gallis.

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
762
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
6
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Transcript of "Effektive samarbeidspraksiser for kravhåndtering"

  1. 1. Effektive samarbeidspraksiser for kravhåndtering Hans Gallis Kjetil Moløkken-Østvold Symphonical Conceptos Consulting JavaZone, 18. september 2008
  2. 2. Viktige momenter ved denne sesjonen BOF = Diskusjonsbasert sesjon. Stor variasjon i bakgrunn og roller hos deltakere. Avbryt, spør og diskuter underveis.
  3. 3. Er kravhåndtering viktig? Kravprosesser (og brukertesting) krever: Struktur og langsiktighet. Godt samarbeid mellom kunde og leverandør. Mange sliter med å få kravprosesser og brukertesting smidig! Kravprosessen forut for en iterasjon er ofte undervurdert. Skal man gjennomføre en stor up-front kravprosess eller skal man gjøre den til del av hver enkelt iterasjon? Symphonical har fått et eget IFU-prosjekt gjennom Innovasjon Norge på dette temaet.
  4. 4. V-modellen Brukerkrav Produksjonssetting til brukere Funksjonell Akseptansetesting spesifikasjon Design- Systemtest spesifikasjon Modul- Modultesting spesifikasjon (utviklere) Systembygg
  5. 5. Oppgave: Forretningsmål Bakgrunn: Uavhengig om du er på leverandørsiden, kundesiden eller i en annen rolle. Spørsmål: Kan du beskrive hva som var forretningsmål(ene) i ditt siste prosjekt?
  6. 6. Dagens budskap Effektive Prosjekter Bedre estimering, kravhåndtering og prosjektgjennomføring Gode samarbeidspraksiser
  7. 7. Kommunikasjon Studier har vist at opptil 70% av total tid i IT-prosjekter benyttes til kommunikasjon¹. Hyppig kommunikasjon kan benyttes til å prioritere krav, fokusere på feilretting, inkludere nye krav eller avklare løsningsmuligheter. Delvis motivert av Cockburn², ønsket vi å undersøke effekten av kommunikasjonsfrekvens mellom kunde og leverandør. ¹ Teasley, S.D., Covi, L.A., Krishnan, M.S. and Olson, J.S. (2002). Rapid Software Development through Team Collocation. IEEE Transactions on Software Engineering, 28 (7), 671-683. ² Cockburn, quot;The End of Software Engineering and the Start of Economic-Cooperative Gaming,quot; ComSIS, 2004.
  8. 8. Kommunikasjonsfrekvens Boxplot of BREBias by Contact frequency 2,0 Overskridelser 1,5 Daglig: 9% BREBias 1,0 Ikke daglig: 58% 0,5 0,0 Daily Not daily Contact frequency
  9. 9. Eksempel 1: Sprint Sprint 1: 3 uker Krav Estimering Akseptanse Analyse Utvikling Testing Bug fix Release Planlegging test Design
  10. 10. Eksempel 2: Release Release 1 Release 2 Release 3 Release 2: 8 uker Test Kravhåndtering Kick-Off Utvikling Utvikling Bugfix Sprint 0 Sprint 1 Sprint 2 Sprint 3 Release Release 3 Kravhåndtering Kick-Off Utvikling Sprint 0 Sprint 1 Sprint 2 …….
  11. 11. Effektive praksiser for kravhåndtering og forretningsprioritering
  12. 12. Frustrerende samarbeid!
  13. 13. Presisjon Abstraksjonsnivå Kommunikasjonskostnader Karakteristikker Øker i pilens retning Nivåer Kravpyramiden © Prosjektledere Utviklere og testere Interaksjonsdesignere Aktører Kunder Sluttbrukere
  14. 14. Presisjon Abstraksjonsnivå Kommunikasjonskostnader Karakteristikker Øker i pilens retning Nivåer Prosjektledere Utviklere og testere Interaksjonsdesignere Aktører Kunder Kravpyramiden © - Nivå 1 og 2 Sluttbrukere
  15. 15. Forretningsmål Avhengig av (eksempelvis): Type prosjekt. Kunde. Prioriteter. Eksempler: ”Portere eksisterende løsning til ny teknologi”. ”Effektivisere saksbehandlingstid med 10%”. ”De 10 viktigste funksjonene skal fungere minimum 20% raskere”. Hvordan bør de settes opp?
  16. 16. Behov Hva er behovene man søker å løse? Tenk behov (arbeidsprosess) fremfor ”features” Features SKAL kunne linkes til et definert behov. Skille mellom typer av behov: Kunde/bestillerbehov. Sluttbrukerbehov. Leverandørforslag. Trender, arkitektur, vedlikeholdbarhet etc. som spiller inn. Foreslå behov for kunden.
  17. 17. Innovasjon I nivå 1 og 2 bør det være rom for innovative konsepter. Dette må leverandøren utfordre kunden på. Utfordrende spørsmål: Hvordan gjøres dette i dag (uten denne funksjonaliteten)? Hvem trenger denne funksjonaliteten? Hvor ofte benyttes denne funksjonaliteten? Finnes det eksisterende løsninger som løser dette på en god måte? Finnes det andre, og kanskje mer innovative, løsninger?
  18. 18. Presisjon Abstraksjonsnivå Kommunikasjonskostnader Karakteristikker Øker i pilens retning Nivåer Prosjektledere Utviklere og testere Interaksjonsdesignere Aktører Kunder Kravpyramiden © - Nivå 2 og 3 Sluttbrukere
  19. 19. Kravhåndteringsprosess Gjelder for ideer (krav) som har blitt prioritert inn i et prosjekt eller delprosjekt. Denne delen involverer også iterasjonsplanlegging (”Product Backlog”). Skille tydeligere mellom ønske og krav (ønske gjelder nivå 1-2 i modellen ovenfor). Utdype spesifiseringen fra idéprosessen med nye og mer detaljerte parametere. Inkluderer å vurdere muligheten for å legge flere krav sammen i en ”modul” etc. Jo mer kundesiden bidrar med, desto bedre blir funksjonaliteten og desto færre feil blir det (pga misforståelser etc).
  20. 20. Kravhåndteringsprosess forts. En brukerhistorie kan suppleres med mer detaljerte parametere: Andre aktører (tilgangsstyring). Input (trigger). ”Happy day” scenario. Use frequency (relevant for prioritering og testing). GUI (dersom ikke tilgang til skisser, beskriv kort hvordan det skal løses GUI-messig eller lag noe enkelt i powerpoint etc). Test case(s) og akseptansekrav. Output (hvordan avsluttes denne funksjonen? Hva skjer i systemet når funksjonen har kjørt?). Spesielle avvik fra ”Happy day” scenario.
  21. 21. Presisjon Abstraksjonsnivå Kommunikasjonskostnader Karakteristikker Øker i pilens retning Nivåer Prosjektledere Utviklere og testere Interaksjonsdesignere Kravpyramiden © - Nivå 3 til 5 Aktører Kunder Sluttbrukere
  22. 22. Oppgavehåndteringsprosess Løsningsansvarlig og utviklere deler opp ”user stories” (krav) i håndterbare oppgaver. IKKE benytt høy/middels/lav prioritet. Benytt heller prinsippet om ”rekkefølge” (uten avhengigheter). For eksempel kan dere lage kategorier a’la first, second, third, fourth, fifth.
  23. 23. Oppgavehåndteringsprosess forts. Identifiser mulige løsninger. Alle krav har minst to løsninger? Utvikleren identifiserer uklarheter/ vanskeligheter. Dette gir innspill til estimeringen (som må gjøres av ansvarlig utvikler og minst en annen utvikler). Hvis vanskelig: vurder om denne skal løses i par, dvs. analysere, skrive tester og teste i par (kode individuelt).
  24. 24. Diskusjon Hvilken størrelse er ”passe” for oppgaver? En uke, tre dager, en dag, fire timer?
  25. 25. Effektive praksiser for å samarbeide om estimering og planlegging
  26. 26. Estimering bør være en integrert del av kravprosessen Estimering og prioritering av krav gir nye innfallsvinkler og konkretiserer utfordringer. Flere roller bør involveres i estimeringen, både fra leverandør og kundeside. Estimeringen bør skje på forskjellige nivåer (ref. pyramiden) og trianguleres.
  27. 27. Metoder for kombinasjon av estimater Struktur Struktur Lite informasjonsflyt Lite informasjonsflyt Skjerming Skjerming Tidskrevende Tidskrevende Decision markets Delphi Wideband-Delphi Planning Poker Semi-strukturerte grupper Ustrukturert Mye informasjonsflyt Statistiske grupper Mulighet for press Kostnadseffektivt
  28. 28. Presisjon Abstraksjonsnivå Kommunikasjonskostnader Karakteristikker Øker i pilens retning Nivåer Prosjektledere Utviklere og testere Interaksjonsdesignere Kravpyramiden © - estimering Aktører Kunder Sluttbrukere
  29. 29. Eksempel fra in-house utvikling Kundesiden prioriterer viktighet og rekkefølge på krav. 1. Utviklingsteamet distribuerer tilgjengelige timer for utvikling 2. på kravene. I kundens prioriterte rekkefølge. Mer fokus på det man vet man rekker å gjøre! Ikke bindende estimater Tidlig avgrensning. Felles Wideband Delphi på overordede krav man tror man 3. rekker. Skaffe mer sikkerhet i estimatene. Diskutere krav. Prioritere på nytt! Utviklingsteam gjør oppdeling med Planning poker på 4. brukerhistorier. Splittes senere i oppgaver.
  30. 30. Noen fordeler ved kombinasjon av estimater Kombinerer kunnskap fra flere kilder. Ekstreme utslag kan bli moderert. Synkronisert oppfatning av hva estimatene innebærer angående aktiviteter og antakelser. Mer eierskap til estimatene. Moderator kan sørge for at irrelevant informasjon ikke ødelegger for realismen. Moderator kan være “djevelens advokat”.
  31. 31. Mulige ulemper ved gruppeestimering Kan være utfordring med passive deltakere. Avhengig av valgt metode: politisk press (groupthink). Krever gode eksperter og moderatorer. Tids- og kostnadskrevende (?).
  32. 32. Planlegging av iterasjoner Timeboxing: Lærer hva tidsintervallet betyr for deg. Eksempel: faste to ukers iterasjoner. Eller: variere lengde for å ”bli ferdig”? Hvordan avsluttes en iterasjon? Legge det man ikke fikk ferdigstilt tilbake i Product Backlog? Overføre det man ikke rakk til neste iterasjon? Utfordring: Det er ikke tatt med i selve planleggingen! Man kjøper seg uansett en ”straff” når krav ikke blir ferdigstilt. Spørsmålet er hvordan denne ”straffen” skal behandles!
  33. 33. Avslutning
  34. 34. Studie om prosjektprosesser Et studie fant signifikante forskjeller i gjennomsnittlige overskridelser av estimert ressursbruk (arbeidstid) ¹. Prosjekter med sekvensielle prosesser: 55%. Prosjekter med fleksible (inkl. smidige) prosesser: 24%. Fleksible prosjekter fikk mer positiv omtale på: Gode krav. Bra samarbeid/kommunikasjon med kunde. Dette er ofte (de mest) kritiske utfordringer i prosjekter! ¹ Moløkken-Østvold and Jørgensen, quot;A Comparison of Software Project Overruns“, IEEE Transactions on Software Engineering, 2004.
  35. 35. Mulige årsaker? Økt interaksjon med kunden øker muligheten for å oppdage feil eller mangler på et tidlig tidspunkt. Kunden involveres gjennom hele prosjektet og ikke bare i en startfase. Utvikling av kjernefunksjonalitet først, deretter videre på prioriteringslisten. Prosjektene utvikles i mer håndterbare (mindre) enheter.
  36. 36. Debatt om prosesser Er smidige prosesser svaret? Hva må man ha av kunnskap om prosesselementer? Hvordan kan man velge de rette praksisene i sin prosess?
  37. 37. Effektiv kravhåndtering! Tenk korte iterasjoner og hyppige leveranser. Enklere å håndtere. Enklere å lære. Bli enige om en standard for beskrivelse av krav på ulike nivåer (ut i fra hvem som faktisk skal involveres). Tydelige roller. Hvem har overblikket? Hvem prioriterer og tar avgjørelser? Hvem kommuniserer med utviklingssiden? Hvem skriver brukerhistorier?
  38. 38. Spørsmål? hans@symphonical.com www.symphonical.com www.conceptos.no
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×