ryanb wrote:Just a crazy idea, perhaps you could use Basecamp and somehow use the API to handle whatever Basecamp lacks.
I looked at Basecamp briefly before posting this. However while it would handle my to-do list needs, I don't think it hits anything else. And perhaps I'm using the wrong term for what I'm looking for -- its not so much a project management tool as an "agile developer control panel". Interperson communication (Basecamp's primary use-case) is not as important -- I guess because I've realized that most of my projects are single-person efforts.
NielsenE wrote:-- Story/Use-Case list with some hook to project's acceptence/integration testing
I'm not exactly sure how that would work, but it sounds very intriguing. 
This is actually the primary thing I'm looking for ... I can survive with my scrap paper to-do lists, though it would be nice to have the list accessible at different places without carrying around scraps of paper.
How I think it could work (version 1)
1. Story name = integration test name (with suitable filesystem-required inflection conventions)
2. Simple red/green indicators next to each story base on the results of that test
3. The story has a textual description (of course)
4. Stories can be assigned to cycles/interations/releases (whatever term you like), optional
The next step would be to see if its possible to slightly codify the textual description into the DSL for the integration tests -- I know I've seen similar things done in Java and PHP. The DSL would need to be rather complete, initially, for it to be useful, otherwise you have to cycle between writing part of your story and then writing the code behind it... I'd want this to be DRY after all -- the story should be the definitive place describing the acceptence test -- with the acceptence test autogenerated.
Finally it would be nice to have some percentage of progress towards the story instead of just the all nothing -- perhaps a hacked integration tester that forces all to pass initially so that it knows how many total assertions are contained along the test, that it can compare with the number of actual passes. (See howing most acceptence/integration tests are multiple request, errors early on will kill the whole test, versus unit tests where each failure only stops the current test method.... integration tests are normally only one long method)
My RoR journey -- thoughts on learning RoR and lessons learned in applying TDD and agile practices.
