incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: Sprints don't work (was: Sprint 1 Results)
Date Mon, 09 Feb 2009 08:49:06 GMT
On Mon, Feb 9, 2009 at 7:41 AM, Bertrand Delacretaz
<bdelacretaz@apache.org> 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 <vdichev@gmail.com> 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

Mime
View raw message