|
||
|
|
|
|
||
This chapter continues the case study of a real-life project run at ESRI using Agile ICONIX. So far, we’ve created an early version of the project domain model, written a “first-pass” attempt at some use cases, and created a release plan from the use cases. We also broke down the use cases into estimable chunks of work so that we could plan and prioritize the work for the first release.
In this chapter, we’ll see the core modeling aspect of ICONIX Process kick into action. We’ll show how the use cases are turned into a concrete design over two very brief modeling iterations, followed by a coding iteration.
Release 1 was to be an exploratory release, examining the new server technology. So it made a lot of sense at this stage for the team members to get their hands dirty and just write some code to familiarize themselves with the new technology. Without the requisite familiarity with the technology they were using, it would be unrealistic to expect anyone to produce a really robust up-front design. Therefore, early prototyping is a key aspect of up-front design, to keep the design grounded in reality.
However, what the team also wanted to avoid was simply leaping in and producing something that was a million miles away from what the customer wanted. So, as the customer already had a pretty good idea of what he wanted from the new system, a little up-front design work was warranted.
Of course at this stage, the team already had a set of use cases and a domain model, so the behavioral requirements of the new system had been thought through. That’s a pretty good place to start, especially for a prototype.
As it embarked on the prototype, the team produced some sequence diagrams to describe the design at a slightly higher level than pure code. The team also revisited and refined the domain model. However, this being a prototype, the team skipped robustness analysis and also didn’t spend time creating a detailed class diagram.
The result was a design that would meet the needs of a prototype, but not a production system, as much of the team’s time was focused on getting an understanding of the underlying technology. To the team members’ credit, they still produced the goods, in the sense that the end product matched the initial set of requirements. However, as you’ll see in Chapter 7, the code and design review gave the team an opportunity to start release 2 (the first production release) from a clean design.
In this chapter, however, we chronicle release 1 exactly as it happened, because it provides a useful real-world indication of the issues that most teams will encounter during the early stages of a project. At this point, the team is prototyping, exploring the technology, and looking for a way to match up the problem with a suitable solution.
 |
Early prototyping in this context is a key agile concept that fits neatly into ICONIX Process: prove it with code[1.] as early in the project as possible.
The code doesn’t have to be “industrial grade” (or even just plain old production-worthy). The important thing is that the team writes some code as soon as possible. As many teams have discovered, this can have an almost miraculous effect on their understanding of both the problem domain and the optimal design path that they should follow. This “miraculous effect” isn’t the product of any particular development process or design methodology; it’s simply that when programmers start thinking in code, they automatically put their design hats on and quickly discover which solutions will work and which ones won’t. This is valuable early feedback, and it’s the reason early prototyping is so important in an up-front design process.
|
[1.]Scott W. Ambler, Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process (New York: John Wiley & Sons, 2002), p. 59.
|
||
|
|
|
|
||