1. Agile

2. A catalog of some processes
Waterfall
Traditional
With prototyping
Spiral
Agile
Dynamic Systems Development Method (DSDM)
Scrum
Crystal
eXtreme Programming (XP)

3. Contrasting processes
Waterfall
Spiral
Agile
Emphasizes:
Simplicity
Traceability
-Risk management
-Exploring alternatives
-Flexibility
-Immediacy
Weakness:
Requirement/design mistakes can be costly
Exploring alternatives can be costly
Continual rework can be costly
Style:
-Highly controlled
-High ceremony
-Moderately controlled
-Moderate ceremony
-Rapid & organic
-Low ceremony
Some definitions
“traceability”: relationships between requirements and system elements are documented
“immediacy”: getting some sort of working system to the customer as fast as possible
“rework”: redesigning the architecture and/or refactoring the program code
“controlled”: conformance to process is highly valued, even if it slows a project down
“ceremony”: how much analysis, documentation, and planning is involved

4. Choosing a process
Waterfall is often a good choice for small systems whose requirements can be fully understood before any design or coding.
Spiral is often a good choice for larger systems with vague requirements and many alternatives for designing and coding.
Agile is often a good choice for systems where you can rapidly create something small but useful, and then expand from there.

5. 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

6. Agile processes Evaluate & control risk
Prioritize requirements and plan
Customer provides short requirements
Write/run/modify unit tests
Operation
Implement
System and acceptance tests

7. Iterations Purpose Timing Grouping Sub-dividing
Iterative development gives you a few “oh drat”s instead of one big OMG at the end.
Timing
Scrum: 1 month (called a “sprint”)
XP: 1−2 weeks
Grouping
Iterations can be grouped into releases… not every iteration necessarily results in a new product release
Sub-dividing
Each iteration can have “micro-iterations” inside of it, where your team tries to complete some stories and communicates progress back to the customer, potentially refining the iteration’s goals.

8. Looking at some specific agile processes
DSDM - Dynamic Systems Development Method
(briefly, as a point of comparison) XP
(in more detail, since this is what you’ll be using for the next few weeks)

9. Principles of DSDM Active user involvement is imperative.
The team must be empowered to make decisions.
Fitness for business purpose is the essential criterion for acceptance of deliverables.
Requirements are specified at a high level.
The focus is on frequent delivery of products.
Iterative and incremental development is necessary to converge on a solution.
All changes during development are reversible.
Testing is integrated throughout the life cycle.
Collaboration and cooperation is essential.

10. Some key practices of DSDM
Ambassador Users & Facilitated Workshops
Users on-call & users en-masse (respectively)
Stages of iterations:
Pre-project exploratory phase (kick around ideas)
Feasibility study (explore if ideas are do-able)
Business study (explore if ideas are worth doing)
Model, design, implement (a “timebox” of work)
Post-project phase (what went well, what didn’t?)

11. Principles of XP
Communication – it is good to talk with customer and between developers
Simplicity – keep it simple and grow the system and models when required
Feedback – let users provide feedback early and often
Courage – speak the truth, with respect

12. Practices of XP Whole team Test-driven development Metaphor
The planning game
Simple design
Small releases
Customer tests
Pair programming
Test-driven development
Design improvement
Collective code ownership
Continuous integration
Sustainable pace
Coding standards

13. XP Practices: Role of customer
Whole team
The customer is part of the team
Customer tests
The customer participates in testing

14. XP Practices: Role of realism
The planning game
Be realistic about meeting customer needs
Small releases
Meet customer needs in small increments
Sustainable pace
No all-nighters, no superheroes

15. XP Practices: Role of design
Simple design
Simple models, simple architecture, simple code
Design improvement
Refactor as needed
Metaphor
Design around a coherent idea
Continuous integration
Regularly check to see if the system is on track

16. XP Practices: Role of teamwork
Pair programming
All code is written with a “co-pilot”
Test-driven development
Write tests first, then write code
Collective code ownership
A big ego… one that includes the team!
Coding standards
Pick a format, use it, and move on

17. XP process in detail Evaluate & control risk Divide stories into tasks
Do “spike” for unfamiliar tasks
Estimate effort of tasks&stories
Prioritize requirements and plan
Customer provides short requirements
Customer selects stories
Collect user stories
Allocate work among team
Write/run/modify unit tests
Operation
Write unit tests
Customer gets to use system
Implement
Customer tests system
Write and refactor code
System and acceptance tests

18. Concerns about XP Constant refactoring can be expensive
XP can degrade into a hacker’s paradise
Pair programming can take extra effort
Programmers don’t always specialize
Knowledge lives in heads, not on paper
XP is not very standardized

19. Lessons from DSDM & XP Learn from… Design based on…
Users (DSDM)
Customers (XP)
Design based on…
Business value (DSDM)
Customer direction (XP)
Requirements should be…
High-level (DSDM)
Succinct (XP)
Engineers must demonstrate…
Empowerment (DSDM)
Courage (XP)

20. What’s next for you? HW5 due before next class
Vote for your favorite vision by midnight Monday
I’ll send an when voting starts

21. Copyright (c) Christopher Scaffidi 2009 All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
Neither the name of Oregon State University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Modified by Scott D. Fleming 2011.