Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why?...
-
Upload
willis-barrett -
Category
Documents
-
view
227 -
download
1
Transcript of Agile Process Models. Prescriptive models don’t work It is unrealistic to not have changes. Why?...
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
Time Resources Functionality
Time Resources
Agile
Prescriptive
FIXED
VARIABLE
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
Write a Story
(Customer)
Spike a Story
(Developer)
Estimate a story
(Developer)
Split a Story
(Customer)Sort stories by value
(Customer)
Declare velocity
(Developer)
Exploration Planning
“too big”
“don’t know how”
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