On Mon, Feb 9, 2009 at 7:41 AM, Bertrand Delacretaz <[email protected]> wrote: > ...now that I got your attention with the catchy subject line ;-)
in the the spirit of http://c2.com/cgi/wiki?WhyWikiWorks and http://c2.com/cgi/wiki?WhyWikiWorksNot, i'd like to jump in and add a counter-point not because i disagree with Bertrand but i am interested in seeing whether sprints could work within a collaborative open development environment. i've been watching the sprints on this list and wondering whether some of the ideas could be applied - in some form - to help organise some other projects i'm involved in at apache. (i also think that there's a danger that apache may become too conservative in terms of model. our development model is well known, has proved itself and is now widely applied. but that doesn't mean it's perfect. sprints clearly work well for the existing esme team and are done very openly. perhaps with some thought and some changes, it might be possible to use them successful.) AIUI (hopefully, the experts will jump in and correct any misunderstands) sprints arose from compressed, cyclic approaches to development - fixing deadlines rather than function shipped. at the end of the sprint, the software should be ready for customer evaluation. this is similar to conventional open development - software is shipped when the consensus says it's ready, rather than to a dealine. the main difference is the short release cycles (a week or two). open development subscribes to the 'release early, release often' philosophy but - in practice - the apache projects usually see long gaps between releases. i've observed many issues - both social and technical - in projects arise from these long gaps. this line of reasoning leads me to propose my first "Open Source Sprints Work" 1. (Open Source Sprints Work) To release early milestones often in other words, committing to cutting and voting on a milestone release ever cycle > On Sun, Feb 8, 2009 at 10:21 PM, Vassil Dichev <[email protected]> wrote: >> ...There's >> still a lot for me to learn from Lift and even Scala in order to reach >> optimum productivity... > > Or even Apache ;-) > > I think sprints don't work when people cannot commit to set amounts of > time or energy towards the sprint's goals. And with the life realities > expressed by several folks on this list, it seems like the ESME time > is like most other Apache teams, in that people's available time comes > in small unpredictable chunks. +1 it can often be difficult for occasional or new developers to pick up small chunks of tasks to fit their small, unpredicatable chucks of time 2. (Open Source Sprints Work) To advertise small tasks that can easily be picked up by the community > The tried and tested way to solve this @apache (at least in the > projects that I've been involved in) is, roughly: > > 1. Enter all issues in JIRA > > 2. Define relationships between issues, so as to build a tree of issue > dependencies that shows you what's needed to achieve the goals - goals > being issues at the top of the tree. Few Apache projects actually use > this technique explicitely, but they should ;-) > > 3. Let people pick and choose the issues that they want to work on. > Ideally everybody can work on any issues as opposed to "all > server-side memory issues are handled by Bob" which doesn't work if > Bob cannot help at the moment. > > 4. Release when an agreed upon set S of issues are implemented and > verified. The release trigger is quality, not the clock. And release > early and often - releases with known issues are fine as long as > that's documented (which happens automatically if JIRA is used > consistently). > > The risk is that intervals between releases might be too long, which > can be adjusted by taking issues out of S. +1 developer's time is unpredicatable and issuing tracking is essential. task tracking is essential to understand the progress made on a particular issue. i've observed major problems arise (in a small minority of projects) from this pushing method. an alternative method would be to use a pull back. a pool of tasks is assigned to the next full release. when a developer grabs a bit of work, they assign it to themselves and - if they think they can complete it in time - move it to the milestone. any work that is unfinished when the milestone is cut is moved back into the pool. 3. (Open Source Sprints Work) uses issue management to organise and record each milestone by selecting issues from the next release pool - robert
