February 27, 2002
URL:http://www.drdobbs.com/how-much-proof-do-you-need/184415789
Adopting and then tailoring a software process to meet your team's needs is an important and difficult decision, one that is critical to your project's success. You face a myriad of choices, ranging from prescriptive methods such as the Rational Unified Process (RUP) and the OPEN process to agile software methods such as Extreme Programming (XP), SCRUM and Dynamic System Development Methodology (DSDM). A wealth of material has been written about these methodologies, but how can you tell whether a methodology will work for you? In particular, how do you determine whether an agile development methodology will work in your environment? If you spend any time online reading process-oriented resources, such as the XP mailing list hosted by Yahoo! groups or the comp.object newsgroup, you've probably noticed the common refrain of the detractors of agile methodologies: "Where's the proof?" On the surface, this seems to be a reasonable question, because many developers want assurances that these new approaches do, in fact, work. However, I feel that these people are barking up the wrong tree for several reasons: The proof-hunters should remember that, first and foremost, agile software development methodologies are new: 1. SCRUM and DSDM, defined in the mid-1990s, are among the oldest agile methods. 2. XP, arguably the most popular of the agile processes, was first described in the late 1990s as a collection of process/organizational patterns, and in 2000 was published as a book. 3. The Agile Alliance was loosely formed in the spring of 2001. 4. Agile Modeling (AM) was first defined in the fall of 2000, and will be published as a book in late February of 2002. Because agile methods are so new, there simply hasn't been sufficient time to prove that they work in a wide variety of situations. Yes, each methodology has excellent anecdotal evidence of its efficiency, but statistical proof provided by a detailed study doesn't yet exist, and probably won't for several more years. Some research resultsfor example, the effectiveness of pair programminghave been examined in detail, and the elements of iterative and incremental approaches are reasonably well known. However, we're going to have to wait a while for metrics concerning agile software development methods.
From Laggards to Innovators
Setting the Bar As these statistics indicate, current best and worst practices have been examined in detail, but the results of newly proposed techniques such as refactoring and co-location with customers have not yet been adequately analyzed. To compound this problem, the majority of agile methodologists are practitioners who are actively working on software projects and who presumably have little time to invest in theoretical study. It may be a long time until we see agile studies comparable to Jones' analyses of traditional techniques.
What One Needs to Know Perhaps the proof-hunters' motivations aren't appropriate. Are they really interested in finding an effective process, or are they merely looking for a reason to disparage an approach that they aren't comfortable with? Are they realistic enough to recognize that no software process is perfectthat there is no silver bullet to be found? Are they really interested in proof that something works, or simply seeking an assurance of perceived safety? Though currently, significant anecdotal evidence indicates that agile software development techniques work, there's very little statistically valid proofnor will this situation change anytime soon. If anecdotal evidence isn't sufficient, agile software development processes aren't for you ... yet! I'd like to thank David M. Rubin, Tim Bond, Dale Emery, Remy Fannader, Adam Geras, Michael Krige, Rob Lineberger, Ed Manley and Dave Thomas for their thoughtful comments regarding this issue posted on the Agile Modeling mailing list. Recently on the Agile Modeling Mailing List:Package diagrams. A discussion ensued when someone pointed out that package diagrams were not included in my list of modeling artifacts for agile modelers. Object modelers commonly create what are called package diagramsa UML diagram that consists only of packagesto serve as high-level diagrams for their system. The two most commonly employed diagrams are UML class diagrams and UML use case diagrams, although UML deployment diagrams could be used as well. A package can be applied on any UML diagram to gather similar elements together. Class Type Architecture. A discussion about the five-layer class-type architecture began after I posted a white paper on the subject. The five layers are User Interface, Controller/Process, Business/Domain, Persistence and System. The discussion focused on the importance of the separations of concern within your design, robustness and performance. A side discussion started pertaining to the modeling implications of each layer, which motivated me to add a new table to the white paper listing suggested types of modeling artifacts for each layer. As you would expect, there was a difference between the layers, suggesting the need for people to use different skill sets to work on each layer. The Next Level of Abstraction. A heated discussion regarding the modeling concept of abstraction began over the New Year holiday when someone questioned what the next level of abstraction would be from high-level programming languages such as Java and Visual Basic in current use. Previous contributors had posited that the Unified Modeling Language (UML) and Model Driven Architecture (MDA) promoted by the Object Management Group (OMG) didn't raise the level of abstraction from programming languages as much as did C over Assembly Language in the past. The use of UML for requirements, analysis and design was discussed, as was the concept of abstraction for all three. RECOMMENDED ONLINE RESOURCES
Agile Alliance Home Page.
Agile Modeling Mailing List.
Artifacts for Agile Modeling: The UML and Beyond. http://www.agilemodeling.com/essays/modelingTechniques.htm
Crossing the Chasm 2/e by Geoffrey A. Moore, eBook edition. http://www.amazon.com/exec/obidos/ASIN/B00005TPD3/ambysoftinc
DSDM Consortium.
Kirk Knoernschild's Principles and Patterns Page.
The OPEN Web Site.
Software Productivity Research.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved. |