[rspec-users] Cucumber fat client

Mischa Fierer f.mischa at gmail.com
Tue Dec 16 06:08:40 EST 2008

I can maybe offer something here. *begin rambling*

My team of 4 (2 coders, 2 biz people) has recently switched to using Pivotal
Tracker, and we've been doing the following:

1) Figure out what we can do that will add value
2) Draw out the ui / changes on a whiteboard
3) Write out features & copy them into pivotal (as stories)
4) Implement

This solves the following problems:

Coders have trouble communicating how long things will take to MBAs
(clients). Putting them in pivotal allows us to be clear about how long
things will take, and that adding things will add time.

Reduces miscommunications between clients and coders, because it forces
clients to be clear about what they want / gives coders ability to show why
some things are not worth the time.

What is still lacking:

While we've been getting better at this, what's lacking is a client ability
to understand how features can/should be written.
I've been just allowing them to write them however they want, with a few
pointers, as for a lot of steps it requires a bit too much understanding
about how Rails works. For example, explaining to a long-term client the
difference between "press" and "follow" is fine, but I can imagine feeling a
bit silly trying to explain it to a new client whom I am making a proposal

So, the solution to this may be to work together (on this list) to come up
with better ways of writing features. (E.g. I've stopped using "And I should
be at xyz" and "And there should be a xyz form" and a few other similar
things except in cases where they're necessary, as clients would not
themselves include these kind of steps for the most part)

So, in terms of an interface:

I like the idea of changes coming in via something like git, where I would
be able to see the differences. However this is not particularly different
from updaing a feature on Pivotal, Trac or Lighhouse.

I think a more interesting idea for an interface would be something that
helps clients write features, like, some sort of drag and drop thing where
they could start as a certain type of user, then drag in whens, then type in
thens, or something. Probably not specific enough to be usefull, but maybe
this will spark an idea for someone else.

In the distant future I can imagine some sort of speccing web app that would
allow clients to build features by clicking and typing, and then rearrange /
sort them plus visualize how they link together.

So, for example, there might be:

UserTypes - role:string

Actions  - what:string

Results - what_happens:string

As a client I would be able to create a bunch of these, then arrange them
and then print them out for my coders.


On Tue, Dec 16, 2008 at 12:42 AM, Matt Wynne <matt at mattwynne.net> wrote:

> On 15 Dec 2008, at 12:53, Bart Zonneveld wrote:
>> On 14-dec-2008, at 19:49, mike.gaffney wrote:
>>  Why not make a web client that manipulates git based projects in the
>>> background? I've been messing around with Grit and doing things like this
>>> lately for http://rdocul.us a site I run and it is very easy to do. If
>>> everything is in a standard location you could just add a project via an
>>> administrative page and it would be cloned in the background, then they
>>> could:
>>> browse all specs (just a filesystem listing)
>>> edit and save specs (git add, commit, push)
>>> look at a history on a given spec (log)
>>> look at the history of all changes to the specs (log on a path)
>>> merge changes / conflicts
>> Correct me if I'm wrong (and I probably missed something), but why do you
>> and some others in this thread want users to actually edit a feature?
>> That's going to wreck havoc with steps that won't match anymore, breaking
>> features, and therefore making the client angry.
>> WDYT?
>> bartz
> What else would they want to do though that would add much value?
> My thinking now is that I would perhaps have the customers working on a
> different branch of the code, which was still built in CI but failed with a
> 'softer' noise, to indicate that there was new work to do. We'd expect the
> build for this branch would be 'broken' most of the time.
> As developers, we could then pull in the commits from this branch (almost
> like a todo list) and get to work on the new or changed features.
> Is that making any sense?
> Matt Wynne
> http://blog.mattwynne.net
> http://www.songkick.com
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081216/cb89ced7/attachment.html>

More information about the rspec-users mailing list