On Wed, Oct 23, 2013 at 10:11 AM, Richard Schoen
<richard@xxxxxxxxxxxxxxx> wrote:
There appear to be shades of Agile, so we've picked up the bits
that seemed to make sense such as requirements before
coding
Well, "requirements before coding" is actually more strongly
associated with the waterfall development style than the agile style.
You could definitely argue that it is part of agile, but the emphasis
of agile is on adaptability and responsiveness; and as such the
requirements are much more likely under agile to change quickly or be
revisited.
Whenever I hear people in IT (particularly in companies whose core
business is NOT their IT) talk about requirements before coding, it's
in the context of having as close to iron-clad specs as possible for a
whole project prior to doing any coding at all for that project. The
specs are typically only revisited if it is discovered that they are
unworkable (and the IT people working under this model typically blame
the users for giving them bad specs or for asking to change the specs
after the work starts). This model sounds much, much more like
waterfall, and practically not at all like agile.
If by "requirements before coding" what you really mean is "let's
understand something (which is preferably some small piece) well
enough to be able to write tests for it first (and let's then go ahead
and write those tests first) before we do coding (for the
functionality being requested)" then, yes, absolutely, you are talking
more agile-style than waterfall-style. But that's a lot of extra
verbiage that you're implying/assuming. In my opinion, far too much
to distill to a three-word buzzphrase.
John
midrange.com
