Home > Archive > Extreme Programming > August 2007 > definition is everything
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
definition is everything
|
|
|
| Actual problem is at p:
------------p----------
It is defined at various points:
C--E--M--B--p---T-----I
at C by customer
at E by executive
at M by management
at B by business analyst
at T by technologist
at I by implementor
Has XP 2nd edition done something about only the Customer defining the
problem?
Furthermore, the value of the definition comes from the repeated
modification of the definition, not from the artifact itself. The
insight into the current problem comes from the change of or
difference in the model/metaphor to the next thing. Definition is
crucial, but thrown away. What's the point of trying to freeze
definitions in a dept wiki, for example.
I spent a month solving the wrong problem defined by C and M, that
was not the actual problem when the problem-solver came in contact
with the problem.
-r
| |
| Phlip 2007-06-30, 10:07 pm |
| r wrote:
> Actual problem is at p:
>
> ------------p----------
>
> It is defined at various points:
>
> C--E--M--B--p---T-----I
>
> at C by customer
> at E by executive
> at M by management
> at B by business analyst
> at T by technologist
> at I by implementor
>
> Has XP 2nd edition done something about only the Customer defining the
> problem?
The "whole team" concept simply means that everyone has a voice here.
Within the team, there is a business side and a development side. Your 'p'
defines the difference between the two sides. So the XP Bills of Rights
imply who on what side has what right.
Next, the "unitary Onsite Customer" doesn't mean there's only one person
writing user stories. It means there's only one person that anyone should go
to for the Decision of Solomon - how to cut a story in half; when to declare
a story finished. Developers should not "shop for judges" on that one.
> Furthermore, the value of the definition comes from the repeated
> modification of the definition, not from the artifact itself. The
> insight into the current problem comes from the change of or
> difference in the model/metaphor to the next thing. Definition is
> crucial, but thrown away. What's the point of trying to freeze
> definitions in a dept wiki, for example.
I think you think there's a pipeline. That's phasist thinking. Everyone in
XP should see last w 's features, and should have input to this w's
features.
> I spent a month solving the wrong problem defined by C and M, that
> was not the actual problem when the problem-solver came in contact
> with the problem.
Didn't M and B (and C and M) also review your solutions after the first
w? That's the point - to never spend more than a w going in the wrong
direction.
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
| |
|
| > > I spent a month solving the wrong problem defined by C and M, that
>
> Didn't M and B (and C and M) also review your solutions after the first
> w? That's the point - to never spend more than a w going in the wrong
> direction.
Why did they need to review? It was a mandated solution based on
their analysis.
We bumped into the actual problem accidentally months later.
-r
| |
|
|
|
|
|
|
|