Agile intro module 2

730
-1

Published on

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

No Downloads
Views
Total Views
730
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

    ×