On Apr 7, 2011, at 8:21 AM, laurent laffont wrote: > > On Wed, Apr 6, 2011 at 10:32 PM, Eliot Miranda <[email protected]> > wrote: > > > On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <[email protected]> > wrote: > > On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <[email protected]> wrote: > Planning is also important. > > Time is good, but another thing is i think we should think about, > what features we want to be in new release, and do not release until > they delivered. > > I don't really like this. I prefer rhythm, agility. Timeboxing enables > maximum value in each release. If a feature is really important, it will be > on time. If not on time, it means it was no so important. > > I couldn't disagree more. Especially with VisualWorks time-boxing has caused > problems with quality and delivery of functionality. Fundamentally there is > no point putting out a release for the sake of it. A release is about > functionality, both new functionality and bug fixes. Without either of these > there is absolutely no point in releasing anything beyond marketing. Yes, > during a release one can make the call that because a subset of the > functionality will arrive much later than the rest of the functionality it > makes sense for that late functionality to slip the release and arrive in a > later one. But that doesn't imply putting out an essentially empty release > for the sake of promptness. > > > Let me talk about my experience. Quality may suffer with timeboxing without > continuous integration and good test coverage. > > CI + tests enable timeboxing because I can maintain high quality level. And > now we have CI it's wonderful. > > As a user, I like software developed with fixed iterations because I know > exactly when it wil be released, plan upgrades and validations. I'm easily in > sync. > > As a developer I like fixed iterations because > 1/ We care more about quality. Cannot develop all this feature in the > iteration ? do only a part and check that it works well - write missing > tests. Not enough time left to integrate this feature ? Just work on the > many details that we need to fix and integrate the new feature soon in next > iteration.
this is exactly what is happening with the introduction of RPackage :) > > 2/ We maintain energy. No long waiting period of stuff xxxx to be done > without realeasing. The more we wait, the less productive we are. > > 3/ I like to change the planning from "what features this version can't be > released without ?" to "what can we develop in 1 / 3 / 6 months (with high > quality) ?". > > 4/ ok I stop here. > > Even every day at work I'm timeboxing with 25mn iterations (Pomodoro > technique) for several years - I cannot live without now. That makes me > deliver a lot of energy. > > > I've never seen empty release because of fixed iterations. And even if the > release contains only fixed bugs, details adjustment and no new big feature > it's great. Details matters a lot. > > In a former job my team was doing a new features iteration, then a "care > about details iteration", then a new features iteration, and so on.... it was > a lot of fun and worked. > > Indeed I would like try and see if it works with Pharo. I also would like > Pharo to be a reference of modern agile development - that would be a step > forward. > > > Laurent. > > > One thing I do approve of is maintennance releases, where some time after an > initial release one puts out a maintennance release that only contains bug > fixes and no new functionality and I think there are good arguments for and > positive experience with scheduling the maintennance release to arrive at > some fixed time after the first release, e.g. 4 to 6 months. But major > releases must IMO be driven by content. > > best > Eliot > > > Always green test is a must-have. > > > Besides bug fixing and minor improvements, there should be some > functionality which we want to have in new release, > > That should be a goal, but don't delay a release because the feature is not > here. If releases are often ( for example every 3 months), shorter, it won't > be a big problem to wait for the next one. > > I prefer to have a release *now* without my feature and wait 3 months for the > next release than no release and waiting for 3 months more with less and less > energy. > > > Laurent. > > so then you could say: 1.x is better than previous because of A,B,C, > but not because a,b,c ( capital letters is major stuff, while regular > ones is for minor stuff ) :) > > > On 6 April 2011 10:01, Serge Stinckwich <[email protected]> wrote: > > On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont > > <[email protected]> wrote: > >> On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck > >> <[email protected]> wrote: > >>> > >>> Yes!!! totally agree. Now that we release 1.2, I would freeze and release > >>> PharoCore 1.3 beta. Update the link to stable pharo to that, and start > >>> trying to load the dev tools there. > >> > >> +10 > >> And propose a fixed date for release - no compromise, will be release at > >> this date. > > > > +1 > > Timeboxing sounds great. > > Podomoro for software development ;-) > > > > Regards, > > -- > > Serge Stinckwich > > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > > Every DSL ends up being Smalltalk > > http://doesnotunderstand.org/ > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > > > >
