Agile intro module 2

613 views
543 views

Published on

Third module of agile/scrum course. Zooming in on requirements / user stories. With practical excercises.

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

No Downloads
Views
Total views
613
On SlideShare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
21
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \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
  • \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
  • \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
  • \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
  • \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
    2. 2. Ere wie ere toekomt ...2
    3. 3. 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.3
    4. 4. 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.4
    5. 5. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests5
    6. 6. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests5
    7. 7. User Story As a trainee I want to know more about User Stories Because this is a core concept in Agile, determines the product, the interaction with the customer and forms the basis for planning6
    8. 8. Why are requirements so difficult7
    9. 9. Why are requirements so difficult7
    10. 10. What is a 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 complete8
    11. 11. What is a 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 complete8
    12. 12. Develop User Stories User Role User Story9
    13. 13. Identify User Roles Receptionist Patient Doctor myHospital Local doctor Nurse supporter of patient10
    14. 14. Group User Roles Patient Receptionist supporter of patient myHospital Doctor Local doctor Nurse11
    15. 15. Personas Patient12
    16. 16. Personas Oma Jans Patient 90 jaar zeer hard-horend slecht ter been nog nooit met computer gewerkt ...12
    17. 17. Personas Oma Jans Patient Kees 90 jaar zeer hard-horend slecht25 jaar ter been nog nooit met computer voetballer gewerkt accountant ... ....12
    18. 18. User Stories As a <User Role> I want <something> So I can achieve <value> acceptance tests13
    19. 19. User Stories As a <User Role> I want <something> So I can achieve <value> acceptance tests13
    20. 20. Cone of Uncertainty clear, precise stories epics14
    21. 21. Trawling15
    22. 22. Trawling methods • User interviews • Questionnaires • Observation • Workshops16
    23. 23. INVEST in User Stories • Independent • Negotiable • Valuable to users or customers • Estimatable • Small • Testable17
    24. 24. Independent A user can pay with Visa card A user can pay with Master card18
    25. 25. Negotiable • A story is NO contract19
    26. 26. Valuable to the user All error handling is done through a set of common classes20
    27. 27. Valuable to the user All errors are presented to the user and logged in a consistent manner20
    28. 28. Estimatable21
    29. 29. Estimatable • When are stories not estimatable?21
    30. 30. Estimatable • When are stories not estimatable? • developers have insufficient domain knowledge21
    31. 31. Estimatable • When are stories not estimatable? • developers have insufficient domain knowledge • developers have insufficient technical knowledge21
    32. 32. Estimatable • When are stories not estimatable? • developers have insufficient domain knowledge • developers have insufficient technical knowledge • stories are too large21
    33. 33. Small22
    34. 34. Small Too big: split up - epic with stories - research and development22
    35. 35. Testable De software moet een goede performance hebben23
    36. 36. Testable Tom Gilb: Planguage23
    37. 37. Planguage TAG Performance Users should not have the GIST feeling they are “waiting for the system” 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”24
    38. 38. Kano model High Customer satisfaction Exciters and delighters ar line / an ce rm rfo Pe Must-have, mandatory Low Fully Absent Feature presence implemented25
    39. 39. Kano - model Must-have, Performance, Exciters and mandatory linear delighters unexpected, hygiene factors more is better not required features unique selling dissatisfiers point26
    40. 40. User Stories vergeleken • Use Cases (Jacobsen) • “traditional” requirements (IEEE 830) • The system shall ...27
    41. 41. User Stories vergeleken Title: buy a book Actor: customer Use Precondition: book is Actor available • Use Cases (Jacobsen) Main scenario: 1. customer selects book • “traditional” requirements basket 830) 2. put in (IEEE 3. pay • The system shall ...Extensions:title 1a search for 1b search for author 3a book not available, delivered later27
    42. 42. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests28
    43. 43. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests28
    44. 44. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests28
    45. 45. User Story As a trainee I want to practice a bit after all theory Because practice makes perfect29
    46. 46. Case30
    47. 47. Case Develop a system to support a bar: • guests can order themselves • system suggests combinations • ordering app connects to back-end • app knows the menu (food & drink) • weekly/monthly offers30
    48. 48. Chaos Cocktail Party • Write an appealing vision for the system on a card • 5 Rounds • Swap card with someone else • At STOP, make pairs and reward 7 points • Add the points on your card31
    49. 49. Instruction • Assign 1 person as Product Owner • Model User Roles • Brainstorm User Stories • Max. 30 minuten32
    50. 50. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests33
    51. 51. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests33
    52. 52. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests33
    53. 53. User Story As a trainee I want to know how to handle acceptance test in Agile Because a User Story is not complete without a test34
    54. 54. Acceptance tests A user can pay with credit card35
    55. 55. Acceptance tests Test with Visa, Master and Amex (pass) Test with Diners Club (fail) Test with good, bad, missing CVC numbers Test with expired cards Test above card limit35
    56. 56. Excercise Now add some acceptance tests to your stories36
    57. 57. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests37
    58. 58. Sprint Backlog TO-DO DOING DONE User Stories Case Acceptance tests37
    59. 59. Summary • Agile Requirements • it’s not about the documentation • but about interaction • Card - Conversation - Confirmation38
    60. 60. Retrospective Start doing Stop doing Continue doing39
    61. 61. 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.40
    62. 62. 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.41

    ×