Agile requirements

1,222 views

Published on

Workshop to increase craftsmanship on using user stories in agile projects.

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
1,222
On SlideShare
0
From Embeds
0
Number of Embeds
37
Actions
Shares
0
Downloads
26
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide



  • Doel van de serie van workshops (elke laatste vrijdag van de maand): ontwikkelen van vakmanschap.
    Veel te weinig aandacht gekregen
    - overfocus op process en technology
    - onderschatting van ervaring en skill - je kan pas echt beitelen als je het vaak gedaan hebt, in verschillende soorten hout, met verschillende fijnheden van werk - je kan pas echt software ontwikkelen, teams leiden, testen, requirements beschrijven, ... als je het vaak gedaan hebt.


  • Hoe herken je een extraverte software engineer?

    De business weet niet wat ze wil
    Kan het niet uitleggen in termen waar IT iets mee kan
    Software engineers zijn verlegen











  • Mike Cohn, in navolging van Suzanne Robertson, gebruikt de term TRAWLING for user stories. Ernaar vissen. Mooie metafoor. Je vangt niet altijd alles in 1 keer. Moet verschillende netten met verschillende mazen gebruiken om verschillende soorten user stories te vangen.
  • Goed:
    - users/gebruikers, maar niet: customers
    - marketing/sales
    - vroegere gebruikers
    - business analisten
    Slecht:
    - manager van users
    - development manager






  • En dan?
    - R&D stories
    - Kleiner stories
  • En dan?
    - R&D stories
    - Kleiner stories
  • En dan?
    - R&D stories
    - Kleiner stories
  • En dan?
    - R&D stories
    - Kleiner stories




  • Groot verschil met “the system shall” is dat daar het systeem beschreven wordt (wat doet het systeem).
    In use cases en user stories wordt de interactie van de gebruiker met het systeem beschreven.
  • Groot verschil met “the system shall” is dat daar het systeem beschreven wordt (wat doet het systeem).
    In use cases en user stories wordt de interactie van de gebruiker met het systeem beschreven.














  • Let op: dit is geen sales show for LCS!
    Noem ook alternatieven: Jira, Pivotal Tracker, ScrumWorks, TFS
    Focus op traceability







  • Agile requirements

    1. 1. Netwerk Meeting Agile Requirements 1
    2. 2. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 2
    3. 3. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 3
    4. 4. Netwerk meetings • Vakmanschap • Software ontwikkeling • Software management 4
    5. 5. Wie ben ik? • Certified Scrum Master • Certified CMMI Lead Appraiser en Instructor • Consultant SWE/SWM • Creatief, pragmatisch • Rijnlander 5
    6. 6. Scope • Agile Requirements • Rol Product •Schatting Owner • Users / User Roles • Planning 6
    7. 7. Waarom zijn requirements zo moeilijk? 7
    8. 8. Waarom zijn requirements zo moeilijk? 7
    9. 9. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 8
    10. 10. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 9
    11. 11. Bijenkorf • Uitgangspunt: het is makkelijker iets voor een ander te vragen dan voor jezelf • Maak trio’s: 1koningin, 2 werkbijen • Koningin heeft vraag • Werkbijen netwerken om antwoord te krijgen • NEE antwoord mag wel, maar dan wel doorverwijzen 10
    12. 12. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 11
    13. 13. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 12
    14. 14. Ere wie ere toekomt ... 13
    15. 15. Wat is een User Story? • Written description of the story used for planning and as a reminder • Conversations about the story that serve to flash out the details of the story • Tests that convey and document details and that can be used to determine when a story is complete 14
    16. 16. Ontwikkel User Stories User Role User Story 15
    17. 17. Identificeer User Roles Receptioniste Patient Dokter myHospital Huisarts Verpleegster begeleider Patient 16
    18. 18. Groepeer User Roles Patient Receptioniste begeleider Patient myHospital Dokter Huisarts Verpleegster 17
    19. 19. Cone of Uncertainty heldere, preciese stories grote lijnen stories 18
    20. 20. Trawling 19
    21. 21. Product Owner • De klant, de PO, zou de User Stories moeten schrijven/geven • Wie is een goede PO? • En wie niet? 20
    22. 22. Trawling methoden • Interviews met gebruikers • Vragenlijsten • Observatie • Workshops 21
    23. 23. INVEST in User Stories • Independent • Negotiable • Valuable to users or customers • Estimatable • Small • Testable 22
    24. 24. Independent A user can pay with Visa card A user can pay with Master card 23
    25. 25. Negotiable • Een story is GEEN contract 24
    26. 26. Valuable All error handling is done through a set of common classes 25
    27. 27. Valuable All errors are presented to the user and logged in a consistent manner 25
    28. 28. Estimatable 26
    29. 29. Estimatable • Wanneer zijn stories NIET estimatable? 26
    30. 30. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis 26
    31. 31. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis • ontwikkelaars hebben onvoldoende technische kennis 26
    32. 32. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis • ontwikkelaars hebben onvoldoende technische kennis • stories zijn te groot 26
    33. 33. Small 27
    34. 34. Small Te groot: dan splitsen - epic met stories - onderzoek en ontwikkeling 27
    35. 35. Testable De software moet een goede performance hebben 28
    36. 36. Testable Tom Gilb: Planguage 28
    37. 37. Planguage TAG Performance Gebruikers moeten niet het GIST gevoel hebben “op het systeem te wachten” PLAN (100 concurrent users) Reponse time < 2s MUST (100 concurrent users) Reponse time < 5s PAST (100 concurrent users) Reponse time > 10s Automatic test script METER “PERFORMANCE” 29
    38. 38. User Stories vergeleken • Use Cases (Jacobsen) • “traditionele” requirements (IEEE 830) • The system shall ... 30
    39. 39. User Stories vergeleken Use Actor • Use Cases (Jacobsen) • “traditionele” requirements (IEEE 830) • The system shall ... 30
    40. 40. User Stories vergeleken Title: koop een boek Actor: klant Use Precondition: boek op Actor voorraad • Use Cases (Jacobsen) scenario: Main 1. klant selecteert boek • 2. plaats in winkelwagen “traditionele” requirements (IEEE 830) 3. betaal • Extensions: The system shall1a zoek op titel ... 1b zoek op auteur 3a boek niet op voorraad, wordt later geleverd 30
    41. 41. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 31
    42. 42. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 32
    43. 43. Case Ontwikkel een iPhone App om onze huis-bibliotheek te beheren • database met boeken • locatie • sorteer/zoek mogelijkheden • uitleen gegevens 33
    44. 44. Chaos Cocktail Party • Schrijf een aansprekende visie voor de App op een kaartje • 5 Rondes • Wissel kaartje uit met anderen • Bij STOP, maak tweetallen, verdeel 7 punten over de 2 kaartjes • Tel de punten op de kaartjes bij elkaar op 34
    45. 45. Instructie • Benoem 1 persoon als Product Owner • Modelleer User Roles • Brainstorm User Stories • Afronden: 14:45 35
    46. 46. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 36
    47. 47. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 37
    48. 48. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 38
    49. 49. Acceptatie tests A user can pay with credit card 39
    50. 50. Acceptatie tests Test met Visa, Master and Amex (pass) Test met Diners Club (fail) Test met goede, slechte, ontbrekende CVC nummers Test met verlopen cards Test met bedrag boven card limit 39
    51. 51. Wie schrijft de tests? • The Customer ! • Programmer can help 40
    52. 52. Goede/slechte tests • Goed • value to the user/customer • Slecht • basis programmeer-hygiëne • datum = 30 februari 41
    53. 53. Test gedurende Sprint VOOR DE SPRINT TIJDENS DE SPRINT Acceptatie op Eerst test schrijven, User Story dan pas code 42
    54. 54. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 43
    55. 55. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 44
    56. 56. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 45
    57. 57. Samenvatting • Agile Requirements • niet de documentatie is belangrijk • maar de interactie • Card - Conversation - Confirmation 46
    58. 58. Volgende meeting(s) Elke laatste vrijdag van de maand Juni Agile Planning and Estimating September Oktober November 47
    59. 59. Retrospective • Graag feedback op het evaluatieformulier 48
    60. 60. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 49
    61. 61. Agenda 13:00 Intro 13:15 Requirements Game 13:45 User Stories 14:15 Case - deel 1 14:45 Koffie 15:00 Acceptatie tests 15:30 Presentatie en demo LifeCycleSuite 16:30 Conclusies 17:00 Borrel 50
    62. 62. Origami • Maak tweetallen, instructeur en vouwer • Groep 1 - zit naast elkaar • vouwer krijgt instructies en kan meekijken op sheet • Groep 2 - zit tegenover elkaar • vouwer krijgt instructies, maar kan niet meekijken • Groep 3 - zit met de ruggen naar elkaar • vouwer krijgt instructies ‘over de schouder heen’ 51

    ×