Академический Документы
Профессиональный Документы
Культура Документы
Software Development
An Agile Toolkit
Mary Poppendieck
mary@poppendieck.com
www.poppendieck.com
Taiichi Ohno
The Toyota
Production
System
Approach to Production
Build only what is needed
(1912-1990)
Stop if something goes wrong
Eliminate anything which does not add value
Philosophy of Work
Respect for Workers
Full utilization of workers’ capabilities
Entrust workers with responsibility & authority
Agile
T im e
Received Knowledge: Received Knowledge:
Die Change is Expensive Code Change is Expensive
Don’t Change Dies Freeze Design Before Code
Taiichi Ohno The Agile Imperative
Economics Requires Many Economics Requires Frequent
Dies Per Stamping Machine Change In Evolving Domains
One Minute Die Change Last Responsible Moment
March, 2003 Copyrignt©2003 Poppendieck.LLC 3
Concurrent Engineering
1981 – GM Starts the G-10 Project
1988 – Buick Regal 2 Years Late
1989 – Olds Cutlass & Pontiac Grand Prix
1986 – Honda Starts the New Accord Project
1989 – Introduced as 1990 model
1990’s – Largest-selling model in North America
A New Mental Model
Instead of
Haste Makes Waste
Quality Costs More
We know
Delay Makes Waste
Quality Saves
Time
How do we support it?
Never
Often
45%
13%
Always
7%
Rarely or Never
Standish Group Study Reported at XP2002 by Jim Johnson, Chairman Used: 64%
Bottlenecks:
Total Time: ~55 weeks
Approvals
Work Time ~17.6 weeks
Sign Offs
1/3rd of the time
Design Review
Wait Time ~37 Weeks
Testing
2/3rds of the time
Deployment
Set Speed
Comparison Throttle
60 mph
Speed
Sensor
Cruise Control
Current
Customer Business System
Needs
Current
Developer Design Comparison Code
Intent
Current
System
Capability
Software Development
Recommended by software
engineering thoughtleaders,
A simplistic but associated with numerous
inferior idea, similar to successful large projects &
medicine’s “four humors”.* recommended by standards
boards.*
* Craig Larman, “A History of Iterative and Incremental Development”, IEEE Computer, June 2003
Payback
Profit
Cost
Breakeven
Software by Number by Mark
Denne and Jane Cleland-Huang
Self-Funding
Time
Increase Feedback !
Customer Feedback to Team
Team Feedback to Management
Product Feedback to Team
Upstream-Downstream Feedback
Custom software
Becomes brittle with age
Architecture is not expected to change
A Minnesota Wedding ?
August 10th
50% Chance of Rain
65-95 ºF
Invitations must
be sent in June
Login New User Get Password
Afal;jdsa;fuwe Afal;jdsa;fuwe Story XX
Afal;jdsa;fuwe Afal;jdsa;fuwe
Login New User
Story YY Afal;jdsa;fuwe
Story XX Login New User
Login New User Story YY
Get Password Story YY
Afal;jdsa;fuwe Login New User
Afal;jdsa;fuwe Login New User
Get Password
Story XX Get Password
Daily Meetings
Afal;jdsa;fuwe
Login New User Afal;jdsa;fuwe
Afal;jdsa;fuwe
Story YY
Login New User
Get Password Story XX
Afal;jdsa;fuwe Login New User
Afal;jdsa;fuwe
Status
Commitment
Need
700 600
600 500
500
400
400
300
300
200
200
100 100
0 0
jan feb mar apr may jun jul aug sep oct nov dec jan feb mar apr may jun jul aug sep oct nov dec
250
200
Tests Written
Acceptance Tests
Tests Passing
150
100
50
0
1 2 3 4 5 6 7 8 9 10
Iteration
Cycle Time
Average End-to-End Process Time
From Entering The Terminal
To Arriving at the Gate
Time Spent in a Queue is Wasted Time
The Goal: Reduce Cycle Time
4. Reduce Utilization
You Don’t Load Servers to 90%
5. Eliminate Bottlenecks
Everyone Pitches In Wherever They Are Needed
5
March, 2003 Copyrignt©2003 Poppendieck.LLC 31
Queueing Theory Lessons
1. Small Batches Move Faster
2. Slack Resources Decrease Cycle Time
40
Large Batches
Cycle Time (hours)
35
Medium Batches
30 Small Batches
25
20
15
10
0
10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Deliver Fast
Examples
Gearworks
Your experience
Do
• Write tests before code
• Eliminate duplication
• Refactor mercilessly
• Leave code better than
you found it
• Only write tests for
contracts
• Write tests for bugs
(before fixing them)
• Don’t be afraid to throw
away code
• Use local databases
every 24
hours
New functionality
is demonstrated
at end of sprint
Product Backlog:
Prioritized product features desired by the customer
Deliver Fast
Examples
MinnesotaSecretary of State UCC System
Your examples
Wi
th
What needs to be done?
ou
tR
Communication
efa
How do we build it?
ct
or
ing
Time How do we support it?
System
Current
Customer Business
Needs
Comparison Code
Current
Developer Design Current
Intent Capability
Test-Driven Development
March, 2003 Copyrignt©2003 Poppendieck.LLC 40
Test-Driven Development
Requirements Feedback System
Under
Current Test
Customer Business
Needs
Comparison Code
Current Current
Developer Design System
Intent Capability
Refactoring Maintenance
Usability
z Never automated!
Etc.
Wi
Self-documenting code
th
ou
3. Suitable for Use
tR
efa
Usability
ct
or
Performance
ing
4. No Repetition
NO REPITITION!
5. No Extra Features
No Code Before its Time
No Code After its Time
Chief Engineer
Understands the Target Customer
Writes the Product Concept
Brings Customer Vision to Technical Workers
Makes Key Technical Tradeoff Decisions
Master Developer
Also Known As:
Architect
Systems Engineer
Chief Programmer
March, 2003 Copyrignt©2003 Poppendieck.LLC 48
Communities of Expertise
Matrix Functional Managers
Value Adding Teams Teacher
Communities of Expertise Hire
Mentor
Set Standards
Communities of Expertise
Establish Communities
Value Adding Teams
Team Leaders
Conductor
Assemble the Team
Clarify the Purpose
Make Work Self Organizing
See to Individual Motivation
A: I can meet
B: No, 3:00 10:00 - 1:00 or B: Let’s meet
is bad. 9:00? 3:00 - 5:00. 12:00 - 1:00.
A: My best time
Can you make any
is 10:00. Can you ? of these times?
make it?
A: Uh, already booked.
Can you meet at 3:00?
You already understand this!
B: No, I can’t.
How about 2:00?
based on dissertation by Durward K. Sobek, II, 1997
Marketing
Suspension
Design Analyze & Body Alternatives
Body Structural
Solution Critique Capability Accept
Chassis able
Modify
Manufacturing Styling Alternatives
Styling
→ Vehicle sketches
Communicate
Constraints, → Clay models
Not Solutions
→ Design structure plans
Gradually
Milestones
→ First prototype
Narrow the
Tolerances
→ Second prototype
→ Production trials
→ Release to production
March, 2003 Copyrignt©2003 Poppendieck.LLC 52
Software Examples
Medical Device Software
Choosing Technology
Use Cases
Plot, Dialog
Interfaces
Action
Understand Constraints
-abilities
Documents Face-to-Face
Richness of Information Media (high bandwidth)
e-mail
Batch Fragmented
Transmission Frequency of Information Transmission (piece-by-piece)
(one-shot)
Bilateral
Unilateral Direction of Communication (feedback)
Or
n ga
a tio ni
za
r m tio
In
fo Do They Believe They na
l En
Make The Decisions? e rg
y
March, 2003 Copyrignt©2003 Poppendieck.LLC 63
Team Commitment
1. Small Team
2. Clear Mission
3. Short Timeframe
4. Staffed with the necessary skills
z Technology Expertise
z Domain Experience
5. Enough information to determine feasibility
6. Assured of getting needed resources
7. Freedom to make decisions
8. Basic environment for good programming
z Coding Standards
z Version Control Tool
z Automated Build Process
z Automated Testing
March, 2003 Copyrignt©2003 Poppendieck.LLC 64
Bring people together
Present recommendations
Bottler
Retail Home
4 days store Retail Store
Warehouse 3 days store
1 min process 2 days store
3 days store 5 min process
5 weeks store
319 days
3 hours (0.04%) processing time
Everyone Looking Out For Their Own Interests
March, 2003 Copyrignt©2003 Poppendieck.LLC 67
Optimize the Economic Chain
In every single case, the Keiretsu (K-ret-soo), that is,
the integration into one management system of
enterprises that are linked economically, has given a
cost advantage of at least 25% and more often 30%.*