Re: [Pharo-project] On fixed release planning [was: Actions done in 1.3]
On Wed, Apr 6, 2011 at 10:32 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont@gmail.com
wrote:
On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua@gmail.com>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. 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 <serge.stinckwich@gmail.com> wrote:
On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont <laurent.laffont@gmail.com> wrote:
On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck <marianopeck@gmail.com> 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.
On Apr 7, 2011, at 8:21 AM, laurent laffont wrote:
On Wed, Apr 6, 2011 at 10:32 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Wed, Apr 6, 2011 at 1:30 AM, laurent laffont <laurent.laffont@gmail.com> wrote:
On Wed, Apr 6, 2011 at 10:17 AM, Igor Stasenko <siguctua@gmail.com> 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 <serge.stinckwich@gmail.com> wrote:
On Wed, Apr 6, 2011 at 12:56 PM, laurent laffont <laurent.laffont@gmail.com> wrote:
On Tue, Apr 5, 2011 at 10:49 PM, Mariano Martinez Peck <marianopeck@gmail.com> 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.
participants (2)
-
laurent laffont -
Stéphane Ducasse