(No, I haven't forgotten about Test Automation. I'm just trying to leverage my time in the best possible way. Most of this post came out of a recent discussion on the SW-IMPROVE discussion list ...)
One thing that I found helpful when gathering requirements is something I call "blank sheet of paper syndrome." That is to say, if you give a (brand new) analyst a template, they will often react with something like this:
"oh, easy, I can do this. Project Name, Project Manager, Executive Sponsor, Initiated Date, Today's Date, Desired Date ... I can fill this out." (... 30 minutes pass ...) "Here's your requirements doc."
On the other hand, if you give them a blank sheet of paper, you are more likely to have a reaction like this:
"But ... well ... this is blank! I have no idea what to write! I don't really know what the customer desires! I had better go find out!"
In my experience, this second reaction is much more likely to result in figuring out the /essential/ requirements of a software system, instead of gathering requirements that "all look like each other."
The argument /for/ requirements templates is that without the template you would forget something. My personal conclusion is that, for the vast majority of projects I have worked on, I will gladly run the risk of forgetting something on the template, in trade for the benefit of, hopefully, capturing something more essential on a personally-written document.
Now, I would be remiss if I did not add that the Planning Game in Extreme Programming - where you have no person in the middle and negotiate the requirements, is one valid implementation of blank sheet of paper concept. You cards could even have a slot for title, points, priority, and description, and I wouldn't be offended. :-)
In other words, Jerry Weinberg's Rule of three, in that you should strive for at least three options for every problem, still applies. "No Template/Blank Sheet" and "All Template/No Customization Sheet" is a false dichotomy - you can always do more or less, allow some customization, have a half-dozen questions instead of a three-page template, and so on.
All that I am saying here is that in the push for stable/predictable/repeatable, some organizations try to make all projects look the same. Sometimes, for the project team, that can do more harm than good.
Friday, October 17, 2008
Subscribe to:
Post Comments (Atom)
1 comment:
Neat little essay, Matthew, not too much, not too little. In particular, it stimulates related thoughts, which is what essays should do.
For me, it got me thinking about these two phrases I hear about projects in their early stages:
a. It's just like every other project. (start with a template)
b. It's different from any project we've done in the past. (start with a blank sheet of paper)
This led me to extend your rule-of-three heuristic:
If you say a, then don't proceed until you can list at least three ways this project is different from any other project we've done. (IOW, we can't use a template 100% from past experience.)
If you say b, then don't proceed until you can list at least three ways this project is like one or more other projects we've done.
What this does is give you an adaptive "sheet of paper," one that's blank when you think it can be completely templated, but is templated when you think it can be done only by starting with a blank sheet of paper.
Post a Comment