Agile http://www.flickr.com/photos/tropicaliving/3672347622/sizes/o/

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

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

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.

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

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

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.

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)

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.

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?)

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

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

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

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

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

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

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

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

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)

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

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 <Scott.Fleming@memphis.edu> 2011.