Milan On 2013-04-03, at 7:38 PM, Ben Francis <[email protected]> wrote:
> On Wed, Apr 3, 2013 at 9:32 PM, Andreas Gal <[email protected]> wrote: > > What about the other option? Avoid v1.2 work until v1.1 is more stable? > > If we start using Scrum and two week iterations as Jonas has described, then > there should be no need for any engineer to work on 1.n+1 work until 1.n is > complete, or even work on iteration n+1 until iteration n is complete. I'd be careful here. There is nothing magical about scrum that would have stopped us from getting exactly to where we are today. I don't see it as either necessary or sufficient condition to get to a better state, whatever that state we may choose to be. > > If we have Scrum teams dedicated to product areas with a product owner and > scrum master for each team then we should have a clear ordered product > backlog and sprint backlogs to work from. If iterations are time-boxed then > you can not, by definition, be working on the next iteration. Sure, but that assumes you have a particular approach in mind, and everybody follows it. Scrum doesn't give you that approach, it needs to come separately. It'll help with execution and focus and such, but won't tell you what the right thing to do is. Don't get me wrong, I don't mind scrum in general, but it doesn't magically wave the problems away. > > Sorry to bring project management into a branching discussion again, but I > think the two are inextricably linked. A continuous delivery approach might > call for a different branching strategy for example. > > Ben > > -- > Ben Francis > http://tola.me.uk _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
