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.
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.
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?
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
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
