A few other things... In the interface that I was describing, it would solve several problems to have something like:
Given I'm a client When I follow "new story" And I drag in "Given I am a Pet Owner" And I press "new action" And I select "When I follow" And I fill in "follows_what_link" with "Buy another dog" And I press "new result" And I select "Then i should see" And I fill in "see_what" with "Say hello to your new dog" And I press "Save feature" Then I should see "Your feature has been saved!" When I select "mischa -- developer" When I press "Send feature" Then I should see "feature sent to mischa" Obviously a bit hacky of a feature, but does everyone see what I'm getting at? M On Tue, Dec 16, 2008 at 3:08 AM, Mischa Fierer <f.mis...@gmail.com> wrote: > 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 > to. > > 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. > > M > > > > > On Tue, Dec 16, 2008 at 12:42 AM, Matt Wynne <m...@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@rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > >
_______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
