Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [eclipse-dev] Exporting the Eclipse project's development/rel ease engineering process


>>It sounds like many of your practices, like continuous integration, smoke tests & frequent releases, coincide with those of agile >>methodologies such as XP. Is that the case? Did you use XP, Scrum, etc. as a model or a starting point?

We didn't explicitly take any methodology or model as a starting point; we just looked at what wasn't working, got some ideas that seemed to fit, and tried it.

Traditionally OTI has many work practices and attitudes that are similar to what people are referring to now as XP (we just weren't clever enough to give it a cool name and write books about it <grin>).  I'm not up enough on XP to detail the intersection, but clearly the ideas and philosophy are related which shouldn't be surprising because the cultures are related in their roots  (e.g. ex smalltalk programmers believing in iterative development).

Cheers,
Kevin




Eric McIntyre <EMcIntyre@xxxxxxxxxxxxxxxxx>
Sent by: eclipse-dev-admin@xxxxxxxxxxx

07/10/2003 04:31 PM
Please respond to eclipse-dev

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



It sounds like many of your practices, like continuous integration, smoke tests & frequent releases, coincide with those of agile methodologies such as XP. Is that the case? Did you use XP, Scrum, etc. as a model or a starting point?
 
I'm also curious to know more about your infrastructure team. Is infrastructure their full-time responsibility? Are the people typically developers or sysadmins?
 
Eric McIntyre
Java Developer
Island Pacific
-----Original Message-----
From:
Kevin McGuire [mailto:Kevin_McGuire@xxxxxxxxxx]
Sent:
Thursday, July 10, 2003 10:38 AM
To:
eclipse-dev@xxxxxxxxxxx
Subject:
Re: [eclipse-dev] Exporting the Eclipse project's development/release engineering process


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



Back to the top