Re: [DotGNU]help needed

[Norbert Bollow]

> i am doing in .net,
> my title:"web based issue/bug tracking system"

Hi Srinu,
  here's a copy of a recent posting on the PBF (Python Business Forum)
mailing list.  I think that an issue tracking system along these lines
would fit well into DotGNU as a useful example of a webservice
application.  One tricky question is this:  What is a good way to keep
track of how much time is spent working on the various issues?  If
that is not automated then you have to be very disciplined to create
reasonably accurate data.  On the other hand, if it's automated (for
example by programming Emacs to automatically talk XML-RPC with the
webservice whenever you start or stop editing a file which is related
to an issue) then there are serious privacy concerns.

Warm greetings,
Norbert.


Subject: [Pbf] Issue trackers, aka XP "story management" (long, sorry)
Sender: address@hidden
Errors-To: address@hidden
X-BeenThere: address@hidden
X-Mailman-Version: 2.0.13
Precedence: bulk
List-Help: <mailto:address@hidden>
List-Post: <mailto:address@hidden>
List-Subscribe: <http://theraft.strakt.com/mailman/listinfo/pbf>,
        <mailto:address@hidden>
List-Id: The Python Business Forum <pbf.strakt.com>
List-Unsubscribe: <http://theraft.strakt.com/mailman/listinfo/pbf>,
        <mailto:address@hidden>
List-Archive: <http://theraft.strakt.com/mailman/private/pbf/>
Date: Sun, 15 Dec 2002 23:37:38 -0500
Content-Type: text/plain; charset=us-ascii
X-UIDL: b94a9ce0b06c318307ecbff09b658427

Dinu Gherman wrote:
>
> talking of XP... I wonder if other people
> here with XP experience (sic!) have some "implemented workflow
> system" for handling story "management" etc.? My gut feeling
> says that some web-based system would be a fruitful direction
> to take here...

Laura's comments about XP, her motion to "put our house in better
order" with improved techniques, the discussions about which
tasks need doing, Laura's comments about the "inner circle policy"
being a failure, my initial observations as a new member, and then
Dinu's inquiry above force me to offer the following points for your
consideration.  (This may turn out to be lengthy.  If so, my apologies -
had I more time I could have made it shorter (stealing from Churchill).)

My group at Kaval Wireless Technologies (my current employer) has
been through a wonderful evolution over the last two years.  At the
beginning of that time, we had barely heard of XP, had done little
Python programming, and were desperately trying to accomplish way too
much work with way too few people and an unclear idea of what the
priorities were.  We were also growing rapidly - the team expanded from
three to about fifteen in the space of a year!  Managing in such an
context is, I would say, an impossibility with traditional approaches.

Fairly early on, we wanted to implement a "bug tracker".  This was the
traditional thing to do.  We investigated commercial and free products
but I was uncomfortable with the complexity of each of them.  We also
were being forced to consider MS Project and its ilk.  I was desperate
for an alternative!  I've been involved with too many projects where
these things were believed to help manage, when in fact all they did
was obscure reality and provide a way of diverting blame when the project
failed.  They gave a false sense of security.

After lengthy discussion, which I won't go into here, we realized that
all the problems we had in this area, tracking "bugs", "tasks", "ideas",
and "stories" (as we started into XP) could be seen as minor variations
on one theme: issues.  We eventually generalized all these in the form
of our "issue tracker", which from the start was a web-based tool with
very simple goals.  It allows one to create an "issue", which just means
"something that has to be dealt with", whether it's a bug, an idea, a
task, or something else.  Issues have few fields: things like author,
date, category, priority, and owner, as well as the automatically
assigned serial number (e.g. SW01690 as our latest Software issue).

Issues have stages, generalized to these: new, study, active, review,
and closed.  "New" means unexamined or untouched.  "Study" means we're
not sure exactly what to do yet but are researching/considering.
"Active" is obvious.  When work is thought to be complete, the issue is
marked for "review", whereupon someone - generally not the one who worked
on it and possibly the originator - considers whether it meets the goals
and marks it "closed", or adds comments and reopens it to "active".

Since two years ago, we have reached the point where *all* work in the
group is managed in the issue tracker.  Sometimes we call it the story
tracker (ala XP) but it's the same thing.  We have (as of this moment),
1690 issues (821 closed, 373 in review, 11 active, 259 in study).

Lately we've added another layer on top which allows us to prioritize
all stories "strictly", which is to say in a strict sequence where the
top one is "highest" and the priority is lower for each one down the
list.  This really focuses one on what is most important at any given
time, and gets rid of the "but they're both equally important" nonsense
which I've faced from senior management in too many places.  This new
tool also lets us divide the prioritized list into "iterations" (two-week
periods with predefined capacities for work to be done) and thereby
measure progress on a fine scale, with rapid feedback and adjustment of
expectations for that progress.


I bring all this up for several reasons.  One is that I suspect some people
don't yet think in simple terms of "issues", but consider bugs, tasks, and
other such things to be distinct, and I believe this is unnecessary and
inefficient.  Second, along with the issue tracker our adoption of XP, and
specifically several key practices, has allowed us to manage scope carefully.
We're at the point where we have a _manageable_ environment, which is more
than I can say for any other place I've worked or seen in the past.


As in XP, people are not /assigned/ tasks, but take them on voluntarily.
The tracker makes it clear which issues are available, and through the
prioritization and discussion, everyone knows which ones are critical.
In XP terms, the "relative business value" is made clear.  This means
the important stuff gets done, while the other stuff is left alone
until resources are available (which, as you know, they usually never
are).

This relates to the "inner circle" thing: in some groups, people are fearful
of "something bad" happening:  "What if somebody writes the wrong thing in
a wiki?"  Lock it down, allow only members to change it.  "What if a volunteer
accidentally deletes a page?"  Only allow a tightly controlled group to have
access.  "What if ???"  Control, restrict, prevent!

This is the wrong attitude, XP would say: have some faith, give people a break,
heck: you *educate* them if they do something wrong.  Don't assume it will break
...
but be prepared to fix it after the fact if it does.  This attitude will let
you open up the process to more people.  It will let you take advantage of the
very limited time some people have, by making it convenient for them to spend
even a few minutes or seconds on a problem, then drop out again for a while.
If you restrict access to only the "right" three people, you're overburdening
those three with work, while preventing the other N-3 people from even
considering making a contribution.  Zope has a robust Undo: make use of it!


Each issue has a log where followup discussion is maintained.  The
text is StructuredText, with simple timestamped headers separating updates
so you can follow who said what.  This diverts discussion from mailing
lists or, in our case, excessive email.  It also captures the discussion
for the future, as list archives do, but all in one place.  It's simple,
but it works.  People (anyone) can subscribe to updates, so any followup
goes out to the self-selected group interested in that particular topic.

A mailing list is fine in general, but between messed-up threading, spam,
lost emails, off-topic discussion, and the many other inconveniences, I don't
think it's necessarily the right medium for focused discussion about a very
specific issue.  The issue tracker has proven to be rather effective at this.
When necessary, issues can be reference in a mailing list discussion by URL,
but much of the time the noise can be diverted from the general list.
(Obviously, setting up separate lists for each issue wouldn't work either,
although separate lists per category might be manageable, but I wouldn't
want to try it.)


All told, I think there would be some value in implementing the issue tracker
concept, diverting all todos, bug reports, tasks, stories, ideas, and other
such items into the tracker, and thereby getting everyone focused on the importa
nt
things: prioritizing the issues so we don't waste time on things with relatively
low business value, and actually doing the work on the high priority issues with
the very limited time we obviously have available.

If this idea is picked up, I have one *very* strong recommendation to make:
Keep it simple!  We consciously stripped out all the non-essentials as we saw
them from the early concepts, and somewhat surprisingly have made very few
additions since the beginning.  Less is more!  Every time I see an idea like
this discussed elsewhere, people get carried away with all kinds of cool
features that should be added.  Don't!  Learn the XP way: drive the development
solely by need, and only after aggressively prioritizing the requests.  Most
of them are not necessary and after a day, or a week, you won't miss them.

Okay, I'm done.  Phew... as I said, sorry it was so long.  Now tear it apart. :)

-Peter Hansen, P.Eng.
(Director, Software Engineering,
 Kaval Wireless Technologies)