Methodology [was] Re: Guinea Pigs [was] Re: EPP [snip]

[Trent Shipley]

On Wednesday 2005-03-16 16:16, Joseph Sinclair wrote:
> I agree with your first point completely.
> Data gathering/requirements definition is definitely appreciated.
> I don't, however, think we should follow the classic "waterfall"
> development model (which is what you allude to with the phases).  It's
> proven to fail in almost all cases (70-90%), and isn't even accepted as
> a valid development model for ISO and SEI certifications any more.

That may be true, but a lot of the vocabulary that come to hand comes from 
other engineering disciplines via waterfall.

For example, we know we do not like the word "requirements", or even 
requirements themselves.  Yet our agile process needs something analogous to 
requirements, what that might be we do not exactly know, nor do we have a 
name for it.

> I stated at the beginning that I wanted to use lightweight/agile
> development methodologies.  This means that we can start the programming
> effort rather early in the process, while analysis/requirements
> gathering is ongoing.  As soon as we have the volunteers to begin
> development, I support sitting down (perhaps virtually), and hashing out
> a rough outline of release 1 (which functionality is first, second,
> etc...), then asking the programmers to volunteer for different
> functionalities (user stories) for the first iteration (about 2-3
> weeks).  At the end of the first iteration the process is repeated (in
> brief) to select the activities for the next iteration.  This continues
> until release 1 is complete, when the plan for release 2 is worked out.
> This is very similar to how most open-source projects work, and has
> proven effective in other arenas as well.

We can start the programming basically now.

The question is on what basis.

I have suggested agile programming JUST the Installfest automation, then 
moving on.

Joseph wants to go for a more strategic, clean top-down design.  

Despite Joseph's education and experience I cannot understand this.  What is 
the point of a perfectly elegant design if it is perfectly unsuited to the 
domain?  I am really, really skeptical that agile methodologies will come to 
the rescue.  

Even in a best case how is master design based agility better than case based 
agility when you have very limited knowledge of the domain (even given the 
financial freedom of a FOSS project)?

Armchair data
Master design 0
Some research
Master design 1
Some feedback, more research
Master design 2
*
*


- - - - - 

armchair data + Installfest case
Installfest design and solution.

Wedding planner case
Wedding planner design and solution.
optionally includes new Installfest solution

*
*

Presidential inauguration case
Presidential inauguration design and solution
optionally subsumes new solutions for previous cases.



> At this point the biggest question on this project is not what do we
> need to build, it's is anyone willing to build it.  Until we have
> programming volunteers, we're building strawmen.

Pick your tools.  I'll do my best to contribute.  Even if I'm the most junior 
programmer in the group, I like to code but when it comes to programming 
projects I'm not exactly a self-starter.