Resilient Agile
Design Driven Testing Meets Test Driven Development
Doug Rosenberg
Copyright © 2016 ICONIX
a little background…
• A couple of years ago I hijacked CS577 for a few weeks and
handed 47 use cases to 47 students for homework, and got a
location based advertising system designed and prototyped.
We called it “massively parallel use case modeling”
• This talk was originally supposed to be about an experiment in
CS577 that’s evaluating massively parallel use case modeling
vs. architected agile
• But then…one of my clients (thanks HMM!) had an idea for a
better interface to scrum…so I refactored my slides
• So the CS577 experiment is now Part II of this presentation…
Copyright © 2016 ICONIX
why “Resilient Agile”?
• Quote from a friend: “agile is great if you do it right, but most
places do it wrong”
• (what people hear: “AGILE IS GREAT if you do it right but most places do it wrong”)
• When agile is done wrong (a lot of the time, shhhhhh)…
– Rainy day scenarios are not anticipated
– Unit tests are skipped because of time pressure
– Pieces don’t fit into the big picture
• These failure modes result in “brittle software”
• Goal: be agile but have designs that are more resilient
Copyright © 2016 ICONIX
underplanning and overplanning are
both expensive
• Most flavors of agile are on the underplanning side of the curve
• This shouldn’t be a surprise since the agile manifesto devalues planning
• Underplanned software tends to break easily (is not resilient)
Copyright © 2016 ICONIX
scrum is often mistaken for an engineering process
but scrum is a management process
• Backlog and task management has little to do with engineering
almost anything can go into a user story
(requirements, use cases, data descriptions, screen layouts, lunch requests…)
Copyright © 2016 ICONIX
a few agilescrum failure modes
•
•
•
•
•
(thanks to Mark Collins-Cope for this list)
Fixed deadline, ill-defined scope
Piecemeal user stories that don’t create a logical set
Start the sprint – spend half of it trying to work out what to do
Forget bug fix time
Copyright © 2016 ICONIX
TDD is the engineering process that
usually goes with scrum
• TDD is focused on code and unit test (assembly line)
• TDD is heavily timebox driven
• Timeboxing inhibits thorough exploration of requirements
and rainy day scenarios (aka Analysis Deficit Disorder)
• Inadequate time for “big picture” analysis
• Unit tests get skipped when sprint deadline arrives
“as a programmer, I want to eat a
twinkie every time a unit test passes”
Copyright © 2016 ICONIX
the video game generation loves making unit tests light up green
Google it:
http://www.theregister.co.uk/2007/04/25/unit_test_code_coverage/
But beware of a false sense of security from over-reliance on unit testing:
•
•
•
Unit tests don’t help you with stuff that you forgot about.
Unit tests that get skipped because of time pressure don’t help you either.
Unit tests also don’t guarantee that the system will integrate properly.
Copyright © 2016 ICONIX
architected agile is better than un-architected agile, but
it can still devolve into a hackathon
Now if we could only get architecture to fit into a 2 week sprint…
Copyright © 2016 ICONIX
as an architect I’d like the user stories in the
backlog to fit together into the big picture
•
•
•
As a QA lead, I’d like it
if rainy day scenarios
didn’t get ignored due
to timeboxing
As a scrum master I’d
like it if unit testing
never got skipped due
to timeboxing
As a developer I’d like
it if all the user stories
were of a similar size
and complexity
Copyright © 2016 ICONIX
modeling addresses the big picture
and should not be timeboxed
•
•
•
•
•
User stories are not the same as use cases!
It’s possible for a user story to be a use case
but more typically they are closer to
requirements (some capability the user wants).
Model the problem domain
Elicit requirements
Draw use case diagrams
Modeling proceeds one use case at a time (perhaps in parellel)
For each use case:
–
–
–
–
–
–
–
Write sunny-day/rainy-day descriptions
Do a Model View Controller (MVC) decomposition
Verify that all requirements are satisfied
Generate “controller tests”
Populate test scenarios
Transform test cases into unit test classes
Add the skeleton unit test code to the backlog
Copyright © 2016 ICONIX
Automated in the
ICONIX/DDT add-in for
Enterprise Architect
design driven testing can generate skeleton unit tests
that are then fed directly into the scrum backlog
How are these tests generated?
Copyright © 2016 ICONIX
acceptance tests go to QA
Resilience comes from full coverage testing of
rainy day scenarios and requirements
Copyright © 2016 ICONIX
controller tests go to the backlog
Resilience comes from not skipping the exception tests
backlog
Copyright © 2016 ICONIX
hotel mapping example illustrates controller tests
and the importance of acceptance testing
“As a frequent traveler I’d like a nice
hotel on the beach in Bora Bora”
Copyright © 2016 ICONIX
check for valid dates on a hotel reservation
MVC decomposition of a use case:
V
C
M
“as a user I need to be prevented from entering invalid dates”
Copyright © 2016 ICONIX
multiple test scenarios are defined for each controller
•
•
•
I can’t check in yesterday
I can’t check out before I check in
I can’t check in and out on the same day
Copyright © 2016 ICONIX
auto-generate unit test skeleton code
If we put these unit test instructions
directly into the backlog, the developers
will know exactly what to code
Copyright © 2016 ICONIX
about that false sense of security from unit testing
•
Advanced Search decluttered the
map by removing hotels that did
not meet Filter criteria.
•
We tried a Requirement Test and
found that filtering by amenities
removed too many hotels from
the map.
•
Investigation showed that using a
default check-in date of
“tomorrow” was the cause,
because many hotels are sold out
“tomorrow”.
•
We fixed the problem by
initializing the screen to use
MM/DD/YY and only checking
the date field if it had been
edited.
•
This class of bug is invisible to
unit testing.
Copyright © 2016 ICONIX
the skeleton unit test goes into the backlog
•
•
•
•
user stories are atomic, testable, unambiguous, satisfy requirements and fit into the
bigger picture
scrum team writes the tests, writes the code, makes the tests pass
big picture work is not timeboxed – there’s time to think!!!
we get better acceptance tests and more complete unit tests – more resilient software
Copyright © 2016 ICONIX
summary (part I): detente
•
•
•
•
Modeling and scrum/TDD can coexist
Big picture issues addressed by modeling (not timeboxed)
Code and unit test done in the scrum room (timeboxed)
Use Case -> MVC -> controller tests -> backlog is the path
Copyright © 2016 ICONIX
part II – the CS577 experiment
The theory is interesting but does it work in practice?
Can we teach it at the university level?
How does it compare to regular (architected) agile?
Copyright © 2016 ICONIX
Resilient Agile – the CS577 experiment
PicShare mobile app
• CS577 gives USC students experience on real world
software projects
• I hijacked CS577B a couple of years ago and had students
design a location based advertising system for homework
– presented Massively Parallel Use Case Modeling at ARR in 2014
• 2015 - What if we could put 2 teams of students on the
same project, one using architected agile and one using
massively parallel use case modeling?
– We did not put unit tests into a scrum backlog as part of this
experiment, this is a new development, but the results are still
interesting
– Several other things need to change if we ever repeat this
experiment, there were some issues
Copyright © 2016 ICONIX
establish a common vocabulary
PicShare: users can upload photos to public or private events, download and view them…
Copyright © 2016 ICONIX
see the big picture - identify use cases
Analysis, design, code, and test proceeds one use case at a time…
Copyright © 2016 ICONIX
group related use cases together
You might choose to develop a related set of use cases in a single sprint
Copyright © 2016 ICONIX
storyboard screens, write use cases
Rainy-day behavior is anticipated from the beginning
Copyright © 2016 ICONIX
do an MVC decomposition of the use case and
verify that requirements are satisfied
MVC decomposition is the key to disambiguating use cases
V
Copyright © 2016 ICONIX
C
M
detailed OOD considers sunny and rainy day scenarios
V
M
C
Copyright © 2016 ICONIX
integrate designs for all use cases
Copyright © 2016 ICONIX
review the designs carefully
Copyright © 2016 ICONIX
write the code and test it
Copyright © 2016 ICONIX
or…(more agile!!!) generate controller
tests and start coding and testing
new, scrum-friendly
approach: everything
downstream from here can
be done in the scrum room.
Just generate controller
tests and follow TDD
Copyright © 2016 ICONIX
results of massively parallel use case modeling
Copyright © 2016 ICONIX
coding proceeds one use case at a time
Copyright © 2016 ICONIX
each developer codes the use cases they modeled
Copyright © 2016 ICONIX
dependencies have been anticipated during design
Copyright © 2016 ICONIX
rainy day scenarios have been
anticipated during design
Copyright © 2016 ICONIX
turnover in project team is manageable
because use cases are documented
Copyright © 2016 ICONIX
result should be a resilient app
Copyright © 2016 ICONIX
testing covers off-nominal cases
Copyright © 2016 ICONIX
test cases follow the use cases
Copyright © 2016 ICONIX
sunny-day/rainy-day analysis guides testing
Copyright © 2016 ICONIX
emphasis on acceptance testing
Copyright © 2016 ICONIX
40 days to code a mobile app
Copyright © 2016 ICONIX
50 days to test the mobile app
Copyright © 2016 ICONIX
90 days to code and test a mobile app – not bad
but wait…these are not fulltime employees
Copyright © 2016 ICONIX
summary (part II)
The theory is interesting but does it work in practice?
Yes, it works. Consistently. This is a repeatable
engineering process.
Can we teach it at the university level?
Yes. I gave one overview lecture to CS577A and spent
approximately 30 hours mentoring this team last
semester.
No mentoring this semester.
How does it compare to regular (architected) agile?
To be honest, I don’t have visibility…but…however well
the architected agile team may or may not be doing,
shouldn’t all students be learning these techniques?
Copyright © 2016 ICONIX
Thanks for your attention!
As a conference attendee, I’d like a Twinkie right about now…
Copyright © 2016 ICONIX