Re: [eclipse-dev] Exporting the Eclipse project's development/release en

["Kevin McGuire" <Kevin_McGuire@xxxxxxxxxx>]

I imagine you will get different answers to these questions.  From my recollection:

First, I should make it clear that any success we've had is the result of many ideas, from many people, and much discussion and hard work by all. 

Definitely a large part is OTI culture.  We hate shipping late.  We also understand pretty good how to shift gears from being theoretical with big plans early, to being pragmatic and brutal about what is really required in the end game.

The milestone idea came from the notion that shipping is hard, so you should do it more often to make each one less painful (thus distributing the pain). What we were finding in the past was that we would have long spans of unintegrated work, then everything would come together in the last minute as it were.  The problem was that you couldn't quite be sure what the product was going to feel like as a whole until near the end since integration, although occuring along the way, wasn't so well structured and planned.  Also, and perhaps most importantly, that approach is stressful and burns everyone out.    The milestones are based on the idea of getting to a known state and staying there.  This was a blend of existing OTI work practice, what we saw happening with on-line games that delivered new fixes and content on a constant basis, and ideas from several software engineering books, one in particular I recall from Mic!
 rosoft but the title escapes me (somewhat heretical to mention, but I would be remiss in not referencing it in this non-partisan forum).

Another benefit of the milestones is that it gives clear scheduled points where you can coordinate dependencies up/down stream.  Finally, the mini test passes distribute the pain of testing, thus avoiding the long and arduous test passes at the end, and allowed us to stay on course since we always knew what we had.  This reduces the chances of big surprises at the last minute and reduces stress.  By having so many points where we have something working, the community can take it the drops with confidence and participate through bug reports, feedback, fixes, etc.

The first point about culture shouldn't be undersold though.  OTI traditionally has had a culture of avoiding drawn out water fall processes, instead focusing on being nimble, removing obstacles to progress, being prepared to replan as you go (as you learn more), and a determination to ship on time and with quality.  In keeping with this, our 'process' evolved over time.  So we combined many ideas and refined it to meet our particular needs.  Since culture is a subtle function of the people, our 'process' may or may not fit other organizations. 

Cheers,
Kevin

"Ed Burnette" <Ed.Burnette@xxxxxxx> Sent by: eclipse-dev-admin@xxxxxxxxxxx 07/10/2003 11:53 AM Please respond to eclipse-dev

To:        <eclipse-dev@xxxxxxxxxxx>         cc:                 Subject:        [eclipse-dev] Exporting the Eclipse project's development/release engineering process

I've been following the development of Eclipse for some time and I'm continually amazed as the extended team hits each projected milestone and ship date with precision. Until this experience, I was convinced that such a feat was impossible for a software project of any size and complexity.

I've read about the PMC and the published plans and all that, but I've been involved in projects that had plans and leaders that were still significantly later than expected. So... the question is how is this really accomplished? And the immediate follow-up of course is, how can this process be replicated elsewhere?

I'm also interested in where this method of development came from, was it part of OTI's culture from the beginning or did it come from IBM? Did it spring from somebody's head fully formed or evolve over time based on project management research? Does it have a name?

My current thoughts are that the key must be the milestones: immovable dates for stable deliverables every 4 to 6 weeks. There must be something about that predictability that stops feature creep and positively affects the mindsets of the team members. Is that it? What do you think?

The purpose of these questions is to allow the lessons of Eclipse to be brought home to our own groups to improve our own scheduling, quality, and predictability. So thanks in advance for any insights.

--Ed

_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev