Scrum - fallgruver og erfaringer - Terje K Wahl
•Download as PPTX, PDF•
0 likes•602 views
Etter noen år som Scrum Master og deltaker i Scrum team gjør man seg en del erfaringer om hva som fungerer bra og hva som ofte gjør at Scrum fungerer mindre optimalt. Presentasjonen fokuserer på erfaringer - ikke bare hva som er utfordringene men også praktiske og konkrete erfaringer fra hvordan man forbedrer bruken av Scrum i teamet sitt.
Recommended
Recommended
More Related Content
Featured
Featured (20)
Scrum - fallgruver og erfaringer - Terje K Wahl
- 1. Scrum Fallgruver og erfaringer Terje K. Wahl 9.1.2012
- 2. Min erfaring med Scrum Diskuter gjerne
- 4. Morgenmøtet Si hva, ikke hvordan
- 6. Estimering II Detaljestimering er bortkastet
- 7. Estimering III Story points funker faktisk!
- 8. Scrum Master og Produkteier vs. Prosjektleder Fokuser på ansvarsfordelingen
- 9. Svakheten ved Scrum Forutsetter kun ansvarlige og dyktige folk
- 10. Retrospective Er sterkt undervurdert. Bruk den!
- 11. Product Backlog items Ikke mist fokus på kunden
- 12. Smidige metoder Vær smidig i bruken av dem
- 13. Takk for meg! Spørsmål? Terje K. Wahl terje@bzzzt.no
Editor's Notes
- - Like mange synspunkt som personer - Diskuter gjerne!
- - Morgenmøtet (brukes ofte feil - hold stram regi) Blir alt for ofte off topic. Alt for ofte én person som er alt for glad i å prate. SM bør ikke være redd for å holde stram regi.Si hva, ikke hvordan. Ikke diskuter detaljer i hvordan du gjorde eller skal gjøre ting (med mindre det er et problem forbundet med det).
- Estimering (liten vits hvis det ikke følges opp)Sjekk hvor lang tid man faktisk brukte: For sammenligning og læring som gjør folk bedre til å estimere, og gir mer nøyaktige estimater. Ikke vanskelig å komme i gang med.
- - Estimering II (hvorfor detaljestimere?)(satt på spissen) Estimering annet enn på overordnet nivå - Product Backlog (PB) items - er bortkastet tid. Så lenge man utfører f.eks. 3-4 PB items ila en sprint er vel det tett nok oppfølging av fremdriften?Med dette mener jeg ikke at man skal la være å analysere hva en PB item innebærer og omfatter. Men mavefølelse på estimering på overordnet nivå er ofte overraskende nøyaktig. Det jevner seg ut.Forutsetter tillit og utviklere som jobber samvittighetsfullt, men hvem gjør vel ikke det? Hvis utviklerne ikke blir stolt på har man et mer alvorlig problem
- - Estimering III.Estimering i story points (i stedet for timer/dager) fungerer faktisk! Mennesker estimerer lettere oppgaver ift andre oppgaver enn for seg selv i antall timer/dager.I tillegg: Lettere å estimere fremover når man regner ut snitt poeng/dagsverk ut ifra faktiske historiske tall.
- Forholdet mellom SM, PL og PO: Har ikke noen fasit - men kan være smart å fokusere mye på ansvarsfordelingen i prosjektorganisasjonen. F.eks. på et tidl. prosjekt ble jeg Scrum Master og Prosjektlederen ble Produkteier sett fra et Scrum-perspektiv.Vær også obs på evt dobbeltroller: SM & utvikler (prioriterer egne oppgaver). SM & leder (overkjører teamet)
- - Forutsetningen for velfungerende Scrum (ansvarlige og dyktige utviklere) vs. Scrum Master-rollen som "ikke skal lede."(jeg synes at Scrum Master må ikke være redd for å ta føringen i den grad det trengs hvis man ikke er på et "super team" med bare selvgående flotte folk.)Også beslektet med dette:- Hva er ferdig og hva er nesten ferdig?Ferdig når...- Det er kodet - Enhetstester er laget - Når det er sjekket inn - Når endringen er testet lokalt - Når hele systemet er testet lokalt - Når systemet er testet på testserveren - osv.Hyppige iterasjoner krever god testing for å få stabile systemer. Testere, produkteier og kunder bør kun unntaksvis finne feil. Her syndes det mye...
- Retrospective - Er sterkt undervurdert. For meg er den systematiske kontinuerlige prosessforbedringen noe av det aller viktigste med Scrum. Gjennomfør regelmessig selv om dere bare bruker deler av Scrum og har foreløpig nedprioritert dette. Husk å følg opp: Oppfølgingspunkter til personer (med tidsfrister) og start neste retrospective med vurdering av oppfølging fraforrige gang.
- Definering av oppgaver (Product Backlog items): Ikke mist fokus av hensikten med oppgaven sett ift kunden. Å spesifisere en oppgave som "oppgradere løsningen til en .Net 4-løsning" eller "endre arkitekturen til å bruke MVVM-patternet" er farlig. Det er gøy med ny teknologi og planlegging for fremtiden, men man mister raskt fokus på lønnsomheten i prosjektet hvis kunden ikke har et klart ønske om f.eks. økt vedlikeholdbarhet som rettferdiggjør oppgavene. I tillegg blir det lettere å snakke med kunden hvis man navngir oppgaver ut ifra kundens behov og ikke tekniske implementasjonsdetaljer.
- Vær smidig med bruken av det smidige :-)Ta i bruk litt og litt etter hvert, og bare gjør det som funker for dere.