- Ron Jeffries is cool
- Charlie Mingus is cool (is-not-was, even tho....)
wrote:
> To come up with what to code is the job of requirements analysts.
> So in most cases the wrong is not with coders but with
> requirements analysts. If requirements analysts were doing a good
> job, most, if not all, coders would be doing a good job.
Well, not according to how one does things in Extreme Programming,
in two regards.
First, the team includes what we call a Customer, who is ideally a
business person, not a "requirements analyst". The Customer, helped
by the Whole Team, expresses what is needed in three forms that I
call "Card, Conversation, Confirmation" , namely a small token to
remind us of what the "Story" is, and to use in tracking its status;
discussion of the need until the team and Customer understand the
problem; and tests, "owned" by the Customer but typically written by
the team, to determine that it works.
Second, your notion that coders would be doing a good job if
requirements were clear does not hold up in practice. In order to
write programs that actually work, we do need to know what to do. We
also need to know how to test that code, how to refactor it as our
understanding changes, and how to make sure that it keeps working.
It turns out that many would-be programmers do not have all the
skills necessary to turn "requirements" into viable "code", much
less the additional skills needed to be effective members of the
teams that create software.
Ron Jeffries
www.XProgramming. com
www.xprogramming. com/blog
Anyone can make the simple complicated.
Creativity is making the complicated simple. -- Charles Mingus
UPDATE - from another poster:
I would also like to suggest that the semantics in this case are important. Job titles like Architect, Requirements Analyst, etc. will pigeon hole people, and will cause folks to see boundaries that shouldn't exist.
No comments:
Post a Comment