Agile Process: Stories To Code: Allen Holub @allenholub

Agile Tools & Environment
Process:
Stories to
Code
Allen Holub
http://holub.com
allen@holub.com
@allenholub
http://holub.com/slides
© 2015 Allen I. Holub www.holub.com 1 © 2015 Allen I. Holub www.holub.com 2
You shouldn’t
have to beg to
get a tool that
helps you
work more
“It’s not the effectively.
equipment, man.”
Team has a
discretionary
budget for
tools, and is
Teams pick their trusted to
spend the
own tools money
appropriately.
? ✘
✘
Low-tech tools are best
✘
omnigroup.com
Some scanner app

The Environment is Important The Environment is Important
cenqua.com/pairon
Teams pick the epic!. Team Structure
Structure teams
around stories.
Red Team
UI Front Blue Team
Shopping
End Yellow Team
Cart
Infrastructure Green
Database
Team
Help Subsystem
Administration
Follows program structure.
Ordering
Jack-of-all-trades teams.
Follows probable story topics (e.g. Accounting
customer roles/categories). Customer
Service
Team Build/
Deployment Coach != Manage
Roles DBA Manage-
• The team’s in charge ment
Architect UI & Code Coach
Developers • No blame
• Removes obstacles to success.
Customer
Testers? • Runs interference.
(Product
Language Owner?)
Lawyer UI Design • Forces people not to work too hard
– “stealing from the future”
(Note
• Watches team interaction.
taker) Tech
UX – Developers may not break the process.
Writer
Librarian • Coordinates. Terminates pathological
iterations.
Work in related program areas

The Core Process
Share
skills
System
Owner/
System
Owner/
in com-
Architect Architect petence
area.
Community of interest Co-located team (~8)
Spotify.com: 30 teams in 3 cities; 250 people.

Waterfall
Agile is incremental
Gather Design Plan Build Test Release
Time
Two
Design
Months
Build
Agile You don’t know

what a program
Plan
should do until you
Gather Gather Gather Gather Gather
Design Design Design Design Design use it.
Build Build Build Build Build
Test Test Test Test
Release Release Release Release Release
Test
Requirements
Agile “requirements”
are user stories.
Requirements
The steps are change constantly,
identical,
but the order based on feedback
© 2015 Allen I. Holub www.holub.com
differs.
19 © 2015 Allen I. Holub
from the user.
www.holub.com 20
An Agile system is a
“Lifecycle” is a flawed notion
continuously evolving
prototype.
Agile Prototype Mockup
Development
tasks
run in
Parallel
Short Release Cycles
• Only two practices both improve productivity

and reduce bugs: (IEEE Software, Oct. ’03, pp 78-85)
• Design review. 
(NOT code review)
• Regular releases to 

users
– The shorter the cycle  
time, the greater the  
benefit.

Task (not time) based
Continuous Development
System is always working.
Team works at 100%.
Agile
Story Story Development Work on highest priority
Shop story, first.
Story
Release No Estimates, There is only
Story Deadlines, Quarterly
Goals
progress.
Periodically review and
Customer Feedback
re-prioritize stores.
No Project Managers
Teams manage
New versions (Incremental Releases) themselves.
The center of the

Agile universe!
Epics Tasks
Stories
“Stories” describe a customer

solving a problem.
Story Capsule form (traditional)
As a <role in the problem domain>

A task that has a useful outcome I want to <perform some task>
(as defined by a customer). so that <I achieve some useful outcome>
As a banking customer,
Updating a
✓
I want to withdraw some money from and
Logging in timesheet ATM
so that I don’t have to wait in line at the
bank.
Selecting an Option
Inverting it makes more

sense: Stories are Use-Case Scenarios
Registering for classes:

In order to <achieve something valuable> Happy path (class available)
a <role in the problem domain> Class is full, not required (wait listed)
needs to <perform some task> Class is full, required, I’m a senior.
• A way for the use

In order to not wait in line at the bank, a case to “play out”
customer, needs to withdraw some money • Fly-on-the-wall
from and ATM
narrative

I never go as a passenger; nor, though I am
something of a salt, do I ever go to sea as a
Commodore, or a Captain, or a Cook. I abandon
Stories Are... Stories are narratives
the glory and distinction of such offices to those
who like them. For my part, I abominate all
honorable respectable toils, trials, and
Testable  tribulations of every kind whatsoever. It is quite
Automatic tests can detect the success/end of the story.

as much as I can do to take care of myself, As a maniacal
without taking care of ships, barques, brigs,
Indicators of progress 
schooners, and what not. And as for going as captain, I need
cook, - though I confess there is considerable
Customers are willing to accept the story as a sign of glory in that, a cook being a sort of officer on to add a
progress toward their larger goal.
harpoon gun
ship-board - yet, somehow, I never fancied
broiling fowls; - though once broiled,
to my whale
judiciously buttered, and judgmatically salted
Bite-sized 
and peppered, there is no one who will speak
Completable within an iteration. Fits on a 4x6 card. more respectfully, not to say reverentially, of a
broiled fowl than I will. It is out of the boat so that I
Estimable 
The technical side of the team must be able to guess how
idolatrous dotings of the old Egyptians upon
broiled ibis and roasted river horse, that you see can catch the
much of the team's time the story will require. the mummies of those creatures in their huge
bake-houses the pyramids. white whale.
Nobody on the “Problem Statement”

planet wants to
fill out a survey What user-level Tech support customers are annoyed that they
“User” doesn’t problem does have to give the techs the same information
mean anything. this solve? How? over and over again. It would be better for
the techs to collect that data into a customer
As a user, I want to fill out a profile survey profile that’s passed from tech to tech as the
so that I can get personalized service, but problem moves through the support process.
this process shouldn’t degrade my user Since a problem may arise again, the profile
experience. should be permanent and made available to
How can it not? What kind of service? the tech who answers the phone the next
What are you doing with time the customer calls in. Since the profile is
Game-ification? Is
this survey? Throwing it fluid, any tech should be able to change it...
that possible?
© 2015 Allen I. Holub
out? No useful outcome!
www.holub.com 35 © 2015 Allen I. Holub www.holub.com 36
“Happy-path” story
The Problem Statement
establishes a System Creating a Profile (happy path)
Metaphor A first-time customer calls in with a problem. A tier-one tech
creates a new profile and fills it in with the customer’s contact
Tech-support department; information, including a phone number to call if the connection is
broken. The tech immediately files the profile for subsequent
calls, problems, profiles, customers, use, and then adds the nature of the problem along with identifying
techs. information for the hardware and its basic configuration (memory,
OS version, machine type, CPU type). These changes to the
• Conceptual framework for system profile are immediately reflected in the saved version.
– A Bank, HR Dept., Accounts Payable Dept.
• The customer’s mental model The tech solves the problem to the customer's satisfaction and
– NOT YOUR MENTAL MODEL! adds to the profile a description of what he did to the profile.
The Epic
Horizontal Splits: 4 small portions
©2015 Allen I. Holub. All rights reserved. http://holub.com 39 ©2015 Allen I. Holub. All rights reserved. http://holub.com 40
Slice 1: a meal of salad Slice 2: a meal of salad & fish
Slice 3: a meal of salad, fish, & veg Slice 4: a complete meal
Narrow the story “Tier-2” story
Contact Only: Handoff to tier 2
Just like the happy-path, but the customer hangs up after
the initial contact in order to collect additional information. Like the Happy-path story, except that the tier-one
We still create the profile with contact information, but the tech cannot solve the problem. The tier-1 tech
profile is otherwise empty. forwards that profile to the tier-2 tech as part of
Second Contact: the standard handoff. The tier-2 tech then
continues the conversation with the customer,
A customer who’s contacted us previously calls adding to, or modifying the profile as required. As
in with a problem. The tier-one tech fetches his
profile and adds any new information. This story before, the profile is immediately updated as the
is otherwise like the “happy path.” tier-2 tech modifies it.
Another example, The Problem Inputs Stories ≠ Feature Requests
Dear Customer Service People, What (stories) You need to know

I had an issue that I couldn’t what you’re doing
resolve, so I posted a question to the How (features) before you can know
list. But, some moderator (who either how to do it.
didn’t read or didn’t understand my Output
issue) came along and changed the Programmer tasks,
posting category to something that’s feature requests, UI
incorrect. I have no way to challenge specifications, etc., are
that change or to restore my original all about “how.”
(correct) category. As a consequence,
nobody’s answering my question.
Planning
When given Features
Story
Ask: What are you doing that requires that feature?
Release
Manage goals, not activities. Iteration Release

Release
Release
Traditional Release
Analysis Demo Release
Design
Most Important Story Release
Assess
Code Next Most Important
Test ~2 Weeks
Next Most Important
Demo Design/Code/Test‡
‡
Daily: 
Least Important Story - fluid design
Choose Plan* - standup 
- integration
Agile Story
*Assign Pairs
© 2015 Allen I. Holub www.holub.com © 2015 Allen I. Holub www.holub.com *Fix Story 52
Planning
Git reduces friction
Set up/groom story
board. What stories
Production
should be released Engineering
together?
Continuously
Release
Stories daily
Iteration
Start
15 min standup.
Plan this iteration’s
what am I doing?
work. Define
what’s blocking me?
implementation tasks.
½–2 hours.
Short Cycles Minimize

An Example GIT Flow Distraction Injection
“You don’t have to deliver

Developer
until next month, so why
Pull Merge don’t you work on X for a
Team
couple days?”
Integration/Test
20 days 2 days
=
100% 10%
Release
5 days 2 days
Periodically deploy this branch =
100% 40%
Design/Build
#NoEstimates
© 2015 Allen I. Holub www.holub.com 58

©2015 Allen I. Holub. All rights reserved. http://holub.com 57
Identify user goals

You can implement your
What is the user really trying to accomplish?
process perfectly, Knowing the goals dramatically effects the entire
program.
but of the architecture
Store checkout: leave the site
doesn't support Meeting Scheduler: not to go
volatility, you will fail.
© 2012. Allen I. Holub www.holub.com 60

Structure code Structure UI with
with Agile in mind! Agile in mind
Avoid high-fidelity
• Continuous change requires:
design tools
– Discipline
– Modularization Use liquid layouts
– S.O.L.I.D. principles Design to allows
– Design Patterns
new elements.
– Rigidly adhering to  
OO principles popups, etc.
– Agile Modeling  Don’t design

(Barely Good Enough)
monolithic pages
first.
Dev/Pair moves story to

task board and... Single team implements
complete story,
consulting outside
experts if necessary.
Time
FRONT
finally
appears.
Tasks short, to BACK
...adds all tasks required estimable.
to implement story front
Tasks are fluid. implementation
to back!
Multiple teams work
Develop by story,  • in the same UI
not by class/feature/page.  • on the same web page
Implement front to back.
• in the same database
• in the same epics
at the same time!

The underlying (code/
database/UI) architecture
Check in early, check in often.
must be able to stand up
to this process.
The lifecycle of a story Develop

Get a task card Avoid changing
Identify user goals/problems
Find a partner Change if story
Create/Modify Stories
Design
changes
Just-Enough Design (code/UI)
Develop acceptance tests  Write unit test with mocks
Run Merciless
test Refactoring
Test/ Customer 20 min.
Feedback/ Realize max. Run
Develop
Bugs Tech mock Acceptance Pass
Support and Run Test
Customer test Integrate
Release
Service
Did the
clown who
came up
with this
junk
actually use
it to do
anything?
http://holub.com/videos
Our guesses about the “right” interface are no

more correct than our guesses about the “right”
implementation.

DbC
Design an interface
based on a story
Pick a story
Develop a test Implement fragment of story

If no changes were that simulates
required, realize the story, Stub out implementation
the interface using using the (with mocks?)
~5 min.
TDD interface
Run Refactor
test 20 min.
Interfaces
Fix the problems you

find writing the client Realize mocks incrementally
code.

An object is defined by
what it does, not by
what it contains.
(responsibility principle)
Ask for help, not for Let’s watch it in action!

information (delegation)
You should be able to

replace the implementation
of a class without
impacting the clients.
(Holub replacement principle)
Actor Role


David Tennant ⇒ Actor • Model the role, CRC Card
not the actor.
Employee Clas
• Roles defined s
by
responsibilities Creates new time sheets as Timesheet
.
Outside: “the necessary and fills them Calendar
– E.g.
guy typing” Employees fill
out daily.
out time
Inside sheets. Fixes errors in timesheets (e.g.
Managers forgot to fill one in, yesterday)
approve them.
Hamlet ⇒ Role litie
s rs
• Actors can bi r ato
nsi lab
o
have multiple Re spo Col
roles.
The Dynamic Model is a Conversation

CRC Card Employee
1. Create CRC Cards. Creates new time sheets as Timesheet
Manager 2. Decide on a story.
necessary and fills them
out daily.
3. Assign roles to people Fixes errors in timesheets (e.g.

forgot to fill one in, yesterday)
Timesheet and hand them a CRC
Approves (or challenges) Time Sheets
for all Employees in their group. Accounting Dept
Submits approved time sheets to – The card is the

accounting class definition.
People are objects.
– People share cards
if several objects
of the same class
participate

4. Solve the problem by talking to other people: The Static Model
– Do only those things listed as responsibilities on
your CRC card. Employee
– Talk only to collaborators. Timesheet Manager

Creates new time sheets as
necessary and fills them Approves (or challenges) Time
– Do not give anybody any of the information that you out daily. Sheets for all Employees in their
Accounting
Dept.
use to do your work. Fixes errors in timesheets (e.g.
group.
Timesheet
5. The cards change as the exercise progresses.
Submits approved time sheets to
accounting
6. The dynamic model is the conversation.
Accounting Dept.
Employee Timesheet Creates paychecks for Timesheet
Tracks time spent by an employee based on time sheet. Employee
Creates new time sheets as Timesheet Accounting
necessary and fills them employee working on a specific Dept.
out daily. project. Debit’s projects for time
spent working
Fixes errors in timesheets (e.g.
90
© 2015 Allen I. Holub www.holub.com 89 © 2015 Allen I. Holub www.holub.com
The Static Model Dynamic model = Recording of the conversation.

Static model = The CRC cards.
In UML
The static model is driven

by the dynamic model—it
is not created first.
Classes are related only if two objects of that class

communicate in the dynamic model.
The set of “public” methods are the requests that the

participants make to each other.
91
© 2015 Allen I. Holub www.holub.com © 2015 Allen I. Holub www.holub.com 92

 
 
?
Allen Holub 
www.holub.com
allen@holub.com
Under the banner of AGILE,

FORWARD to a better tomorrow!
These slides ©2015, Allen I. Holub.

All rights reserved.
All images used in this presentation are either used with permission, fall under “fair use,” or are in the public
domain. If I’ve inadvertently used an image to which you own the rights, please contact me at allen@holub.com,
and I’ll either delete the image or acquire usage rights, depending on cost.

Agile Process: Stories To Code: Allen Holub @allenholub

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Agile Process: Stories To Code: Allen Holub @allenholub

Transféré par

Droits d'auteur :

Formats disponibles

Agile Tools & Environment

© 2015 Allen I. Holub www.holub.com 5 © 2015 Allen I. Holub www.holub.com 6

Some scanner app

© 2015 Allen I. Holub www.holub.com 7 © 2015 Allen I. Holub www.holub.com 8

© 2015 Allen I. Holub www.holub.com 9 © 2015 Allen I. Holub www.holub.com 10

Work in related program areas

Community of interest Co-located team (~8)

Spotify.com: 30 teams in 3 cities; 250 people.

© 2015 Allen I. Holub www.holub.com 17 © 2015 Allen I. Holub www.holub.com 18

Agile You don’t know

© 2015 Allen I. Holub www.holub.com 21 © 2015 Allen I. Holub www.holub.com 22

Short Release Cycles

• Only two practices both improve productivity

• Regular releases to

© 2015 Allen I. Holub www.holub.com 23 © 2015 Allen I. Holub www.holub.com 24

The center of the

“Stories” describe a customer

As a <role in the problem domain>

Inverting it makes more

Registering for classes:

• A way for the use

© 2014 Allen I. Holub www.holub.com 31 © 2015 Allen I. Holub www.holub.com 32

Automatic tests can detect the success/end of the story.

Nobody on the “Problem Statement”

Horizontal Splits: 4 small portions

Slice 3: a meal of salad, fish, & veg Slice 4: a complete meal

Another example, The Problem Inputs Stories ≠ Feature Requests

Dear Customer Service People, What (stories) You need to know

When given Features

© 2015 Allen I. Holub www.holub.com 49 © 2014 Allen I. Holub www.holub.com 50

Manage goals, not activities. Iteration Release

Analysis Demo Release

Short Cycles Minimize

“You don’t have to deliver

© 2015 Allen I. Holub www.holub.com 58

Identify user goals

© 2012. Allen I. Holub www.holub.com 60

– Agile Modeling Don’t design

Dev/Pair moves story to

at the same time!

The lifecycle of a story Develop

Our guesses about the “right” interface are no

© 2014 Allen I. Holub www.holub.com 71 © 2014 Allen I. Holub www.holub.com 72

Develop a test Implement fragment of story

Fix the problems you

© 2014 Allen I. Holub www.holub.com 75 © 2014 Allen I. Holub www.holub.com 76

Ask for help, not for Let’s watch it in action!

You should be able to

© 2014 Allen I. Holub www.holub.com 79 © 2014 Allen I. Holub www.holub.com 80

© 2014 Allen I. Holub www.holub.com 83 © 2014 Allen I. Holub www.holub.com 84

The Dynamic Model is a Conversation

3. Assign roles to people Fixes errors in timesheets (e.g.

Submits approved time sheets to – The card is the

© 2015 Allen I. Holub www.holub.com 87 © 2015 Allen I. Holub www.holub.com 88

– Talk only to collaborators. Timesheet Manager

6. The dynamic model is the conversation.

© 2015 Allen I. Holub www.holub.com 89 © 2015 Allen I. Holub www.holub.com

The Static Model Dynamic model = Recording of the conversation.

The static model is driven

Classes are related only if two objects of that class

The set of “public” methods are the requests that the

© 2015 Allen I. Holub www.holub.com © 2015 Allen I. Holub www.holub.com 92

Under the banner of AGILE,

• Regular releases to 

– Agile Modeling  Don’t design