[
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?
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
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