Software Engineering - Re: Agile In Action

Author

Re: Agile In Action

Vladimir Levin

2006-06-24, 8:15 am

bill turner wrote:

> I have seen little requirement for this knowledge. In fact, a quick search on
> DICE would demonstrate that it has not been as widely adapted as some seem
> to think. If fact, it seems only a small percentage of shops have adopted these
> practices.

That's very possible. Since I make an extra effort to work on agile
projects, I am very likely to think they are more pervasive than they
really are! :)

> Why wouldn't it be possible? I don't see it. Nothing you have
> described precludes the ability of an RE from identifying the three
> types of analysis you describe. In fact, I would say it would be an RE

Good question. Here's my attempt at an answer: From my point of view,
the problem is one of time and perspective. For any requirement, one
can always ask "Is there anything more? Anything different? Anything
you haven't thought of?" as a generic question. One doesn't even need
an RE. One could write a computer program that responds that way to any
requirement that you input into it. In fact, it is something I try to
do, both in the software world and when I am leaving on a trip! I
suspect that in many cases the user would simply say "As far as I know
right now, no." I've had quite a lot of experience eliciting
requirements, and I have often witnessed the scenario where I ask
repeatedly whether a particular difficult feature will ever be needed
and repeatedly get the answer "no" only to see the feature pop up
later. Sometime's it's exactly the feature I asked about, and sometimes
there's a spin on it that would be difficult for anyone without
extremely deep knowledge and foresight to come up with. Anyhow, my
point is this: All of the stories we develop on our project go through
a review committee of subject experts before reaching the developers,
and yet it is often the case that stories are modified as in my example
during development. In my opinion (and it's just an opinion), one
cannot think of every possible angle on a story, and furthermore,
trying to do so is probably not a good idea (because the amount of time
and effort it takes to get there is prohibitive). When you're dealing
with a real, complex, application, the number of combinations gets
large, and it becomes almost impossible to cover things ahead of time.
If one thing is not missed, then something else will be. It reminds me
of diagonalization, where you can always add another infinitely long
binary string to the list, but then you look anew at the diagnonal, and
the complement is still not in the list, ad infinitum. Hence the set of
all infinitely long binary strings is uncountable.

In software, I believe there is this principle at work: For every new
requirement, there will always be a number of things that are vague,
can be interpreted in a several ways, or may not be considered until
the story is in development, or even afterward.

My point was to try to show how three people worked together to satisfy
a requirement. I introduced a requirement that had been missed because
it was not a common case and because our experts only have so much time
to develop stories. The GUI expert had some additional input that
neither I nor the customers had thought of. There is a natural
temptation to think that some more skillful forethought could have
achieved the same result. Personally, I don't think so, at least not in
most cases. It would be interesting to do some experiments with
requirement gathering to see how good up-front elicitation of
requirements really is.

> who failed to ask the appropriate defining questions. As for the UI
> design, that too is completely doable. Whether or not people thought
> creatively has little to do with the methodology used. In fact, I
> would posit that quick drawings on paper or whiteboard could elicit
> exactly the same response, then it could be formally defined in a
> document.

> Your conclusion, it seems to me, seems unwarranted.
>
> <snip description of experience>
>
>
> Bill
> ------------------------------------------
> Bill Turner
>
> A faith that the free play of market forces will eventually end in Good is, in fact, more 'absurd' than religious belief, for there, at least, there is a presumption of an intelligent Agent Who writes straight with His crooked lines. - William Pfaff
>
>
> Views expressed are entirely my own and only coincidentally represent those of other persons or entities.

Isaac Gouy

2006-06-27, 9:59 pm

Vladimir Levin wrote:
> Isaac Gouy wrote:
>
> I should have been more clear. We did in fact raise this issue because
> of a failing test while working on a different story. In this case we
> were trying to direct to a unit while testing something else. The test
> failed, and we asked if we should be able to direct to a unit.

That is essential information, the example just doesn't make any sense
if you miss that out :-)

> The
> customers told us "no" but then realized this might be something to
> consider for the story they had just written which allows one to direct
> to higher level facilities.
>
>
> It's not that I don't think people should try to be as thorough as they
> can when developing stories (or requirements, or whatever the right
> term is). The examples I have brought up are meant to illustrate that
> "drilling down into the detail of requirements" is not good enough when
> developing complex applications. The feedback loop I've tried to show
> is intented to handle the risk of missing requirements when the story
> is being defined. Exhaustive planning in the requirements stage has
> additional potential risks, such as analysis paralysis.
>
> If I understand your objections properly, you seem to be saying that a
> better approach would be for customers and requirement engineers to
> carefully put together stories well ahead of development in a separate
> phase. Once these requirements are prepared, the developers will not
> have access to the customers any longer and will be expected to develop
> the code only from the specs given and possibly from discussions with a
> small number of requirement engineers. Presumably, issues like the ones
> I've described simply won't occur. If they do, I assume the process for
> dealing with them would be much more formal and time consuming than the
> one I've descrived. I think that's not the right way to do development,
> but you're entitled to your opinion of course. I've tried my best to
> use a few examples to illustrate why such an approach would not
> generally be useful, but I certainly am not claiming any kind of proof.
> Still, I would be interested in finding out what kinds of experiences
> you in turn have and what kind of approach works better for you than
> the one I've outlined.

I had two objections
- first, there was no mention of working with the code (you've fixed
that)
- second, too many negative assumptions about what would happen in
different scenarios (you're still doing that).

What you have is an example of your approach working - it's a mistake
to confuse that with an example of some other approach not working.

"I think that's not the right way to do development"
imo Without knowing the detail of what and who and why, it's silly to
be dogmatic about the right way to do development. Different projects,
different approaches.

Sponsored Links