The analysis and design activities described in the Theme approach can be split up and molded to fit into whichever development process you are happiest using. Later, in Chapter 3, "The Theme Approach," we briefly outline how that might work. Fitting the Theme approach into processes such as the iterative and waterfall approaches is quite straightforward. Figuring out how to work them into the family of agile processes[7] deserves further discussion. In Chapter 3, we go into some of the processes in more detail. Here, however, we discuss analysis and design in the context of agile processes from a high-level point of view.
The use of Theme/UML in agile processes mirrors the relationship between standard UML and agile processes, which is a much larger question. After sifting through rhetoric from experts on both sides (UML is crucial versus UML is useless), we found words of wisdom that struck many chords with usMartin Fowler's paper entitled "Is Design Dead?"[8] which we highly recommend.
What we have taken from the "Is Design Dead?" article is that if you are the type of developer to find diagrams helpful, then you will continue to do so with agile processes, and if you are not, then you won't. In addition, it is especially important to recognize that diagrams can "actually cause harm" and therefore should be used judiciously. The use of diagrams has potential value from a number of perspectives: communication; as a means to explore a design before you start coding it; and documentation both ongoing and for handover situations. From a Theme approach perspective, we paraphrase or steal directly from "Is Design Dead?" in the following list of recommendations for managing both Theme/Doc and Theme/UML diagrams in an agile process environment:
|