Hi Andy,
First of all, thanks for asking these questions. As we push jbehave
public, we are expecting all kinds of questions. It is better to get
them now and start talking about them than on the spot.
Let's start from the top.
The cycle you wrote are very accurate, except you need a "refactor"
step between 4 and 5.
With that cycle, your can write high quality code with over-engineer
your product, yada yada yada... But how do you know at which point
you can tell your customer, "hey it is ready, check this out!" without
fearing that he or she will say "but.. you are supposed to display on
the screen that there are 7 emails sent out instead of 8 (because of
that one duplication)!" ?
That is where the stories come into the picture. The customer
specifies when the story is done by writing them into a format that
can be run. You just need to make sure that the story can finish
without error before you go and show it off. If there is anything
missing, it is a lot easier to discuss and figure out if it is because
of lack of requirement, lack of story specification, or anything else.
The key is not to find the person to blame, but to figure out where
you can improve in your development process.
So your are right that the iteration is not as tight as the ones of
BDD. It is the cycle outside the BDD cycle. The idea is that you run
the story, verify it cannot pass (maybe write some fixtures to support
the story), then you keep programming until you are done (you can
checkin code, eat food, sleep, etc. of course). The idea is that you
work on one story only at one time because it helps you focus and
deliver value to the customer faster.
It will take long for you to get to a "pass" state. To make the story
run, it can actually be very esy, right? Like BDD, you just need to
write the minimum code to make sure that THIS story run and does the
right thing.
One last note, I feel that you are pretty familiar with the concept of
"BDD" but not with the whole idea of agile development process. I
recommend you read a book that is coming out called "Art of Agile".
It is under review right now so you can read the draft here
(http://www.jamesshore.com/Agile-Book/)
Cheers
Shane
On 4/6/07, Andy Zimmerman <[EMAIL PROTECTED]> wrote:
Shane,
That does help quite a bit. I guess my next question is more of a practical
one. I'm completely sold on the behaviour-first methodology for writing
code, but I'm trying to figure out how to incorporate the Story aspect into
it.
Ignoring the Story framework, I'd simply follow a cycle like this:
1. Write Behaviour
2. Verify Behaviour (fails)
3. Implement Behaviour
4. Verify Behaviour (passes)
5. Repeat
Now, how do I add the Story framework into this cycle? Each story obviously
(at least usually) spans mutliple Behaviours, so it doesn't lend itself to a
nice, tight iteration; it'll take more time than that. If I write the
Stories first, it'll take longer for me to get to a "compilable" state,
right? Hmmm.... maybe that's a bad assumption on my part.
{runs off to look at the Hellbound example ... again}
I have to admit, though, I'm pretty sure I'm not grokking something
fundamental in how the Stories are run - what they are actually *doing*. Is
there a lot of autowiring going on in the Story framework?
Oh, and I apologize if the dev list was the wrong place for these questions.
I realized after I started the thread that they probably *belong* in the
users list. *blush*
Thanks,
Andy
--
Shane
http://www.shaneduan.com
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
