[rspec-users] it "should [action] ..." vs it with an active voice
pergesu at gmail.com
Mon Nov 12 23:56:16 EST 2007
On Nov 12, 2007 8:47 PM, Pat Maddox <pergesu at gmail.com> wrote:
> On Nov 12, 2007 7:12 PM, David Chelimsky <dchelimsky at gmail.com> wrote:
> > On Nov 12, 2007 9:03 PM, Pat Maddox <pergesu at gmail.com> wrote:
> > >
> > > On 11/12/07, David Chelimsky <dchelimsky at gmail.com> wrote:
> > > > On Nov 12, 2007 8:09 PM, Pat Maddox <pergesu at gmail.com> wrote:
> > > > > The difference is that the story is an authoritative
> > > > > spec of how the system should behave, and the description has no
> > > > > authority at all.
> > > >
> > > > I don't have that sense at all. Where do you get that from?
> > >
> > > >From the belief that the customer is the ultimate authority on what it
> > > means for the system to behave acceptably, and the fact that stories
> > > are customer-facing and specs are developer-facing.
> > I totally agree that the customer is the authority - however, the
> > customer has just as much right to change her mind about a story as I
> > do about a spec! So why should stories be any more locked down than
> > specs?
> Stories represent a bridge between the customer's and the developer's
> minds, a snapshot of the shared understanding at a given point in
> time. They do not obviate the need for customer-developer
> communication. A customer should be able to change her stories as
> much as she wants, but all but the very simplest changes ought to spur
> a discussion and reevaluation of assumptions.
Also, I don't think this approach poses an obstacle to creative tools
like a Story Builder. If anything, I'd say it enhances those tools.
A customer can play with the tool and build various stories without
committing to anything, building stories and then tossing them away on
a whim. Then when she finds a few stories she likes - perhaps it's
very valuable, or 80% of the steps are already done - she can bring
them up with the developer. That would allow the customer to take a
more active role in exploring potential stories, and make more
efficient use of direct customer-developer collaboration because less
time is wasted sifting through half-hearted stories.
More information about the rspec-users