Post on 15-Aug-2015
“the thinking it took to get us into this mess is not the same thinking that is going to get us out of it.”
5
ag
ile m
an
ifest
oindividuals and interactions over processes and toolsworking software over comprehensive documentation
customer collaboration over contract negotiationresponding 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
www.agilemanifesto.org
kent beck - mike beedle - arie van bennekum - alistair cockburnward cunningham - martin fowler - james grenning - jim highsmith
andrew hunt - ron jeffries - jon kern - brian marick - robert c. martinsteve mellor - ken schwaber - jeff sutherland - dave thomas
6
scru
m (
n) a framework
within which people can addresscomplex adaptive problems,
while productively and creatively delivering products
of the highest possible value
7
scrumshippable
product increment
sprint planning meeting• review product backlog• what: stories for sprint• how: engineering solutions• commit to few weeks of work
sprint backlogstories selected, tasks agreedby team-members
product backlog:ordered list of
stories desired bythe product owner
scrum
sprintsprint review &
team retrospective
8
wholeteam
planninggame
smallreleases
customertests
collectiveownership coding
standard
sustainablepace
continuousintegration
test-drivendevelopment
refactoring
simpledesign
pairprogramming
pra
ctic
es
- xp
10
ag
ile m
an
ifest
o individuals and interactions over blah blah blahblah blah blah over blah blah blah
blah blah blahblah blah blah
(alistair coburn)
11
scru
m (
n) a framework within which
people can addresscomplex adaptive problems,
while productively and creatively delivering productsof the highest possible value
12
scrumshippableproduct increment
sprint planning meeting• review product backlog• what: select stories for sprint• how: engineering solutions• commit to few weeks of work
sprint backlogitems selected, tasks agreedby team-members
product backlog:ordered list of
items desired bythe product owner
scrum
sprintsprint review &
team retrospective
15
wholeteam
planninggame
smallreleases
customertests
collectiveownership coding
standard
sustainablepace
continuousintegration
test-drivendevelopment
refactoring
simpledesign
pairprogramming
pra
ctic
es
- xp
16
wholeteam
planninggame
smallreleases
customertests
collectiveownership coding
standard
sustainablepace
continuousintegration
test-drivendevelopment
refactoring
simpledesign
pairprogramming
assemblyintegrationevolution
architecturalrisk analysis
deployment &operations
legacysystems
insiderthreat
incidentmanagement
deployment &operationsrisk
management
requirementsengineering
measurement
penetrationtesting
securitytesting
systemstrategies
white boxtesting
17
not
that
diff
ere
nt
coding
standard
collective code
ownersh
ip
continuous
integration
design
improvemen
t
pair programming
planning gam
e
simple design
small
releases
sustainable pace
system metaphor
test driven developmen
t
whole
team
acquisition x x x
architectural risk analysis x x x x x x x
assembly, integration, and evolution x x x x
code analysis x x x
deployment and operations x x x
governance and management x
incident management
insider threat x x x x x
legacy systems
measurement x
penetration testing x x x x x
project management
requirements engineering x x x x x
risk management x x x x x x
security testing x x x x x
system strategies x x x x x x x
training and awareness x x
white box testing x x x x x
22
stori
es
stories get their namefrom how they should be used,
not what should be written
Jeff Patton, Peter Economy: User Story Mapping (2014)
24
back
log
refin
em
en
t• product owner & development
team collaboration• design is happening now,
you may want to document• stories are explored,
split, added• team has to understand
the work before orderingor estimating:• at start of the delivery• before sprint planning
25
test
dri
ven
develo
pm
en
t• think about what you want to do• think about how to test it• write a small test• write just enough code to fail the test.• run and watch the test fail• write just enough code to pass the test (and all your
previous tests)• run and watch all of the tests pass• refactor to remove duplication and increase
expressiveness• run the tests again, it should still pass otherwise fix it• repeat the steps above until you can't find any more tests
that drive writing new code
(re-used from http://c2.com/cgi/wiki?testdrivendevelopment – by david clark)
26
secu
rity
dri
ven
d
evelo
pm
en
t• think about what you want to do• think about how to security test it• write a small security test• write just enough code to fail the security test• run and watch the test fail• write just enough code to pass the security test (and pass
all your previous security tests)• run and watch all of the security tests pass • refactor to remove duplication and increase
expressiveness• run the tests again, you should still pass all security tests.• repeat the steps above until you can't find any more
security tests that drive writing new code
(re-used from http://c2.com/cgi/wiki?testdrivendevelopment – by david clark)
27
develo
pm
en
t te
am
• the development team consists of professionals who do the work of delivering a potentially releasable increment of “done” product at the end of each sprint. only members of the development team create the increment.
• development teams are structured and empowered by the organization to organize and manage their own work. the resulting synergy optimizes the development team’s overall efficiency and effectiveness.
• development teams have the following characteristics: • they are self-organizing. no one (not even the scrum master) tells the
development team how to turn product backlog into increments of potentially releasable functionality;
• development teams are cross-functional, with all of the skills as a team necessary to create a product increment;
• scrum recognizes no titles for development team members other than developer, regardless of the work being performed by the person; there are no exceptions to this rule;
• scrum recognizes no sub-teams in the development team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule; and,
• individual development team members may have specialized skills and areas of focus, but accountability belongs to the development team as a whole.
29
cad
en
ce &
patt
ern
pro
du
ct o
wn
er
develo
pm
en
t te
am
1 2 3 4 5
sprint planning: what scrum scrum scrum scrum
sprint planning: how
design, code & unit test design, code & unit test design, code & unit test design, code & unit test design, code & unit test
test & bug fix test & bug fix test & bug fix test & bug fix test & bug fix
production support production support production support production support production support
6 7 8 9 10scrum scrum scrum scrum scrum
backlog refinement meeting
spikesto research stories
backlog refinement meeting
estimate added or changed stories
prep sprint review
design, code & unit test design, code & unit test design, code & unit test design, code & unit test review
test & bug fix test & bug fix test & bug fix test & bug fix retrospective
production support production support production support production support production support
1 2 3 4 5
sprint planning: what scrum scrum scrum scrum
identify stories for next sprint
modeling, design, architecture
modeling, design, architecture
requirements meetings stakeholder meetings
assist development assist development assist development assist development assist development
update backlog update backlog accept stories accept stories accept storiesupdate backlog update backlog update backlog
6 7 8 9 10scrum scrum scrum scrum scrum
backlog refinement meeting
gui prototypes for next sprint
backlog refinement meeting
support estimating review
retrospective
assist development assist development assist development assist development updates to product backlog/ rankings based
on reviewaccept stories accept stories accept stories accept stories
update backlog update backlog update backlog update backlog
30
spri
nt
revie
w• attendees include the scrum team and key stakeholders
invited by the product owner; • the product owner explains what product backlog items
have been “done” and what has not been “done”; • the development team discusses what went well during
the sprint, and how problems were solved; • the development team demonstrates the work; • the product owner discusses the product backlog as it
stands• the entire group collaborates on what to do next, so that
the sprint review provides valuable input to subsequent sprint planning;
• …