Hi folks, Cucumber has become popular a lot quicker than I had anticipated. Still, with its plain text nature it is still limited to programmers (in most teams). I want to close the gap between customers/product owners/business analysts and programmers, and I''m convinced that a fat client is needed to achieve this. Something that lets people browse, edit and run features inside a friendly user interface. So I''m asking you - what would this user interface be like? How do people want to access it and use it? Cheers, Aslak -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/rspec-users/attachments/20081209/968c7aa0/attachment-0001.html>
On 9 Dec 2008, at 09:43, aslak hellesoy wrote:> So I''m asking you - what would this user interface be like? How do > people want to access it > and use it?I was considering writing (but will probably never have time for) a simple writeboard/wiki-style site that is linked to a git repository. So you point the app at a clone of your git repository''s features folder, people can browse the folder, edit a feature in the browser (and view the history) and then push them straight back into the repo. (I noticed someone else had posted a writeboard-based system earlier too) B Rahoul Baruah Web design and development: http://www.3hv.co.uk/ Nottingham Forest: http://www.eighteensixtyfive.co.uk/ Serious Rails Hosting: http://www.brightbox.co.uk/ Lifecast: http://www.madeofstone.net/
Hi Aslak, Below are my manager''s recommendations: "If you take a look at Twist, Thoughtworks have already done the hard work in gleaning the requirements for this. Something Twist like would be well received. http://studios.thoughtworks.com/twist-agile-test-automation Their implementation is eclipse based." Thanks Aidy 2008/12/9 aslak hellesoy <aslak.hellesoy at gmail.com>:> Hi folks, > > Cucumber has become popular a lot quicker than I had anticipated. > Still, with its plain text nature it is still limited to programmers (in > most teams). > > I want to close the gap between customers/product owners/business analysts > and programmers, > and I''m convinced that a fat client is needed to achieve this. Something > that lets people > browse, edit and run features inside a friendly user interface. > > So I''m asking you - what would this user interface be like? How do people > want to access it > and use it? > > Cheers, > Aslak > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users >
On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah <baz at madeofstone.net> wrote:> > On 9 Dec 2008, at 09:43, aslak hellesoy wrote: > > So I''m asking you - what would this user interface be like? How do people >> want to access it >> and use it? >> > > > I was considering writing (but will probably never have time for) a simple > writeboard/wiki-style site that is linked to a git repository. > > So you point the app at a clone of your git repository''s features folder, > people can browse the folder, edit a feature in the browser (and view the > history) and then push them straight back into the repo. > > (I noticed someone else had posted a writeboard-based system earlier too) >Yes, it''s called Remote Feature: http://github.com/aslakhellesoy/cucumber/wikis/related-tools http://github.com/mhennemeyer/remote_feature/tree/master Aslak> > B > > Rahoul Baruah > Web design and development: http://www.3hv.co.uk/ > Nottingham Forest: http://www.eighteensixtyfive.co.uk/ > Serious Rails Hosting: http://www.brightbox.co.uk/ > Lifecast: http://www.madeofstone.net/ > > > > > > > _______________________________________________ > 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/20081209/f7e13c8d/attachment.html>
Hey Aslak, Doesn''t this sound a bit like your Kipling project, which we spoke about at QCon London, back in March? ;) (http://gitorious.org/projects/kipling) I think it would be a great app to have, which would work well inside a web browser, rather than a fat client that customers and managers have to download...?>From my recollection, you were wanting to keep Kipling quite sparse and textbased, in contrast to the Thoughtworks product which Aidy mentioned in this thread. I would be interested in getting involved with this, if I could be helpful in any way :) Steven On Tue, Dec 9, 2008 at 11:15 AM, aslak hellesoy <aslak.hellesoy at gmail.com>wrote:> > > On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah <baz at madeofstone.net>wrote: > >> >> On 9 Dec 2008, at 09:43, aslak hellesoy wrote: >> >> So I''m asking you - what would this user interface be like? How do people >>> want to access it >>> and use it? >>> >> >> >> I was considering writing (but will probably never have time for) a simple >> writeboard/wiki-style site that is linked to a git repository. >> >> So you point the app at a clone of your git repository''s features folder, >> people can browse the folder, edit a feature in the browser (and view the >> history) and then push them straight back into the repo. >> >> (I noticed someone else had posted a writeboard-based system earlier too) >> > > Yes, it''s called Remote Feature: > http://github.com/aslakhellesoy/cucumber/wikis/related-tools > http://github.com/mhennemeyer/remote_feature/tree/master > > Aslak > > >> >> B >> >> Rahoul Baruah >> Web design and development: http://www.3hv.co.uk/ >> Nottingham Forest: http://www.eighteensixtyfive.co.uk/ >> Serious Rails Hosting: http://www.brightbox.co.uk/ >> Lifecast: http://www.madeofstone.net/ >> >> >> >> >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > _______________________________________________ > 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/20081209/574eec64/attachment-0001.html>
On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <shingler at gmail.com> wrote:> Hey Aslak, > > Doesn''t this sound a bit like your Kipling project, which we spoke about at > QCon London, back in March? ;) > > (http://gitorious.org/projects/kipling) >A little bit, but the idea with Kipling was to make something similar to ThoughtWorks Mingle or Pivotal Tracker, which are tools to manage stories, iterations, estimates, burndown etc. My goal with a fat Cucumber client is different (although it clearly intersects): * Browse features * Edit features * Run features So I''m thinking more along the lines of Fitnesse, but with a more business-friendly UI, and focus on Cucumber (of course). Essentially - I want this to be primarily a tool that replaces TextMate and the CLI for editing and running features, and not so much a Scrum/XP planning tool. And the target audience is not us programmers (most of us are happy in TM/CLI) - it''s the non-techies that know Word and Excel only (and are experts in their business'' domain). Aslak> I think it would be a great app to have, which would work well inside a web > browser, rather than a fat client that customers and managers have to > download...? > > From my recollection, you were wanting to keep Kipling quite sparse and > text based, in contrast to the Thoughtworks product which Aidy mentioned in > this thread. > > I would be interested in getting involved with this, if I could be helpful > in any way :) >> Steven > > > On Tue, Dec 9, 2008 at 11:15 AM, aslak hellesoy <aslak.hellesoy at gmail.com>wrote: > >> >> >> On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah <baz at madeofstone.net>wrote: >> >>> >>> On 9 Dec 2008, at 09:43, aslak hellesoy wrote: >>> >>> So I''m asking you - what would this user interface be like? How do >>>> people want to access it >>>> and use it? >>>> >>> >>> >>> I was considering writing (but will probably never have time for) a >>> simple writeboard/wiki-style site that is linked to a git repository. >>> >>> So you point the app at a clone of your git repository''s features folder, >>> people can browse the folder, edit a feature in the browser (and view the >>> history) and then push them straight back into the repo. >>> >>> (I noticed someone else had posted a writeboard-based system earlier too) >>> >> >> Yes, it''s called Remote Feature: >> http://github.com/aslakhellesoy/cucumber/wikis/related-tools >> http://github.com/mhennemeyer/remote_feature/tree/master >> >> Aslak >> >> >>> >>> B >>> >>> Rahoul Baruah >>> Web design and development: http://www.3hv.co.uk/ >>> Nottingham Forest: http://www.eighteensixtyfive.co.uk/ >>> Serious Rails Hosting: http://www.brightbox.co.uk/ >>> Lifecast: http://www.madeofstone.net/ >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> rspec-users mailing list >>> rspec-users at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/rspec-users >>> >> >> >> _______________________________________________ >> rspec-users mailing list >> rspec-users at rubyforge.org >> http://rubyforge.org/mailman/listinfo/rspec-users >> > > > _______________________________________________ > 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/20081209/12ea62ed/attachment.html>
On 9 Dec 2008, at 15:11, aslak hellesoy wrote:> On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <shingler at gmail.com> > wrote: > Hey Aslak, > > Doesn''t this sound a bit like your Kipling project, which we spoke > about at QCon London, back in March? ;) > > (http://gitorious.org/projects/kipling) > > A little bit, but the idea with Kipling was to make something > similar to ThoughtWorks Mingle or Pivotal Tracker, which are tools > to manage stories, iterations, estimates, burndown etc. > > My goal with a fat Cucumber client is different (although it clearly > intersects): > * Browse features > * Edit features > * Run featuresI think that some kind of autocomplete / syntax highlighting that understands the currently-implemented set of step matchers would be really useful too - I already find myself wondering whether I''ve already implemented a step as I write the scenario.> So I''m thinking more along the lines of Fitnesse, but with a more > business-friendly UI, and focus on Cucumber (of course). > > Essentially - I want this to be primarily a tool that replaces > TextMate and the CLI for editing and running features, and not so > much a Scrum/XP planning tool. And the target audience is not us > programmers (most of us are happy in TM/CLI) - it''s the non-techies > that know Word and Excel only (and are experts in their business'' > domain).It would be good if it could integrate into a a planning tool though - offer an API that returned the number of Running Tested Features, etc.> I think it would be a great app to have, which would work well > inside a web browser, rather than a fat client that customers and > managers have to download...?+1 Matt Wynne http://blog.mattwynne.net http://www.songkick.com
Matt Wynne wrote:> > On 9 Dec 2008, at 15:11, aslak hellesoy wrote: > >> On Tue, Dec 9, 2008 at 3:52 PM, steven shingler <shingler at gmail.com> >> wrote: >> Hey Aslak, >> >> Doesn''t this sound a bit like your Kipling project, which we spoke >> about at QCon London, back in March? ;) >> >> (http://gitorious.org/projects/kipling) >> >> A little bit, but the idea with Kipling was to make something similar >> to ThoughtWorks Mingle or Pivotal Tracker, which are tools to manage >> stories, iterations, estimates, burndown etc. >> >> My goal with a fat Cucumber client is different (although it clearly >> intersects): >> * Browse features >> * Edit features >> * Run features > > I think that some kind of autocomplete / syntax highlighting that > understands the currently-implemented set of step matchers would be > really useful too - I already find myself wondering whether I''ve > already implemented a step as I write the scenario. > >> So I''m thinking more along the lines of Fitnesse, but with a more >> business-friendly UI, and focus on Cucumber (of course). >> >> Essentially - I want this to be primarily a tool that replaces >> TextMate and the CLI for editing and running features, and not so >> much a Scrum/XP planning tool. And the target audience is not us >> programmers (most of us are happy in TM/CLI) - it''s the non-techies >> that know Word and Excel only (and are experts in their business'' >> domain). > > It would be good if it could integrate into a a planning tool though - > offer an API that returned the number of Running Tested Features, etc. > >> I think it would be a great app to have, which would work well inside >> a web browser, rather than a fat client that customers and managers >> have to download...? >Running like a web based application through something like like Adobe Air or Mozilla Prisim would be nice. (Though these are reliant on downloading plugins).> +1 > > 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 >
steven shingler wrote:> Hey Aslak, > > Doesn''t this sound a bit like your Kipling project, which we spoke > about at QCon London, back in March? ;) > > (http://gitorious.org/projects/kipling) > > I think it would be a great app to have, which would work well inside > a web browser, rather than a fat client that customers and managers > have to download...?+1, I think keeping it in the browser will work well for most situations. One option is to make it a flex app and could then be used as a stand-alone Air app. WDYT? I have been thinking about the requirements for such a project and I think having it git-powered would be great. Having the stakeholder to be able to edit features and have the changes show up in a remote branch automatically would be a great feature IMO. If it is powered off of git we also get versioning and a lot of other stuff for free. (I would recommend watching Scott Chacoon''s presentation on using git in this way from ruby conf: http://rubyconf2008.confreaks.com/using-git-in-ruby-applications.html) Anyways, thats my two cents. I would argue that most business people these days are just as, if not more, comfortable in a browser than they are in Excel as long as the UI is good. Of course, having clients for both would be ideal. :) -Ben> > From my recollection, you were wanting to keep Kipling quite sparse > and text based, in contrast to the Thoughtworks product which Aidy > mentioned in this thread. > > I would be interested in getting involved with this, if I could be > helpful in any way :) > > Steven > > > On Tue, Dec 9, 2008 at 11:15 AM, aslak hellesoy > <aslak.hellesoy at gmail.com <mailto:aslak.hellesoy at gmail.com>> wrote: > > > > On Tue, Dec 9, 2008 at 11:47 AM, Rahoul Baruah > <baz at madeofstone.net <mailto:baz at madeofstone.net>> wrote: > > > On 9 Dec 2008, at 09:43, aslak hellesoy wrote: > > So I''m asking you - what would this user interface be > like? How do people want to access it > and use it? > > > > I was considering writing (but will probably never have time > for) a simple writeboard/wiki-style site that is linked to a > git repository. > > So you point the app at a clone of your git repository''s > features folder, people can browse the folder, edit a feature > in the browser (and view the history) and then push them > straight back into the repo. > > (I noticed someone else had posted a writeboard-based system > earlier too) > > > Yes, it''s called Remote Feature: > http://github.com/aslakhellesoy/cucumber/wikis/related-tools > http://github.com/mhennemeyer/remote_feature/tree/master > > Aslak > > > > B > > Rahoul Baruah > Web design and development: http://www.3hv.co.uk/ > Nottingham Forest: http://www.eighteensixtyfive.co.uk/ > Serious Rails Hosting: http://www.brightbox.co.uk/ > Lifecast: http://www.madeofstone.net/ > > > > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org> > http://rubyforge.org/mailman/listinfo/rspec-users > > > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org <mailto:rspec-users at rubyforge.org> > http://rubyforge.org/mailman/listinfo/rspec-users > > > ------------------------------------------------------------------------ > > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
>> I think it would be a great app to have, which would work well >> inside a web browser, rather than a fat client that customers and >> managers have to download...? > +1, I think keeping it in the browser will work well for most > situations. One option is to make it a flex app and could then be > used as a stand-alone Air app. WDYT? > > I have been thinking about the requirements for such a project and I > think having it git-powered would be great. Having the stakeholder > to be able to edit features and have the changes show up in a remote > branch automatically would be a great feature IMO. If it is powered > off of git we also get versioning and a lot of other stuff for > free. (I would recommend watching Scott Chacoon''s presentation on > using git in this way from ruby conf: http://rubyconf2008.confreaks.com/using-git-in-ruby-applications.html) > > Anyways, thats my two cents. I would argue that most business > people these days are just as, if not more, comfortable in a browser > than they are in Excel as long as the UI is good. Of course, having > clients for both would be ideal. :)+1 to having it in browser as the first priority. People are more and more comfortable all the time in their browsers. Personally, I''m not sure I would want it tied to git explicitly - we haven''t quite made that jump at work yet. On the other hand, it should be easy to put hooks into it to auto-commit changes to pretty much any type of repository. -tim
On 9 Dec 2008, at 09:43, aslak hellesoy wrote:> Hi folks, > > Cucumber has become popular a lot quicker than I had anticipated. > Still, with its plain text nature it is still limited to programmers > (in most teams). > > I want to close the gap between customers/product owners/business > analysts and programmers, > and I''m convinced that a fat client is needed to achieve this. > Something that lets people > browse, edit and run features inside a friendly user interface. > > So I''m asking you - what would this user interface be like? How do > people want to access it > and use it?We have a person filling the ''Product Owner'' role who is completely non-technical. I think it would be nice if there was a way for her to be able to do this: * fire up the client * choose ''open project'' * enter the URL to the git repo where the project lives * then see a nice overview of all the features * be able to print off features for taking to meetings, reading on the train etc, nicely formatted * be able to edit features and easily push the changes back to the git repo To me, this is more important than being able to run them. I don''t think non-techie users need to be able to run features as they won''t be able to do anything about it when they inevitably fail. I also hate the idea of having to set up Ruby, gems etc on a non-techie person''s computer. It''s better, IMO, if the tool makes it easy for them to push their changes into a git repo where they can either be swept into the main dev fork / branch, or automatically run using CI, et etc. So that''s where I think the focus of such a tool should be - browsing, reviewing and editing features rather than executing them, and with some SCM integration to make all that easier for non-techies. I do think that eventually the ability to run features will become important too, but I would like to see this side of the problem solved first. Obviously there''s a dependency on git in what I''m suggesting, but I''m sure it would be easy enough to plug in other SCMs if that was popular enough. Matt Wynne http://blog.mattwynne.net http://www.songkick.com
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 the only thing that would be hard at all would be the conflict resolution from if/when a normal git user update a spec. -Mike Matt Wynne wrote:> > On 9 Dec 2008, at 09:43, aslak hellesoy wrote: > >> Hi folks, >> >> Cucumber has become popular a lot quicker than I had anticipated. >> Still, with its plain text nature it is still limited to programmers >> (in most teams). >> >> I want to close the gap between customers/product owners/business >> analysts and programmers, >> and I''m convinced that a fat client is needed to achieve this. >> Something that lets people >> browse, edit and run features inside a friendly user interface. >> >> So I''m asking you - what would this user interface be like? How do >> people want to access it >> and use it? > > We have a person filling the ''Product Owner'' role who is completely > non-technical. > > I think it would be nice if there was a way for her to be able to do this: > * fire up the client > * choose ''open project'' > * enter the URL to the git repo where the project lives > * then see a nice overview of all the features > * be able to print off features for taking to meetings, reading on > the train etc, nicely formatted > * be able to edit features and easily push the changes back to the > git repo > > To me, this is more important than being able to run them. I don''t think > non-techie users need to be able to run features as they won''t be able > to do anything about it when they inevitably fail. I also hate the idea > of having to set up Ruby, gems etc on a non-techie person''s computer. > It''s better, IMO, if the tool makes it easy for them to push their > changes into a git repo where they can either be swept into the main dev > fork / branch, or automatically run using CI, et etc. > > So that''s where I think the focus of such a tool should be - browsing, > reviewing and editing features rather than executing them, and with some > SCM integration to make all that easier for non-techies. I do think that > eventually the ability to run features will become important too, but I > would like to see this side of the problem solved first. > > Obviously there''s a dependency on git in what I''m suggesting, but I''m > sure it would be easy enough to plug in other SCMs if that was popular > enough. > > 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
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 / conflictsCorrect 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> Matt Wynne wrote: >> On 9 Dec 2008, at 09:43, aslak hellesoy wrote: >>> Hi folks, >>> >>> Cucumber has become popular a lot quicker than I had anticipated. >>> Still, with its plain text nature it is still limited to >>> programmers (in most teams). >>> >>> I want to close the gap between customers/product owners/business >>> analysts and programmers, >>> and I''m convinced that a fat client is needed to achieve this. >>> Something that lets people >>> browse, edit and run features inside a friendly user interface. >>> >>> So I''m asking you - what would this user interface be like? How >>> do people want to access it >>> and use it? >> We have a person filling the ''Product Owner'' role who is >> completely non-technical. >> I think it would be nice if there was a way for her to be able to >> do this: >> * fire up the client >> * choose ''open project'' >> * enter the URL to the git repo where the project lives >> * then see a nice overview of all the features >> * be able to print off features for taking to meetings, >> reading on the train etc, nicely formatted >> * be able to edit features and easily push the changes back to >> the git repo >> To me, this is more important than being able to run them. I don''t >> think non-techie users need to be able to run features as they >> won''t be able to do anything about it when they inevitably fail. I >> also hate the idea of having to set up Ruby, gems etc on a non- >> techie person''s computer. It''s better, IMO, if the tool makes it >> easy for them to push their changes into a git repo where they can >> either be swept into the main dev fork / branch, or automatically >> run using CI, et etc. >> So that''s where I think the focus of such a tool should be - >> browsing, reviewing and editing features rather than executing >> them, and with some SCM integration to make all that easier for >> non-techies. I do think that eventually the ability to run >> features will become important too, but I would like to see this >> side of the problem solved first. >> Obviously there''s a dependency on git in what I''m suggesting, but >> I''m sure it would be easy enough to plug in other SCMs if that was >> popular enough. >> 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 > _______________________________________________ > rspec-users mailing list > rspec-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/rspec-users
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? > bartzWhat 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
On 16-dec-2008, at 9:42, Matt Wynne 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.That''s what I missed, I guess :). rake features --as-blissfully-ignorant-client anyone?> 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?Yep! thanks, bartz
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 <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>
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.mischa at 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 <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/70db1c89/attachment.html>
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.mischa at 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.mischa at 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 <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/392cb6c3/attachment-0001.html>
>>> 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> 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. I was thinking the same thing with my original comment about letting people edit the features. I didn''t think it fully through though. In our distributed environment we typically have people discussing stories / specs what have you over vnc or over the phone or over email and they change until they are ''accepted''. I was thinking that allowing this type of interaction in this tool before the specs are actually ''accepted''. eg keep them pending until ''accepted''/greenlit. Having developers pull them in would be another way as well. Perhaps ''accepting'' could be done with pull requests. The accepting / pulling paradigm would depend on how you wanted to handle half done specs and not yet implemented features. Please bear with my terminology as I''m 1/2 way in the test::unit world. -Mike