On Wed, Apr 22, 2015 at 10:46 AM, Daan Hoogland <daan.hoogl...@gmail.com> wrote:
> On Wed, Apr 22, 2015 at 10:29 AM, Erik Weber <terbol...@gmail.com> wrote: > > On Wed, Apr 22, 2015 at 9:49 AM, Stephen Turner < > stephen.tur...@citrix.com> > > wrote: > > > >> I have to admit I'm a bit sceptical because when we did have a > four-month > >> release cycle, we never seemed to manage to meet it. Personally I think > >> six-monthly might be easier. > >> > >> Having said that, part of the problem was the long close-down period > where > >> we kept finding critical bugs, so more automated testing might help to > >> shorten the cycle. > >> > >> > > > > - Shorter cycle means that it's less of a problem to miss a deadline, > > meaning you can spend more time on QA. > > - Longer cycle means that it could be critical to meet the deadline, > > meaning you might end up doing less QA while stressing to get your > feature > > in. > > > > My $.002 > > Yes, Eric and the amount of qa needed is less as well. Bare with me > for a little rant here. > > When less new features are introduced less new interdependencies are > introduced. I could try and expand on this but people make phd on the > subject so that would be presumptuous of me. > > un-educated guess is (m + n)! - m! > where m is old features and n is new features > > example: > 1 old feature + 1 new feature mean 1 check to see if they (still) work > 1 old feature + 2 new features means 3 checks to see if they all work > 2 + 2 = 6 of which only 1 is old and should be fine > 2 + 3 = 10, see the n! progressing ;) > > > this is an over simplification as the complexity of features comes in > play as well. I make them out for being function points here. those > are fables of course. > > thanks for baring that. > > I'm all with you on this Daan. Just for the record, my notion of QA was meant at the feature developer, ie. that they could use more time on test coverage etc. without having to worry that much about feature freeze dates. -- Erik
