Extreme Programming--a “New” Process Model Extreme Programming-- a “New” Process Model

Review of Process Models System design—some popular process models Linear Sequential Model Prototyping Model RAD Model Incremental Model Spiral Model Concurrent Development Model Component-Based Development Formal Method Model problem  develop  integrate each step is carried out recursively until an appropriate level of detail is achieved Basic method:

Introduction to Extreme Programming

“12 Practices” of XP

Metaphor

Release Planning 2. release planning requirements are given in terms of "user stories" each "story" is a short (~ 1 index card) description of what the customer wants, in natural language requirements are prioritized by customer resources and risks are estimated by developer "planning game"--each increment is restricted to a "time box"; highest priority and highest risk user stories are in early time boxes; after each increment, replay the "planning game"

Testing 3. testing development is test-driven tests are written before code unit must run at 100% before going on acceptance tests written with customer; they act as "contract", measure progress

Pair Programming 4. pair programming two engineers, one task, one computer "driver" controls keyboard & mouse "navigator" watches, identifies defects, participates in brainstorming roles are rotated periodically

Refactoring 5. refactoring improve design of existing code, but don't change functionality relies on testing; no new errors can be introduced

Simple Design 6. simple design no big design up front "do the simplest thing that could possibly work" don't add features you won't need may use "CRC cards"

Collective Code Ownership 7. collective code ownership code belongs to project, not individual engineers may browse into and modify ANY class

Continuous Integration 8. continuous integration pair writes unit test cases & code pair tests code to 100% pair integrates pair runs ALL test cases to 100% pair moves on to next task

On-Site Customer 9. on-site customer clarifies stories, participates in critical decisions developers don't make assumptions no waiting for decisions face-to-face communication

Small Releases 10. small releases timeboxed as small as possible, but with "business value" get feedback early and often do planning game after each iteration

40-Hour Work Week hour work week burning midnight oil kills performance tired developers make more mistakes workforce is more content

Coding Standards 12. coding standards use coding conventions write intention-revealing code

“13th Practice” "13th practice": stand up meeting 15 minutes at start of each day stand up to keep meeting short each participant says --what they did yesterday --what they plan to do today --any obstacles they are facing pairs can be reformed based on meeting

Contrast with Waterfall Model example contrasts: "waterfall model” || XP planning: upfront || incremental control of project, "people" questions: centralized || distributed customer involvement: only for specification, reviews || ongoing risk analysis, scheduling: all at beginning || in increments code development: assigned sections || collective ownership testing: specific phase || ongoing and required to 100% project type: well-understood, static || new, dynamic