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
