I know resources are limited, one of the few certainties in life. But...
Just like with a release cycle people can rely upon, the should be able to rely on what
will be in that release. In many projects I worked on, knowing 6 weeks before a release
that certain functionality that was scheduled to be in that release will not be in it is
not something I can work with.
I know consultancy jobs can come unexpected, that is not the problem, just like huge
internal discussions. But things like Javaworld, JBoss World, Devoxx and other
converences/talks could, no *should* be taken into account when planning.
Looking at the past releases, each time issues were slipping to the next release, it did
not happen often that there was a plethora of time. So I'd like to propose two
- Try to define (as good as possible, taking the above into account) plan at the beginning
of e.g. release 4.3 the issues for 4.4, not plan them at the beginning (or half way as
happened now) of 4.4
- Take a little more time, so plan less 'issues'
This would make for an even more reliable release schedule (less irritation) and might get
others to step in if they think it is to long of for it to be fixed.
Ofcourse another solution would be to get more resources ;-)
View the original post :
Reply to the post :