Dr. Dobb's Journal - November 2008 - (Page 64)

The Agile Edge by Scott W. Ambler Newsflash: Agilists Write Documentation! Contrary to popular myths YOU’VE LIKELY HEARD, and worse yet spread, some of the common myths around modeling and documentation on agile projects. For example, there’s the myth that Agilists don’t do any architecture, something that flies in the face of the fact that all systems have architectures regardless of the development paradigm used to create them. Another myth is that Agilists don’t do up-front requirements modeling, yet when was the last time you saw a software development get funding without an indication of what was going to be built? Agilists apparently don’t write documentation either, having magically convinced end users that they don’t need user manuals, operations and support people that they don’t need any sort of documentation, and the maintenance team that they don’t need any sort of overview documentation. The list of things that agilists are supposedly getting away with is truly impressive, so needless to say, I believe that it is abundantly clear that these myths and misunderstandings need to be cleared up. This month I summarize the results from two surveys, one that focused specifically on modeling and documentation activities on software development projects and one that explored what agile teams actually do in practice. Reality is definitely far from the rhetoric. of 33 percent only sketching and 33 percent sketching and then capturing critical ones. Seven percent of agile teams use software-based modeling tools (SBMTs) such as ER/Win or Rational System Architect (RSA) for documentation purposes and 5 percent for full round-trip engineering, compared with 16 percent and 0 percent for traditional teams, respectively. Figure 1 summarizes the results for all four types of teams that the survey looked at: ad-hoc, traditional, iterative, and agile. The Ambysoft 2008 Agile Practices and Principles survey explored how well agile developers agreed with various development strategies. To explore whether agile teams were doing up-front requirements modeling, it asked “We do some initial requirements modeling at the beginning of agile projects for scoping and planning purposes.” The survey found that 74 percent of respondents either strongly agreed or agreed with this statement, 18 percent were neutral, and only 8 percent indicated disagreement or strong disagreement. Similarly, to explore up-front architecture modeling, it asked the question “We do some initial architecture modeling at the beginning of agile projects to get going in the right technical direction.” The results were almost identical, with scores of 73 percent, 19 percent, and 8 percent, respectively. In short, two different surveys to two different communities both showed that agile development teams do, in fact, model. Agile teams are doing up-front modeling because they still need to answer questions around the scope that they’re addressing, the relative cost and schedule, and what their technical strategy is. Without coherent answers to these questions, the project simply won’t get funding. Although you need to do some modeling early in the project lifecycle, that doesn’t imply that you need to write mounds of documentation to do so. You can gain the benefit of modeling, which is to communicate and think things through, without accepting the costs of unnecessary documentation. Another reason why agile teams are doing up-front modeling, contrary to the popular belief of extremists in the agile community, is because architectural metaphors are not sufficient. System architectures are complex, addressing a myriad of nonfunctional requirements and technical constraints such as performance, security, scalability, usability, legacy assets, integration, and many more (see my October 2008 column on this topic). An architectural metaphor simply isn’t going to get the job done. For example, consider the website for the Agile 2008 conference (www.agile2008.org), which was built around the metaphor that organizing a conference is just like running a stage production. This metaphor clearly didn’t work well because people didn’t find the website very usable. For example, to put together a schedule for yourself you needed to navigate the 19 stage pages to get detailed listings of what was being offered on each “stage.” Yikes. A little bit of up-front requirements and architecture envisioning could very likely have avoided this sort of problem. Up-Front Modeling Dr. Dobb’s 2008 Modeling and Documentation survey discovered a few interesting things about how teams approach modeling. It found that 18 percent of traditional teams did no modeling at all, compared with only 5 percent of agile teams, implying that agile teams are arguably more likely to model than traditional ones. It also found that the primary approach to modeling on agile teams was that 55 percent of teams preferred to sketch to think things through or to communicate ideas, and an additional 30 percent both sketched, then captured critical sketches when it made sense to. The majority of traditional teams also focused on sketching, with rates 64 Dr. Dobb’s Journal l www.ddj.com l November 2008 Agile Documentation Dr. Dobb’s Modeling and Documentation survey revealed that there’s not a lot of difference between the various development approaches when it comes to http://www.agile2008.org http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - November 2008

Dr. Dobb's Journal - November 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer's Notebook Saving Open Source Conversations iPhone Building Your Own Web Server Green Telnet What's New In Boost Threads? Testing Service Oriented Architectures Test Case Generation, UML, and Eclipse Unit Testing Web Services C3 Programming The Agile Edge Swaine's Flames Effective Concurrency

Dr. Dobb's Journal - November 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.