[RT] Planning

[Daniel Fagerstrom <da...@nada.kth.se>]

This is a call for start using Bugzilla (or possibly JIRA) for planning 
again. I'm aware that my fierce critisism about our previous habit of, 
IMO, creating unrealistic release plans, might be one of several reasons 
for our dereased use of Bugzilla for planning. Now I'm start to see the 
need for more organized planning for keeping track on what needs to be 
done to get real blocks (and other things) working.

So here are some ideas about how to get realistic plans:

* Plan at block and feature level: Or stating it negatively: avoid 
unecesary dependencies. In the past we have stated things like: 2.2 
should contain real blocks, VPCs and stable CForms. While it certainly 
would be nice to have, these things are not dependent of each other and 
it just complicates life by making it seem like they have anything with 
each other to do. Much better is to have separate and as independent 
plans as possible for specific blocks and or features. This will be more 
helpful and easy to grasp for people who have the itch to implement 
something we have talked about for a while.

* Create incremental and evolutionary plans: From our experience of the 
long path towards real blocks (and other things), it is very complicated 
to get any traction from plans that require us to e.g. switch component 
management and invent completely new technologies before even get to a 
point where we can start developing something that is useful in itself. 
Deliver one useful feature at the time without needing start a research 
branch makes it much more likely that we get somewhere.

* Avoid coupling features to a certain release number: While the habit 
to write roadmaps for each release seem to work nice in some 
communities, it doesn't seem to work in ours. Possibly because some of 
our todo items have been to complicated and research oriented. For short 
term planning, like deciding what should be part of the release a month 
from now, coupling todo items to a release might be useful. But for long 
term planning it seem less usefull as our interests might change during 
the period. It is also common that we agree about something being 
important, but no one actually have the itch to do something about it 
(don't want to get Ralph going by mentioning the stabilization of CForms 
;) ).

* Replan and prioritize: A plan only represent our knowledge, interests 
and priorities at a certain point in time. As we and the world around us 
develops, so must our plans and priorities. Also I think that when our 
release dates start to slip (like a couple of years or so ;) ), it is 
better to lower our requirements and schedule some of the items to 
later, than to let the plan continue to slip. Remember: if a bug doesn't 
get fixed or a feature doesn't get implemented, it doesn't have to mean 
that we are a bunch of bad and lazy people without responsibility ;) It 
might mean that the bug or feature wasn't that important.

WDYT?

/Daniel

Re: [RT] Planning

[Joerg Heinicke <jo...@gmx.de>]

On 24.09.2005 13:17, Daniel Fagerstrom wrote:

> WDYT?

What's the actual problem you want to solve? Ok, we tried to use 
Bugzilla as project management tool and it did not really get started. 
But do we really have problems with project management? Do we need 
rock-solid project plans? Starting with unrealistic goals and later 
adapting them worked not that bad IMO.

Jörg