| Isaac Gouy 2006-06-26, 7:03 pm |
| Vladimir Levin wrote:
> Isaac Gouy wrote:
>
>
> I don't like that idea. Here's why: The point I was trying to make with
> the agile process I described was that there was a useful feedback loop
> between developers who knew the code and the customers who wrote the
> stories and knew the business. Taking advantage of that constant close
> interaction helped us guide the development in the right direction.
> Defining 'Requirements Specialist' as a separate role would seem to
> remove that very interaction; it would imply that a requirements
> specialist would be sufficient without being a developer. For missing
> requirement I brought up, there were several options the customer had
> as a response:
>
> 1) That "averaged ge factors" case is in a future story, relax!
> 2) I don't care about it at all, just don't do anything in that case.
> 3) Wow, that's a good point. We'll write a story around that, thanks!
> 4) Well, if it's not too time-consuming, go ahead and label that case
> but that's all - no fancy breakdowns of where the averages are coming
> from.
>
> I think *all* of these potential responses are helpful. It's the
> feedback between the customer and the developer that helps both
> parties.
I don't think you're succeeding in making the point you're trying to
make. Why wouldn't there be "a useful feedback loop" between the
requirements specialists who knew the existing requirements and the
customers who knew the business - that would cover #1, #2 & #3.
The "developers who knew the code" clause becomes important in #4
because of "if it's not too time-consuming" - however, what I hear #4
to say is if it's free we want it but we don't want to give up anything
else to get it.
> Consider the hypothetical scenario where that "averaged ge
> factors" case were to have been covered in the original story. In that
> case, if the requirement were complex, I'd have possibly asked for it
> to be broken into a separate story when we went over the stories at the
> start of the sprint, or even before I began working on the story if
> that's when I realized that this requirement was complex and did not
> impede the remainder of the story. It would be a red flag for the
> customer to note that this would take more time than they might want us
> to spend, and would given him/her a chance to remove or simplify that
> feature. Or not, but at least it would be an informed decision.
Again, why wouldn't that same scenario play out with requirements
specialists rather than programmers, with the customer choosing between
requirements.
(When we talk about "a chance to remove or simplify that feature" it
seem's like the customer already decided there was a requirement and
prioritised it, and now we are looking at different solutions to meet
that requirement.)
|