How Much Ceremony Do You Want?

We know that iterative and risk-driven development is desirable relative to waterfall development, and therefore projects should be on the lower half of the Waterfall/Iterative axis. Less certainty exists as to where projects should be on the scale of Low versus High Ceremony.

In "Get Ready for Agile Methods, with Care," [15] Professor Barry Boehm describes how the need for rapidly adapting to evolving business environments should be balanced with the need for predictability and discipline by choosing the right level of ceremony to fit project-specific needs. (Boehm used the term "agile" versus "disciplined" to mean roughly the same thing we do with low versus high ceremony.)

[15] See Boehm 2002.

Project factors favoring a lower ceremony approach include operating in a rapidly changing marketplace , co-located teams, small teams , and less technical complexity. Using a low-ceremony approach means reduced system documentation, for example, not documenting and tracking changes to requirements, designs, or test cases. Limited documentation means fewer updates are required when changes are made, thereby saving time and reducing the cost of change, which may be very important for a company operating in a rapidly changing marketplace.

Factors driving a project toward higher ceremony include large-scale development, distributed development, technically complex projects, and complex stakeholder relationships. For many such projects, lack of proper documentation can be very costly since it can prevent effective communication, and make it very hard and expensive to maintain technically complex or large software systems.

It should be noted that in some cases proper automation can accomplish the benefits sought by adopting a higher ceremony approach, without bearing the costs of document overhead. Examples of such tool technologies are

  • Configuration and Change Management solutions that can simplify life for developers and hence provide them with a "lighter" process.

  • Visual modeling support providing synchronization between requirements, design, and implementation, also known as round-trip engineering.

  • Automated metrics collection tools that can simplify reporting for developers and analysis for managers.

All of these technologies come with an infrastructure overhead cost in terms of setting up and managing the necessary tool environment, but they can make the actual development effort much more efficient.



The Rational Unified Process Made Easy(c) A Practitioner's Guide to Rational Unified Process
Programming Microsoft Visual C++
ISBN: N/A
EAN: 2147483647
Year: 2005
Pages: 173

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net