Iteration 9 notes

[Norman Gray]

Folks,

I've added the notes for the iteration 9 meeting on the project
wiki[1]. Note that these are not almost two weeks late, like the last
lot....

See you,

Norman

[1] http://code.google.com/p/skua/wiki/Iteration9

--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester

[Ross Gardler]

I'm particularly interested in your discussions about the process,
specifically "Are the user-stories useful?"

I have often tried to use user stories as you are trying to do now and
I have always hit the same position that you are now in. I believe
that the effort of making up the story, when the full team already
know what is needed as a result of meetings etc. They are more useful
when there is a real customer, as observed in the iteration notes.
However, you notes are missing a very important use for them.

I'm not sure that this use maps to your process here as the stories
are not (as far as I can see) tied to work in the issue tracker or
archived discussions. However, in an open development project (as
opposed to the open/agile process you have here) the user stories are
really useful for newcomers coming to the project. Let me try and
illustrate (bear with me, I'll suggest how this may inform your own
process at the end):

Story X defines feature A

The story is recorded in the issue tracker. Discussions in the mailing
list about how to implement the story are archived and these archives
are linked from the comments in the issue tracker.

Feature A is implemented and the commit message refers back to the
issue that defines the story.

Now the project team move on to a new story.

Two years later a power user comes along. The original developer has
moved on but a new developer needs to extend feature A. Unfortunately
the implementation is confusing to this new developer. They search in
the issue tracker for the story that describes feature A. This
provides a link to the archives where the design is discussed and also
records the individual commits made as a part of this work, along with
the commit messages they say why it was necessary.

The issue will also be linked to any other stories that have, over the
years, impacted on this feature implementation. For an example of how
this works see [1]. This illustrates a particularly large feature that
is now core to the most powerful of features within the project. From
that one location it is possible for a newcomer to find everything
they need to know about this feature.It covers a development period of
over 3 years. It involved 5 developers (in the issue, probably more on
the mail lists) and has 8 related features and 19 subtasks. One of the
developers who joined one year into the effort was a complete
newcomer, the patches he supplied to that issue were his first
contributions - pretty impressive for something that was refactoring a
major portion of the system. Two of the developers from the early
stage of the feature implementation are no longer active on the
project, but we still have their thoughts and guidance right there in
the project.

What I'm trying to say is this is a very powerful knowledge retention
and sharing mechanism and it really is worth the effort in the long
term. However, with the right tools, this whole process can be
(largely) automated and thus, for very little additional effort, the
project becomes more maintainable.

Of course, in most cases of open development the stories are not
actually stories they are really feature requests in the issue tracker.

I wonder if your internal frustrations with stories are a result of
the increased effort in story writing providing very little visible
long term impact. I don't deny the stories are useful as
documentation, but without the links into the whole history of the
project they are only of use whilst actively watching development, the
comments in the iteration notes seem to indicate the project team have
similar feelings.

If this is the case it might be useful to consider dropping the formal
stories and instead using actively using an issue tracker in a more
informal way. Spend less time on the stories, but still capture the
important knowledge. If you can attract real customers then you can
get them to write real stores and the developers can break them into
smaller tasks.

Even better if you can link this to design archives and code commits
(this is an often requested feature over at Google Code and should be
forthcoming soon).

Anyway, as ever, just a suggestion - let me know how it works out. I'm
watching and learning from your experiments in development
methodologies.

Ross

[1] https://issues.apache.org/jira/browse/FOR-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel