Agile software process models

advertisement
Agile Process Models
Prescriptive models don’t work
• It is unrealistic to not have changes. Why?
• The Agile Manifesto:
• Individuals and interactions over processes
and tools
• Working software over comprehensive
documentation
• Customer collaboration over contract
negotiation
• Responding to change over following a plan
The Agile approach
• Fix time and resources, not features
Functionality
FIXED
Time
Resources
Agile
Prescriptive
Time
Resources
VARIABLE
Functionality
The Agile approach
• Effective and rapid response to change
• Effective communication among all
stakeholders
• On-site customer
• Rapid, incremental delivery of software
The Agile process
• Driven by customer descriptions of what is
desired
• These are translated into short-lived plans
• Development is iterative
• Adapts as changes occur
• Little to no documentation
– Why bother documenting what is likely to change?
– Customer is on-site
Popular Agile Processes
• eXtreme Programming
• Scrum
eXtreme Programming
• Very programmer-focused; take the good
practices and do only those!
– Simplicity
– Communication
– Feedback
– Courage
XP practices: Planning
• Begins with customer-defined user stories
• Agile team assigns each story a cost
• Stories are grouped into deliverable
increments
• Commitment is made on delivery
date
• After the first increment this project velocity is
used to define future increments
XP practices: planning game
Split a Story
(Customer)
Write a Story
(Customer)
Sort stories by
value
(Customer)
“too big”
Estimate a
story
Declare velocity
(Developer)
(Developer)
“don’t know how”
Spike a Story
(Developer)
Exploration
Planning
XP practices: user stories
• Watered-down version of use cases
• Written by customers, estimated by
developers
• Often on post-it notes
• Replaces large documents
XP practices: on-site customer
More XP practices
• Small releases
• Continuous integration
– Implies refactoring
• System metaphor
• Sustainable pace
– 40 hours max/week
XP practices: Pair programming
•
•
•
•
One developer writes, the other watches
Switch every two hours
Results in collective ownership
Need a coding standard
XP practices: Test Driven Development
• Write automated unit tests first (will all fail)
• Only write code until all tests pass
– Stop there; no extra features!
When not to use XP
• Customer requires documentation
• Teams larger than 15 people
• When you can’t get immediate feedback
(embedded systems)
• When it’s impossible to get people in the
same room
Scrum
• Sprints, backlog, daily scrum meeting
Criticisms of Agile approaches
• Lack of scalability
• Relies on mature team
• May result in inefficient designs due to
incrementality
• Potentially expensive
– On-site customer
– Rework
– Inefficiency
Download