On Mon, 2009-04-20 at 13:26 -0400, Dale Worley wrote:
> On Sun, 2009-04-19 at 21:54 -0400, Scott Lawrence wrote:
> > Predicting when things will be done is very hard, but hitting a specific
> > date set months in advance is even harder. Personally, I'd prefer never
> > to set or publish a date at all, but instead to try to select a set of
> > features that can be made stable together in a short 4-6 month cycle,
> > and release them when they are ready. Anything that might take longer
> > happens only on a branch, but maintaining a branch is extra work too so
> > it's a balancing act.
>
> There is a perennial urge to shorten the release cycle -- 3 cycles per
> years is often mentioned. Of course, that means that each cycle would
> contain fewer new features. But in practice, it seems to be difficult
> to have such short cycles. Are there overheads that make shorter cycles
> harder? Is the problem that we do not organize the work correctly?
I think that there has been difficulty with:
* Keeping the list of 'desired' features for a release short
enough that the odds of all of them coming in on time are
reasonable (if there's a 20% chance of each item slipping, then
you only need 4 such before your odds of hitting the date are
down to 41% - and I've never met a programmer who consistently
met schedules 80% of the time).
* Dedicating people to 'overlapped' development (that is, get some
people working on changes that will take a long time targeted
for release N+1 while others are doing release N).
_______________________________________________
sipx-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipx-dev
Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
