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

[Joseph Sinclair]

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.

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.

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.

==Joseph++


Eric "Shubes" wrote:

> <<SNIP>>
>
> Whew! I was afraid things were getting a bit off track. I think that 
> it's important for project participants to have a common understanding 
> of and agreement on the development methodology that will be used. My 
> impression thus far is that there has been a somewhat of a failure to 
> (effectively) communicate, though there's been no lack of effort. 
> Kudos to everyone.
>
> I think that Trent is on the right track here. Whether you call it 
> data gathering, requirements definition, research or story cards, to 
> me it's all the same thing - learning (and documenting) what the user 
> does and how it's done. Not a fun task for (some) techies, it still 
> needs to be done (a system can't be developed in a vacuum). This is 
> the architectural phase of development, where the goal is to describe 
> what it is that is going to be addressed and for whom. Such a 
> description should be largely void of technology (which gets added in 
> the Design phase), in the same way that an architect's drawing is void 
> of construction materials (although the architect would have ideas). 
> The product of this phase will provide input necessary (required) for 
> subsequent phases of development (Analysis, Design, 
> Construction/Testing, Implementation).
>
> IMHO, most of the other subjects of discussion (e.g. platform, 
> integration)) are premature.
>
> Keep in mind, the "system" is not just the technology, but includes 
> users and non-automated processes as well. A good automated system is 
> usually a good manual system that's been automated.
>
> I like Trent's start here: Identify the universe of users, then 
> classify and whittle it down. Learn what's out there, then choose 
> where to focus, and go into more detail (what they do, how they do 
> it). I think that this is the right thing to do at this point, and 
> deserves as much attention and support as we can muster. So anybody 
> have any ideas on how to target research?