Also, if people are into this sort of thing, I would be up for helping build it.
On Tue, Dec 16, 2008 at 3:17 AM, Mischa Fierer <f.mis...@gmail.com> wrote: > 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
