3. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
3
4. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
4
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 planning
5
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 complete
7
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 complete
7
23. Estimatable
• Wanneer zijn stories NIET estimatable?
19
24. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
19
25. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
• ontwikkelaars hebben onvoldoende
technische kennis
19
26. Estimatable
• Wanneer zijn stories NIET estimatable?
• ontwikkelaars hebben onvoldoende
domein kennis
• ontwikkelaars hebben onvoldoende
technische kennis
• stories zijn te groot
19
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. Kano model
High
Customer satisfaction
Exciters and
delighters ar
lin e
/
an ce
fo rm
Per Must-have,
mandatory
Low Fully
Absent Feature presence
implemented
23
33. Kano - model
Must-have, Performance, Exciters and
mandatory linear delighters
unexpected,
hygiene factors more is better not required
features
unique selling
dissatisfiers
point
24
34. User Stories vergeleken
• Use Cases (Jacobsen)
• “traditionele” requirements (IEEE 830)
• The system shall ...
25
35. User Stories vergeleken
Use
Actor
• Use Cases (Jacobsen)
• “traditionele” requirements (IEEE 830)
• The system shall ...
25
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 geleverd
25
37. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
26
38. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
27
39. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
28
40. User Story
Als een cursist
Wil ik na al die theorie wel een beetje oefenen
Omdat oefening kunst baart
29
41. Case
Ontwikkel een applicatie om
thuiszorg uitleen te beheren
• database met hulpmiddelen
• locatie
• sorteer/zoek mogelijkheden
• uitleen gegevens
• iPhone app voor leners
30
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 op
31
43. Instructie
• Benoem 1 persoon als Product Owner
• Modelleer User Roles
• Brainstorm User Stories
• Max. 30 minuten
32
44. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
33
45. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
34
46. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
35
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 test
36
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 limit
37
50. Wie schrijft de tests?
• The Customer !
• Programmer can help
38
51. Goede/slechte tests
• Goed
• value to the user/customer
• Slecht
• basis programmeer-hygiëne
• datum = 30 februari
39
52. Test gedurende Sprint
VOOR DE SPRINT TIJDENS DE SPRINT
Acceptatie op Eerst test schrijven,
User Story dan pas code
40
53. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
41
54. Sprint Backlog
TO-DO IN WORK DONE
User Stories
Case
Acceptatie
tests
42
55. Samenvatting
• Agile Requirements
• niet de documentatie is belangrijk
• maar de interactie
• Card - Conversation - Confirmation
43
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. 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 customer's 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
Editor's Notes
\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
Groot verschil met &#x201C;the system shall&#x201D; 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 &#x201C;the system shall&#x201D; 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