Software Development's Agile Modeling Newsletter
In This Issue:
--2003 Software Development Salary Survey
--19 Tips for Agile Requirements Modeling
--News and Views from the AM Mailing List
--Hot Links
2003 Software Development SALARY SURVEY
Dear Software Development reader:
Every month, we receive letters from readers thanking us for our coverage of the design-build-test-deploy lifecycle for successful software projects. One of the must-read resources we provide is an annual developer salary survey. Our data is the most trusted and unique tool for anyone -- from developer to project manager to chief technology officer -- wondering whether they're getting paid what they are worth in the field.
If you work in the U.S., I'd like to invite you to participate in Software Development magazine's annual salary survey. The 26-question survey takes about eight minutes to complete, and can be found at http://www.cicresearch.com/Proj03792/
Please be assured that all responses are completely confidential. This is used exclusively as editorial research for an article to be published in the November 2003 issue. Only aggregate results will be used, and we will not disclose or use your e-mail address for any other purpose than to alert you to next year's survey.
Sincerely,
Alexandra Weber Morales
Editor in Chief
Software Development
CMP Media LLC
600 Harrison Street
San Francisco, California 94107
[email protected]
19 TIPS FOR AGILE REQUIREMENTS MODELING
I'd like to share some vital tenets that will help to set an effective foundation for your agile requirements-modeling efforts:
1. "Active stakeholder participation is crucial." Project stakeholders must be available to provide requirements, to prioritize them, and to make decisions in a timely manner. It's critical that your project stakeholders understand this concept and are committed to it from the beginning of any project.
2. "Software must be based on requirements." If there are no requirements, you have nothing to build. The goal of Software Development is to build working software that meets the needs of your project stakeholders. If you don't know what those needs are, you can't possibly succeed.
3. "Nothing should be built that doesn't satisfy a requirement." Your system should be based on the requirements, the whole requirements, and nothing but the requirements.
4. "The goal is mutual understanding, not documentation." The fundamental aim of the requirements-gathering process is to understand what your project stakeholders want. Whether or not you create a detailed document describing those requirements, or perhaps just a collection of hand-drawn sketches and notes, is a completely different issue.
5. "Requirements come from stakeholders, not developers." Project stakeholders are the only official source of requirements. Yes, developers can suggest requirements, but stakeholders need to adopt those suggestions.
6. "Use your stakeholders' terminology." Don't force artificial, technical jargon onto your project stakeholders. They're the ones doing the modeling -- and the ones the system is being built for -- therefore, you should use their terminology to model the system.
7. "Publicly display models." Models are important communication channels, but they work only if people can actually see -- and understand -- them. I'm a firm believer in putting models, even if they're just sketches or collections of index cards, in public view where everyone can access and work on them.
8. "Requirements change over time." People often don't know what they want -- and if they do, they usually don't know how to communicate it well. Furthermore, people change their minds -- it's quite common to hear stakeholders say, "Now that I think about this some more ..." or "This really isn't what I meant." Worse yet, the external environment changes -- perhaps your competitors announce a new strategy, or the government releases new legislation. Effective developers accept the fact that change happens and, better yet, they embrace it.
9. "Requirements must be prioritized." Stakeholders must prioritize the requirements, enabling you to constantly work on the most important ones and thus provide the most value for their IT investment.
10. "Requirements only need to be good enough." Not perfect? But you'll build the wrong thing! Agile developers don't need a perfect requirements specification, nor do they need a complete one, because they have access to their stakeholders. Not sure what a requirement means, because there isn't enough detail? Talk with your stakeholders and have them explain it; if they can't explain it, keep talking.
11. "Use simple, inclusive tools and techniques." It's possible, and in fact desirable, for stakeholders to be actively involved in modeling. However, stakeholders typically aren't trained in modeling techniques, nor complex modeling tools. Although one option is to invest several months to train your stakeholders in modeling tools and techniques, a much easier approach is to use simple tools, like whiteboards and paper, and simple modeling techniques. Simple tools and techniques are easy to teach and are therefore inclusive because anyone can work with them. Don't scare people with technology if it's not needed!
12. "You'll still need to explain the techniques -- even the simple ones." Because people learn best by doing, it's often a good idea to lead stakeholders through the creation of several examples.
13. "Most requirements should be technology independent." I cringe when I hear terms such as "object-oriented", "structured" or "component-based" requirements. These terms are all categories of implementation technologies and therefore reflect architectural and design issues.
14. "Some requirements are technical." It's important to recognize that some requirements, such as the technical constraint that your system must use the standard J2EE and relational database technologies employed within your organization, are in fact technology dependent. Your stakeholders should understand when this is applicable, and why.
15. "You need multiple models." The requirements for a system are typically complex, dealing with a wide variety of issues. Because every model has its strengths and weaknesses, no one single model is sufficient; therefore you'll need several types of models to get the job done.
16. "You need only a subset of the models." When you fix something at home, you'll use only a few of the tools in your tool box, such as a screwdriver and a wrench. The next time you fix something, you may use different tools. Even though you have multiple tools available, you won't use them all at any given time. It's the same thing with Software Development: Although you have several techniques in your "intellectual toolbox," you'll use only a subset on any given project.
17. "The underlying process determines some artifacts." Different methodologies require different requirements artifacts. For example, the Rational Unified Process and Enterprise Unified Process both require use cases, Extreme Programming requires user stories and Feature-Driven Development requires features.
18. "Take a breadth-first approach." It's better to first paint a wide swath to try to get a feel for the bigger picture, than to focus narrowly on one small aspect of the system. By taking a breadth-first approach, you quickly gain an overall understanding of the system, and you can still dive into the details when appropriate. Taking an Agile Model-Driven Development approach, you gain this broad understanding as part of your initial modeling efforts during "Cycle 0."
19. "Start at your enterprise business model." Some organizations have what's called an enterprise business model that reflects their high-level business requirements. If your organization has one, and it's current, it's a perfect starting place to understand both your organization and how your system fits the overall picture. You should be able to identify which high-level requirements your system will (perhaps partially) fulfill; otherwise, it's a clear sign that either the model is out-of-date or it's not necessary in your organization.
This column was drawn from Chapter 4 of my forthcoming book, The Object Primer, 3rd Edition: Agile Model Driven Development with UML 2 (Cambridge University Press, January 2004).
NEWS AND VIEWS FROM THE AM MAILING LIST
--SWEBOK
The most popular issue, arguably an off-topic one, is the IEEE's
Software Engineering Book of Knowledge (SWEBOK) efforts. The
discussion swirled around issues such as whether Software Development is closer to an engineering process or an art
(many people leaned toward aesthetics over science) and whether
it was truly possible to define a book of knowledge for our
profession (it's probably too early to do so because we haven't
come to a reasonably common consensus on how to go about developing
software).
--Agile Models Distilled
I've been working on a collection of pages, each of which describes
one type of modeling artifact. Although this is still a work in
progress, a large number of pages have been posted online, with
more still to come. Whenever I post a new artifact description, I
ask for feedback on the list, and a discussion ensues. (See the
Hot Links section for URLs.)
--Agile Modeling Limits
A new member asked about the limits of Agile Modeling. Various
issues were discussed, including when AM was applicable (on agile
projects, big or small), the scope of AM (just modeling and
documentation), and the idea that adopting even some of its
principles and practices is a step in the right direction.
Last Chance for Fame and Fortune
Do you have a deployment or beta horror story that you're dying to tell? Send your tale of no more than 500 words to [email protected] for possible publication in the October 2003 issue. Submission deadline is July 28, 2003.
HOT LINKS
In "Active Stakeholder Participation," I argue that project
stakeholders can and must be actively involved with the Software Development process.
Go to http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm
The Agile Alliance home page is the best starting point for anyone
interested in learning more about agile Software Development.
http://www.agilealliance.org
My article "Agile Enterprise Architecture" describes agile techniques and philosophies for enterprise architects. http://www.agiledata.org/essays/enterpriseArchitecture.html
"Agile Model Driven Development (AMDD)" overviews how to take an
AMDD approach on a Software Development project.
Check it out at http://www.agilemodeling.com/essays/amdd.htm
Find the "Agile Modeling Mailing List" at http://www.agilemodeling.com/feedback.htm
Find agile modeling training resources at
http://www.agilemodeling.com/training.htm
"Agile Models Distilled: Potential Artifacts for Agile Modeling"
provides links to pages overviewing various modeling artifacts
such as business rules, use cases, user interface flow diagrams
and UML activity diagrams.
http://www.agilemodeling.com/artifacts/index.htm
Find out about Extreme Programming Explained -- Embrace Change by Kent Beck, (Addison-Wesley, 2000), at http://www.amazon.com/exec/obidos/ASIN/0201616416/ambysoftinc
The SWEBOK home page, or the "Guide to the SWEBOK," can be found at http://www.swebok.org
Check out Stephen R. Palmer and John M. Felsing's A Practical
Guide to Feature-Driven Development (Prentice Hall PTR, 2002) at
http://www.amazon.com/exec/obidos/ASIN/0130676152/ambysoftinc
The Rational Unified Process 2nd Edition: An Introduction
by Philippe Kruchten (Addison-Wesley, 2000) can be found at
http://www.amazon.com/exec/obidos/ASIN/0201707101/ambysoftinc
