16 Jan
2012
16 Jan
'12
10:14 a.m.
Hi Vincent,
On Mon, Jan 16, 2012 at 10:09 AM, Vincent Massol <vincent(a)massol.net> wrote:
Hi devs,
We've been quite bad at following the release strategy we've defined so far:
timeboxing.
We've been constantly slipping our release dates during all the past releases (and
not by 1 or 2 days, but by 2 weeks or more).
Personally I find this not professional of us and for me it means that the date we give
are just a joke now. I don't even see why we're giving dates since they can only
be misleading to anyone who would act on them… At the current slippage rate, we should
only give a month estimation to have a chance of being correct ;)
There's only one reason we're really slipping
IMO: we've forgotten that we're doing time boxing.
I don't believe this is the only reason, not even the main one. I
don't think 3.4M1 was delayed because we wanted to do more. What I
know is that the build was unstable during the winter holidays when
most of the committers were offline so there wasn't anyone to
investigate and fix the failing tests on CI. You can argue that the
build was unstable because we don't do timeboxing, but even with
timeboxing you can have:
* integration tests failing because a commit in module A (which has
its own unit tests passing) has side effects on module B. If both
modules are under development, with lost of commits, then it's hard to
track which commit broke the build. Jenkins is not very helpful
regarding this.
* flickering functional tests, both due to bad test coding but also
due to the instability of Selenium (I don't feel it 100% reliable).
Let me remind us what time boxing is and how it can be made to work:
* It means releasing on a fixed date and releasing whatever is ready at that date.
* The idea is also to do quick releases so that if a given feature is not in a release
it'll be in the next one coming soon (we used to do 2 to 3 weeks releases at some
points and recently we've been doing instead 3-5 weeks instead)
* The reason for releasing often is because this pushes the bug fixes and new stuff to
users ASAP and thus let them experiment with them and give us feedback (bugs, usability,
etc)
* The way to make timeboxing work is by having automated functional tests so that we can
release safely knowing that our test suite will catch the problems if any. This means that
whenever a commit is done, in the same commit there are tests proving that what is
committed is working (and not several weeks later which would be anti-timeboxing).
* it doesn't mean we cannot have a roadmap. What it means is that we should the
maximum of what is in the roadmap in a given time slot. What's not done doesn't
get released. This means that large features should be divided into small one that will
fit. Developers need to think about what they're doing by constantly checking the
release date and verifying what they can achieve for that date and make absolutely sure
that what they have committed is working for that date (even if what they have committed
is not finished).
* Timeboxing is not about how many men/days you have
available or whether people are on holidays or not. If you have less men/days you do less
work. It doesn't change the release date.
You still need someone do to the release and we aren't that many
committers so if we all take the winter holidays (as it is normal)
then we have to adjust the release date.
Basically you can only do timeboxing if you have good and automated quality control.
The opposite of timeboxing is feature releases which lead to the following:
* People committing not working stuff or without tests because they know they'll have
time to fix it later on before the release (easy to think this since there's no
release date, it's only when the features are done that it'll get released)
* Release date become not important since they keep being pushed since what's
important is to release planned features
* Build failing all the time and developers not caring about it ("it can always be
fixed later when we get close to the release date" - that's easy to say since
there' no fixed release date)
* Users seeing less frequent releases and giving less feedback to developers (thus
helping less)
* In general, quality dropping over time
So we have several choices:
1) Forget timeboxing and do feature-based releases, i.e. we list features and we only
release when they're done
2) Start doing real timeboxing again
I've seen so many projects do 1) in the past with such bad results that for me
there's no doubt that the only good strategy is 2). Especially for an open source
project which has a strong community and we should be releasing stuff regularly and
quickly to this community to get good feedback. Doing timeboxing is also a great way to
improve the quality of our code.
Timeboxing can only work fine if everyone agrees with it (we can revert stuff from a
developer if it breaks things but it's a pain) and believe in the release date, so
we'd need everyone's agreements.
So WDYT, are we ok to resume doing timeboxing and go
back on track?
I'm definitely for timeboxing.
Thanks,
Marius
On my side I'm ok to do it and help enforce it. If we agree we should start now by
releasing RC1 ASAP and give a new date for 3.4 final and release on that date.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs