Agile Intro      Module 2 Agile Requirements         1
Ere wie ere toekomt ...           2
Sprint Backlog      TO-DO        IN WORK   DONE    User Stories        Case    Acceptatie      tests3
Sprint Backlog     TO-DO       IN WORK        DONE                 User Stories       Case    Acceptatie      tests4
User Story    Als een cursist    Wil ik meer weten van User Stories    Omdat dit een kernconcept in Agile is, dat    bepal...
Waarom zijn    requirements zo moeilijk?6
Waarom zijn    requirements zo moeilijk?6
Wat is een User Story?    • Written description of the story used for      planning and as a reminder    • Conversations a...
Wat is een User Story?    • Written description of the story used for        planning and as a reminder    • Conversations...
Ontwikkel User Stories            User Role            User Story8
Identificeer User Roles                              Receptioniste              Patient    Dokter              myHospital  ...
Groepeer User Roles                Patient           Receptioniste     begeleider Patient                          myHospi...
Cone of Uncertainty     heldere, preciese          stories                         grote lijnen                           ...
Trawling12
Product Owner     • De klant, de PO, zou de User Stories       moeten schrijven/geven     • Wie is een goede PO?     • En ...
Trawling methoden     • Interviews met gebruikers     • Vragenlijsten     • Observatie     • Workshops14
INVEST in User Stories     • Independent     • Negotiable     • Valuable to users or customers     • Estimatable     • Sma...
Independent      A user can pay with           Visa card      A user can pay with         Master card16
Negotiable     • Een story is GEEN contract17
Valuable     All error handling is done     through a set of common               classes18
Valuable     All errors are presented to      the user and logged in a          consistent manner18
Estimatable19
Estimatable     • Wanneer zijn stories NIET estimatable?19
Estimatable     • Wanneer zijn stories NIET estimatable?      • ontwikkelaars hebben onvoldoende         domein kennis19
Estimatable     • Wanneer zijn stories NIET estimatable?      • ontwikkelaars hebben onvoldoende         domein kennis    ...
Estimatable     • Wanneer zijn stories NIET estimatable?      • ontwikkelaars hebben onvoldoende         domein kennis    ...
Small20
Small     Te groot: dan splitsen     - epic met stories     - onderzoek en ontwikkeling20
Testable       De software moet een     goede performance hebben21
Testable     Tom Gilb: Planguage21
Planguage     TAG                         Performance                                 Gebruikers moeten niet het     GIST ...
Kano model     High      Customer satisfaction                              Exciters and                               del...
Kano - model      Must-have,     Performance,     Exciters and      mandatory          linear        delighters           ...
User Stories vergeleken     • Use Cases (Jacobsen)     • “traditionele” requirements (IEEE 830)      • The system shall .....
User Stories vergeleken                                      Use                        Actor     • Use Cases (Jacobsen)  ...
User Stories vergeleken                            Title: koop een boek                            Actor: klant           ...
Sprint Backlog      TO-DO       IN WORK        DONE                  User Stories        Case     Acceptatie       tests26
Sprint Backlog      TO-DO       IN WORK    DONE                            User Stories        Case     Acceptatie       t...
Sprint Backlog      TO-DO       IN WORK    DONE                            User Stories                   Case     Accepta...
User Story     Als een cursist     Wil ik na al die theorie wel een beetje oefenen     Omdat oefening kunst baart29
Case     Ontwikkel een applicatie om     thuiszorg uitleen te beheren     • database met hulpmiddelen       • locatie     ...
Chaos Cocktail Party     • Schrijf een aansprekende visie voor de App       op een kaartje     • 5 Rondes      • Wissel ka...
Instructie     • Benoem 1 persoon als Product Owner     • Modelleer User Roles     • Brainstorm User Stories     • Max. 30...
Sprint Backlog      TO-DO       IN WORK    DONE                            User Stories                   Case     Accepta...
Sprint Backlog      TO-DO       IN WORK    DONE                            User Stories                              Case ...
Sprint Backlog     TO-DO      IN WORK       DONE                             User Stories                               Ca...
User Story     Als een cursist     Wil ik weten hoe Agile met acceptatie-tests     omgaat     Omdat een User Story blijkba...
Acceptatie tests      A user can pay with credit card37
Acceptatie tests     Test met Visa, Master and Amex (pass)           Test met Diners Club (fail)     Test met goede, slech...
Wie schrijft de tests?     • The Customer !     • Programmer can help38
Goede/slechte tests     • Goed      • value to the user/customer     • Slecht      • basis programmeer-hygiëne         • d...
Test gedurende Sprint     VOOR DE SPRINT   TIJDENS DE SPRINT      Acceptatie op   Eerst test schrijven,       User Story  ...
Sprint Backlog     TO-DO      IN WORK       DONE                             User Stories                               Ca...
Sprint Backlog     TO-DO      IN WORK     DONE                           User Stories                             Case    ...
Samenvatting     • Agile Requirements      • niet de documentatie is belangrijk      • maar de interactie     • Card - Con...
Retrospective     Start doing              Stop doing                    Continue doing44
Agile Manifesto              We are uncovering better ways of developing              software by doing it and helping oth...
12 principes                                                        Our highest priority is to satisfy the customer       ...
Upcoming SlideShare
Loading in...5
×

Agile intro module 2

699

Published on

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

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

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • Hoe herken je een extraverte software engineer?\n\nDe business weet niet wat ze wil\nKan het niet uitleggen in termen waar IT iets mee kan\nSoftware engineers zijn verlegen / nerd / houden van puzzelen\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 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.\n
  • Goed:\n- users/gebruikers, maar niet: customers\n- marketing/sales\n- vroegere gebruikers\n- business analisten\nSlecht:\n- manager van users\n- development manager\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • En dan?\n- R&D stories\n- Kleiner stories\n
  • En dan?\n- R&D stories\n- Kleiner stories\n
  • En dan?\n- R&D stories\n- Kleiner stories\n
  • En dan?\n- R&D stories\n- Kleiner stories\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Voorbeeld:\nhotelkamer\n- MH - bed, douche, schoon\n- Linear - m2\n- Exciters - fitness ruimte, WIFI\n
  • Groot verschil met “the system shall” is dat daar het systeem beschreven wordt (wat doet het systeem).\nIn use cases en user stories wordt de interactie van de gebruiker met het systeem beschreven.\n
  • Groot verschil met “the system shall” is dat daar het systeem beschreven wordt (wat doet het systeem).\nIn use cases en user stories wordt de interactie van de gebruiker met het systeem beschreven.\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Twee mogelijke uitvoeringen:\n- voor mij - wat moet ik met deze cursus starten/stoppen/doorgaan\n- voor de deelnemers - wat gaan zij morgen in hun werk doen\nVoorkeur voor de tweede vorm.\n
  • Toepassing op Requirements\n1\n- ga bij elkaar zitten tijdens release/sprint planning\n- leg uit wat je bedoelt met een requirement\n2\n- voor een sprint van 3 weken kan je veel details wel onthouden, documenteer alleen het noodzakelijke\n- snelle oplevering zorgt ook voor snelle leercurve voor foutief ingeschatte requirements\n3\n- ga bij elkaar zitten ...\n4\n- elke nieuwe sprint kan iets volledig anders zijn dan vooraf gedacht\n
  • Toepassing op requirements\n1. Feedback in sprint review\n2. Sprint planning\n3. -\n4. Release / sprint planning\n5. -\n6. -\n7. Sprint review\n8. Release/sprint planning\n9. Sprint\n10. Release/sprint planning\n11. -\n12. Release/sprint planning/daily scrum/sprint review\n
  • Agile intro module 2

    1. 1. Agile Intro Module 2 Agile Requirements 1
    2. 2. Ere wie ere toekomt ... 2
    3. 3. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests3
    4. 4. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests4
    5. 5. User Story Als een cursist Wil ik meer weten van User Stories Omdat dit een kernconcept in Agile is, dat bepalend is voor de interactie met de klant, en de basis voor de planning5
    6. 6. Waarom zijn requirements zo moeilijk?6
    7. 7. Waarom zijn requirements zo moeilijk?6
    8. 8. 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 complete7
    9. 9. Wat is een User Story? • Written description of the story used for planning and as a reminder • Conversationsaabout the story that serve As <User Role> to flash out wantdetails of the story I the <something> So I can achieve <value> • Tests that convey and document details and that can be used to determine when a story is complete7
    10. 10. Ontwikkel User Stories User Role User Story8
    11. 11. Identificeer User Roles Receptioniste Patient Dokter myHospital Huisarts Verpleegster begeleider Patient9
    12. 12. Groepeer User Roles Patient Receptioniste begeleider Patient myHospital Dokter Huisarts Verpleegster10
    13. 13. Cone of Uncertainty heldere, preciese stories grote lijnen stories11
    14. 14. Trawling12
    15. 15. Product Owner • De klant, de PO, zou de User Stories moeten schrijven/geven • Wie is een goede PO? • En wie niet?13
    16. 16. Trawling methoden • Interviews met gebruikers • Vragenlijsten • Observatie • Workshops14
    17. 17. INVEST in User Stories • Independent • Negotiable • Valuable to users or customers • Estimatable • Small • Testable15
    18. 18. Independent A user can pay with Visa card A user can pay with Master card16
    19. 19. Negotiable • Een story is GEEN contract17
    20. 20. Valuable All error handling is done through a set of common classes18
    21. 21. Valuable All errors are presented to the user and logged in a consistent manner18
    22. 22. Estimatable19
    23. 23. Estimatable • Wanneer zijn stories NIET estimatable?19
    24. 24. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis19
    25. 25. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis • ontwikkelaars hebben onvoldoende technische kennis19
    26. 26. Estimatable • Wanneer zijn stories NIET estimatable? • ontwikkelaars hebben onvoldoende domein kennis • ontwikkelaars hebben onvoldoende technische kennis • stories zijn te groot19
    27. 27. Small20
    28. 28. Small Te groot: dan splitsen - epic met stories - onderzoek en ontwikkeling20
    29. 29. Testable De software moet een goede performance hebben21
    30. 30. Testable Tom Gilb: Planguage21
    31. 31. 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”22
    32. 32. Kano model High Customer satisfaction Exciters and delighters ar lin e / an ce fo rm Per Must-have, mandatory Low Fully Absent Feature presence implemented23
    33. 33. Kano - model Must-have, Performance, Exciters and mandatory linear delighters unexpected, hygiene factors more is better not required features unique selling dissatisfiers point24
    34. 34. User Stories vergeleken • Use Cases (Jacobsen) • “traditionele” requirements (IEEE 830) • The system shall ...25
    35. 35. User Stories vergeleken Use Actor • Use Cases (Jacobsen) • “traditionele” requirements (IEEE 830) • The system shall ...25
    36. 36. 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 geleverd25
    37. 37. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests26
    38. 38. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests27
    39. 39. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests28
    40. 40. User Story Als een cursist Wil ik na al die theorie wel een beetje oefenen Omdat oefening kunst baart29
    41. 41. Case Ontwikkel een applicatie om thuiszorg uitleen te beheren • database met hulpmiddelen • locatie • sorteer/zoek mogelijkheden • uitleen gegevens • iPhone app voor leners30
    42. 42. 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 op31
    43. 43. Instructie • Benoem 1 persoon als Product Owner • Modelleer User Roles • Brainstorm User Stories • Max. 30 minuten32
    44. 44. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests33
    45. 45. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests34
    46. 46. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests35
    47. 47. User Story Als een cursist Wil ik weten hoe Agile met acceptatie-tests omgaat Omdat een User Story blijkbaar niet af is zonder acceptatie test36
    48. 48. Acceptatie tests A user can pay with credit card37
    49. 49. 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 limit37
    50. 50. Wie schrijft de tests? • The Customer ! • Programmer can help38
    51. 51. Goede/slechte tests • Goed • value to the user/customer • Slecht • basis programmeer-hygiëne • datum = 30 februari39
    52. 52. Test gedurende Sprint VOOR DE SPRINT TIJDENS DE SPRINT Acceptatie op Eerst test schrijven, User Story dan pas code40
    53. 53. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests41
    54. 54. Sprint Backlog TO-DO IN WORK DONE User Stories Case Acceptatie tests42
    55. 55. Samenvatting • Agile Requirements • niet de documentatie is belangrijk • maar de interactie • Card - Conversation - Confirmation43
    56. 56. Retrospective Start doing Stop doing Continue doing44
    57. 57. Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.45
    58. 58. 12 principes Our highest priority is to satisfy the customer Working software is the primary 1 measure of progress. 7 through early and continuous delivery of valuable software. Agile processes promote sustainable Welcome changing requirements, even late in development. The sponsors, developers, 2 and users should be able to maintain a 8 development. Agile processes harness change for the customers competitive advantage. constant pace indefinitely. Continuous attention to technical Deliver working software frequently, from a 3 excellence and good design enhances 9 couple of weeks to a couple of months, with a agility. preference to the shorter timescale. Simplicity--the art of maximizing the Business people and developers must work 4 amount of work not done--is essential. 10 together daily throughout the project. The best architectures, requirements, Build projects around motivated individuals. 5 and designs emerge from self-organizing teams. 11 Give them the environment and support they need, and trust them to get the job done. At regular intervals, the team reflects The most efficient and effective method of on how to become more effective, then 6 tunes and adjusts its behavior 12 conveying information to and within a development team is face-to-face conversation. accordingly.46
    1. A particular slide catching your eye?

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

    ×