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 toolsIndividuals and interactions over processes and tools Working software over comprehensive documentationWorking software over comprehensive documentation Customer collaboration over contract negotiationCustomer collaboration over contract negotiation Responding to change over following a planResponding to change over following a plan

The Agile approach Fix time and resources, not features Functionality TimeResourcesFunctionality TimeResources 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