2016-01-19
En agil systemutvecklingsprocess
Vattenfallsmodellen
Annika Silvervarg
•
•
•
•
•
•
•
•
Manifesto for
Agile Software Development
Agila modellen
Sprint 0
Strategic intake & research
(Strategic intake & research)
(Product statement)
(Design koncept)
Technical solution outline
Practical agreements
Setting up the ”room”
Definition of done
Start on Product backlog
• Market and end-user
– Competition?
– Market?
– End-users?
• Brand
– Defined brand?
– ”tone-of-voice”?
– Corporate visual identity?
1
2016-01-19
Product statement
• Template: For (target customer) who (statement of
need or opportunity) the (product name) is a
(product category) that (key benefit, compelling
reason to buy)
Design koncept
• Graphic profile
• Conceptual design
• Example: trakz.nl is a trustworthy online music store,
we are personal and passionate about music!
Technical solution outline
• Can include
– legacy system limitations
– CMS characteristics
Practical agreement
•
•
•
•
•
•
When do you work?
Where do you work?
Contact information, e-mail, phonenumbers….
When do you have stand-up meetings (and how)?
When do you demo (test) and with whom?
When and how do you do the retrospective?
Setting up the ”room”
•
•
•
•
Hardware
The room
Supplies
Software
– Dropbox?
– GIT, SVN,…
• Scrumboard
• Trello, wiki, excel, google docs,…
Definition of Done
• Technical requirements
–
–
–
–
Devices?
Browsers?
Documentation?
How tested?
• User experience
– How does it feel?
– Tests with external people?
• Customer acceptance
– Who decides when done is done?
2
2016-01-19
Start on product backlog
• The backlog is a prioritized features list, containing
short descriptions of all functionality desired in the
product, typically in the form of
• User stories, which are short, simple descriptions of
the desired functionality told from perspective of the
user
User story template
• Title (one line describing the story)
• As a [role]
I want [user need]
So that/because [resulting ability] OR
• As a [role]
I can [do/view something]
– "As a shopper, I can review the items in my shopping cart
before checking out so that I can see what I've already
selected."
User story examples
A good user story – INVEST
•
•
•
•
Independent, of other stories
Negotiable, not a contract
Valuable, to customer or end user
Estimable, enough information and reasonable
scope
• Small, coded and tested within half a day to two
weeks
• Testable, clear definition of ”done”
Sprint 1-6
Release planning
• Release plan
• Iteration plan
– Velocity
– Time estimates – Planning poker
– Prioritise
•
•
•
•
Scrum board and Burn down chart
Daily scrums
Demo and Acceptance testing
Retrospective
3
2016-01-19
Release planning –
Step 1: Writing user stories
Release Planning
• Customer presents the desired features to the
programmers as user stories
• Programmers estimate their difficulty
• Customer lays out a plan for the project
• Initial release plans are necessarily imprecise.
However, even the first release plan is accurate
enough for decision making and teams revise the
release plan regularly
•
Release planning –
Step 2: Time esitmation
•
Developers estimate how long the stories might
take to implement
– Each story will get a 1, 2 or 3 days estimate in ideal
development time
– Longer than 3 days means that the customer need to
break the story down further and less than 1 day that it is
at too detailed a level, combine some stories
– Stories can be assigned technical risk: low, medium,
high
Iteration planning
• During Iteration planning, the Customer presents the
features desired for the next iteration
• The programmers break them down into tasks, and
estimate their cost (at a finer level of detail than in
Release Planning)
• Based on the amount of work accomplished in the
previous iteration, the team signs up for what will be
undertaken in the current iteration
Customers write user stories
– Stories can be assigned business value: essential, highly
valuable or good idea (or a more fine grained scale, eg.
1 to 10)
– Developers can suggest stories but the customer has
always final say
– Stories can always be added, changed or deleted
Release planning –
Step 3: Prioritising stories
•
Together developers and customers move the
cards around on a large table to create a set of
stories to be implemented as the first/next release
– A useable, testable system that makes good business
sense delivered early is desired
– You may plan by time or by scope
•
•
either how many stories can be implemented before a
given date (time), or
how long a set of stories will take to finish (scope)
Iteration planning –
Step 1: Project velocity and scope
• Project velocity is calculated based on previous
iterations (initial velocity often set to 50%)
– Velocity = completed stories divided by actual hours
59/84h = 70%
– Time for next iteration = velocity * time * number of pairs
70% * 28h * 3 = 59 h (ideal time)
• Customer choose prioritised stories from release
plan
• Failed stories/tasks from the previous iteration to be
fixed are also selected
4
2016-01-19
Iteration planning –
Step 2: Creating tasks
• The user stories and failed tests are broken down
into the programming tasks that will support them by
the developers
– Tasks are written down on index cards like user stories
– While user stories are in the customer's language, tasks
are in the developer's language
– Duplicate tasks can be removed
– Each story has a corresponding task card for writing an
acceptance test together with the customer
Planning poker
Iteration planning –
Step 3: Time estimation
• Estimates are made by the team and tasks divided
at the end of the session, or put in a stack where
developers choose tasks one at a time
– Each task should be estimated as 1, 2, or 3 ideal
programming hours in duration
– Tasks which are shorter than 1 hour can be grouped
together and tasks which are longer than 3 hours should
be broken down farther
• or developers sign up to do the tasks and then
estimate how long their own tasks will take to
complete
Planning poker
• Alla i teamet estimerar en story/task
– Väljer ett kort/skriver en siffra
• Alla visar upp sitt val samtidigt
• Den som valt minst tid och den som valt mest tid
diskuterar och enas om en estimering
• Finns flera varianter…
• Finns appar att använda istället för kortlek
SCRUM Board
Burn down chart
5
2016-01-19
Demo and Acceptance tests
Acceptance test
• Short presentation of the process of the sprint
(preconditions, constraints, impediments, etc.)
• Short ”walk through” of the product, explaining
decisions made (focus on what, not how)
• Customer (stakeholders) sit down individually and
go through users stories using the system and
judge if acceptance tests pass or fail
• Acceptance tests are created from user stories
• During an iteration the user stories selected will be
translated into acceptance tests by the customer
• A story can have one or many acceptance tests,
each acceptance test represents some expected
result from the system
• Customers are responsible for verifying the
correctness of the acceptance tests and decide
which failed tests are of highest priority to fix in the
next iteration
– Failed acceptance tests are collected for next iteration
• Scrum master have closing discussion with
customers and bring the most important bits back to
the team
Acceptance test template
• Scenario 1: Title
• Narrative:
Given [context] (And [some more context]...)
When [event]
Then [outcome] (And [another outcome]...)
Retrospective
Acceptance test examples
User story
test
Criteria for acceptance
Retrospective
• ”Inspect and adapt”
• Draw a timeline of the sprint on a whiteboard
• Sit down individually (5 min)
– Write positive things on green post its
– Write negative things on pink post its
• Place the post its on the timeline (2 min)
• Look at the board and discuss what you wrote to
identify patterns or clusters (5 min)
• Choose max 3 things you want to improve (5 min)
6
2016-01-19
Sprint 0
•
•
•
•
•
•
•
•
Sprint 0 – Att Göra
• Grupp: Utse en scrum master
• Grupp: Gå igenom scheman och gör en detaljerad planering
för vilka tider gruppen ska jobba. Bestäm ett lämpligt straff för
sen ankomst (t.ex. bjuda gruppen på fika)
• Scrum master: Välj en lämplig yta på en stor whiteboard och
rita upp en scrum board (se nedan)
• Grupp: Se till att ett möte med kunden äger rum. Utbyt
kontaktuppgifter och kom överens med kunden om hur
kommunikationen under projektet ska fungera
Sprint 1-6
• Release plan
• Iteration plan
– Velocity
– Time estimates – Planning poker
– Prioritise
•
•
•
•
Scrum board and Burn down chart
Daily scrums
Demo and Acceptance testing
Retrospective
(Strategic intake & research)
(Product statement)
(Design koncept)
Technical solution outline
Practical agreements
Setting up the ”room”
Definition of done
Start on Product backlog
Sprint 0 – Att Göra
• Kund: Delta i möte med projektgruppen och gör en översiktlig
beskrivning av det planerade systemet (inklusive syfte,
vision, etc). Eventuella sekretessavtal skrivs lämpligtvis
under vid detta möte
• Kund: Förbered user stories och förmedla till projektgruppen
• Grupp: Genomför en tekniköversikt och riskanalys gällande
val av teknikplattformar (utvecklingsverktyg, programspråk,
databashanterar, etc).
Sprint 1-6 – Att Göra
Före sprint start
• Scrum master: Uppdatera backlog
(justera och lägg tillbaka stories som fått fail).
• Scrum master: Se till att material finns på plats (pennor, postits, etc).
• Kund: Förbered nya user stories (vid behov) och lägg dem i
Backlog. Gör en prioritering av alla user stories i Backlog.
• Grupp: Tidsestimera alla user stories i Backlog i
prioritetsordning.
7
2016-01-19
Sprint 1-6 – Att Göra
Sprint start
• Grupp: Välj ut en mängd user stories (i prioriteringsordning)
så att den uppskattade summan av tider stämmer ungefär
överens med den tillgängliga tiden för user stories denna
sprint (ta hänsyn till förra sprints velocity vid beräkning av
tillgänglig tid).
• Grupp: Bryt ner valda user stories till tasks och skriv tasklappar.
• Kund: Det är bra om kunden finns tillhands och kan svara på
frågor då stories bryts ner till tasks (antingen på plats eller via
telefon/chat).
Sprint 1-6 – Att Göra
• Scrum master: Placera lapparna för alla valda stories på
tavlan. Alla stories och deras tillhörande tasks placeras i
kolumnen Not Started och sorteras i prioriteringsordning med
högst prioritet överst.
• Grupp: Kör ett kort scrum-möte för att avgöra vem som börjar
med vad. Varje gruppmedlem (eller par om man kör
parprogrammering) väljer en task, och skriver sitt namn på
lappen och flyttar den till kolumnen Started.
• Scrum master: Ritar upp ny burn-down chart: x-axeln speglar
antal arbetsdagar som ingår i denna sprint. Y-axeln speglar
summan av tidsuppskattningarna för alla tasks som hör till
utvalda stories.
Sprint 1-6 – Att Göra
• Grupp: Tidsestimera alla tasks med Planning poker.
Skriv den överenskomna tiden på respektive task-lapp.
Om summan av tiden för alla tasks som ingår i en story är
mycket större än den uppskattade tiden för storyn, kontakt
kunden för en diskussion.
Ska en annan story släppas från denna sprint?
Ska storyns omfång (scope) definieras om?
Ska prioriteringen av stories ändras?
Allt är möjligt.
Sprint 1-6 – Att Göra
Under sprinten - Scrum-möten i början av varje ”arbetsdag”
• Scrum master: Leder mötet och fördelar ordet.
• Grupp: Varje gruppmedlem besvarar kortfattat tre frågor:
1) Vad har jag gjort sedan förra mötet?
2) Vad åtar jag mig att göra till nästa planerad scrum möte?
3) Finns det något som hindrar mig i mitt åtagande (behöver
jag hjälp med något)?
• Grupp: Alla gruppmedlemmar uppdaterar
tidsuppskattningarna av de tasks de jobbar med. Om en task
är färdig flyttas den till kolumnen Done. Om alla tasks för en
user story är klara flyttas lappen med storyn till
kolumnen Ready for Review.
Sprint 1-6 – Att Göra
Sprint 1-6 – Att Göra
• Scrum master: Uppdaterar burn-down chart så att den
stämmer med de nya återstående tiderna.
• Scrum master: Om aktuell status i burn-down chart avviker
väsentligt från ideallinjen, ska kunden kontaktas och
informeras om läget. Tänkbara resultat från denna kontakt
kan t.ex. vara att en eller flera user stories tas bort från
denna sprint (eller läggs till om utvecklingen gått bättre än
förväntat). Om så är fallet ska burn-down chart uppdateras
så att den speglar det nya läget.
Sprint end
• Scrum master: Allokera en timme för demon. Schemalägg
med kunden i god tid.
• Grupp: Dema systemet för kunden, och gå igenom alla user
stories som gjorts under sprinten.
• Kund: Avgör om det blir pass/fail för varje user story. User
stories som fått fail skrivs om och läggs tillbaka i backlog.
8
2016-01-19
Sprint 1-6 – Att Göra
• Scrum master: Allokera en timme för retrospective. Äger rum
efter demon (kunden deltar ej).
• Scrum master: Gå igenom sprinten som ägt rum och påminn
om bra och dåliga saker som inträffat.
• Grupp: Varje gruppmedlem (inklusive scrum master) skriver
(under tystnad) post-its med Plus (saker som gått riktigt bra
under sprinten) och Delta (saker som inte fungerat under
sprinten).
• Scrum master: Be varje medlem komma fram och sätta upp
sina post-its på tavlan och kortfattat förklara vad som menas.
Ingen diskussion.
Sprint 1-6 – Att Göra
• Scrum master: gå igenom alla positiva post-its på tavlan,
summera och be om eventuella kompletterande
kommentarer.
• Scrum master: gå igenom alla Delta post-its på tavlan,
summera och diskutera igenom det hela med gruppen. Vad
kan vi som grupp göra för att undvika dessa Delta?
• Grupp: Rösta om vilka Deltan som gruppen ska jobba med
att förbättra under nästa sprint (tre röster per gruppmedlem).
Tre Deltan väljs ut. Lapparna för dessa Deltan placeras på
gruppens whiteboard. Dessa tas också upp för diskussion vid
nästa Retrospective. Gick det bättre nu?
• Scrum master: Behåll lapparna för uppföljning.
Sprint 1-6 – Att Göra
• Scrum master: Efter retrospective rensar scrum master upp
scrum board för att göra plats för nästa sprint, och beräknar
den aktuella sprintens hastighet (velocity).
• Scrum master: Fyller i sprintformuläret och lämnar in till
läraren.
9