Does the "Cost of Fixing Errors" Curve Invalidate XP?
If this curve is still valid, does this mean XP is invalid? I argue that it is not. Several of the XP practices
Thus, XP attacks the roots of the high cost of fixing errors (with good specifications, good design, good implementation, and fast feedback). Furthermore, by using very short cycle times, the cost is never allowed to rise very high.
Note that, with the exception of the very short cycle times and pair programming (which in XP
Although errors are most costly to fix when found in later phases, each later phase is more likely to find errors in previous phases. This is because each phase produces a more concrete, more
Iterative Versus Incremental
The well-known "waterfall" method is rarely used, even by those who claim (or are forced) to use it. Most development
Now let's see how different types of methods use iterations and
Analyze, design, code, integrate, test—done! No iterations, no increments, no feedback; everything works the first time.
Classic RUP-Like Process
Analyze until 70-80% done. Start the design phase, but keep updating the analysis with any feedback you receive. Design until 70-80% done. Start the coding phase, but keep improving with feedback. And so on for the other phases.
This is an iterative process—feedback is used to improve the work done. The process is not incremental, except in the coding and integration phases, where some
Incremental Architecture-Driven Process
Analyze the application until 70-80% done. Design the application so that the architecture and high-risk elements are relatively complete. Define functional groups. Refine the analysis and design as the project progresses.
For each functional group, a detailed analysis, a detailed design, coding, integration, and testing are done. Each increment is handled like a small RUP-like project, with iterations to improve the output. When the functional
We have an iterative first step, which looks at the whole application. The application is then delivered incrementally, with each increment developed using an iterative process.
Gather an initial set of stories from the customers (high-level analysis). Define a metaphor (high-level analysis and design).
For each release, perform the planning game to allocate stories. For each story, define acceptance tests (analyze), write unit tests (design), code, refactor, integrate, test, and repeat frequently (iterate) until done.
The basic process is incremental on the level of releases and stories. Within those increments, the process iterates