Flylib.com

Books Software

 
 
 

Iterative Development

Iterative Development

Iterative development is an approach to building software (or anything) in which the overall lifecycle is composed of several iterations in sequence. Each iteration is a self-contained mini-project composed of activities such as requirements analysis, design, programming, and test. The goal for the end of an iteration is an iteration release , a stable, integrated and tested partially complete system. To be clear: All the software across all the teams is integrated into a release each iteration. Most iteration releases are internal , a baseline primarily for the benefit of the development team—they are not released externally. The final iteration release is the complete product, released to the market or clients . See Figure 2.1.

Figure 2.1. iterative and incremental development

graphics/02fig01.jpg

iterative planning tips

Although an iteration can in theory be only for clean-up or performance tuning, usually the partial system grows incrementally with new features, iteration by iteration; in other words, incremental development . The concept of growing a system via iterations has been called iterative and incremental development ( IID ), although simply "iterative development" is common. Some older process literature [Wong84] used the term "incremental development" to mean a combination of frozen up-front specifications followed by iterative development of the features, but there is no widespread agreement on usage. In this era, most development methods are IID methods . And, IID is at the core of all the agile methods, including Scrum and XP.

Most projects have at least three iterations before a final public release; I've seen a two-year Valtech project composed of close to 20 iterations averaging around four weeks each, and I know of at least one long project with 45 iterations.

In modern iterative methods, the recommended length of one iteration is between one and six weeks.

Each iteration includes production-quality programming, not just requirements analysis, for example. And the software resulting from each iteration is not a prototype or proof of concept, but a subset of the final system.

More broadly, viewing an iteration as a self-contained mini-project, activities in many disciplines (requirements analysis, testing, and so on) occur within an iteration (see Figure 2.2).

Figure 2.2. disciplines across iterations

graphics/02fig02.jpg

Risk-Driven and Client-Driven Iterative Planning

What to do in the next three-week iteration? IID methods promote a combination of risk-driven and client-driven [1] priorities. Risk-driven iterative development chooses the riskiest, most difficult elements for the early iterations. For example, maybe the client says "I want the Web pages to be green and the system to handle 5,000 simultaneous transactions." Green can wait. In this way, the highest risks are surfaced and mitigated early rather than late. Risk is a broad concept—maybe you are making a new 3D modeling tool and market research shows that what will capture market interest is a novel , much easier user interface metaphor. The high risk is not getting the UI right.

[1] Throughout this book, client or customer could mean a proxy, such as a marketing or product manager for a consumer software product, true end-users for an internal application, etc.

risk-driven

ranking risks

first iteration

use cases and iteration planning

Client-driven iterative development implies that the choice of features for the next iteration comes from the client—whatever they perceive as the highest business value to them. In this way, the client steers the project, iteration by iteration, requesting the features that they currently think are most valuable . Note that the customer adaptively plans the choice for the next iteration, shortly before it starts, based on their latest insight, rather than speculatively at the start of the project. The customer has ongoing control and choice, as fresh information arises.

adaptive and client-driven planning

Apply both schemes. Clients do not always appreciate what is technically hard or risky. Developers do not always appreciate what has high business value.

mixing and ranking iteration goals