newbie question - please could someone could explain the bug workflow
boflynn
I've used a few bug systems in the past.
In agilo, I'm not sure how things are meant to work?
A tester logs a bug in agilo, assigns it to a sprint.
A developer (with TEAM_MEMBER rights and AGILO_CREATE_BUG rights and
AGILO_TICKET_EDIT rights),
for some reason can't go a pick a bug off the list and take ownership
of it? They also can't update the bug to fixed?
In fact, under the Actions section on the bug edit page, there is only
one option Leave as New?
For some reason someone has to be assigned to the bug for the
developer to be able change the status?
Surely this isn't the way its meant to work? Every other bug system
I've used, the developers can just go in and pick a bug off the list
(everyone owns all the code, etc. from agile)
Garbrand van der Molen
What you want to do can be done by configuring Agilo to suit your
workflow, but I'll explain why it doesn't work like that be default.
Since the question comes by more often, let me answer in more details
then is strictly necessary for future reference ;-)
The short answer: Bugs are treated similarly to User Stories: so
create tasks for bugs and developers will be able to 'own' those.
Long answer:
Agilo is *not* a bug tracker. It is first and foremost a Scrum project
management tool. It just happens to be based on a bug tracker ;-)
The core concept in Agilo is full traceability. That means you can
start with a blurry Vision, and then progressively follow it down to a
very concrete code commit.
So the basic flow looks like this:
- You create a Vision statement, something that tells you at a very
high level what you want your product to be
- From this vision you create Requirements - high level 'needs' that
your product will need to satisfy in order to be successful
- The Requirements you break down into User Stories - concrete
descriptions of how you will satisfy those needs for specific type of
users
- The User Stories are broken down into Tasks - 'real' pieces of work
you can solve at your desk ;-)
Now from a workflow point of view, these items are planned like so:
- The Vision is a wiki page. It is revised on a very slow cycle, as
the vision usually stays the same for very long periods of time.
- Requirements are planned in the Roadmap - you make a rough plan on
which need you want to solve when, depending on market opportunity and
your business model. You do this by planning you Releases in the
Roadmap - dividing it into several Sprints
- To the Sprints you add User Stories that you want to work on, based
on the Requirement you have in mind for Release
So where are the bugs?
Inevitably, software development will lead to bugs. There are two ways
of dealing with bugs: squashing them the moment they appear, in-
sprint. This should be done for all bugs that are noted immediately.
Some bugs do not pop-out during development, but after deployment, or
'in-production'. If they are critical, you of course stop what you are
doing and fix them.
If they are not-critical, you prioritize them, then plan them inside
your sprint plans. They should be prioritized and planned by the
Product Owner in collaboration with QA or Testing - not *by* QA or
Testing, as the PO needs to have control over the backlog if you want
him to be accountable.
A Bug is broken down into tasks, and then we are back at the short
answer ;-)
Regards,
Garbrand
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Agilo for Scrum" group. This group is moderated by agile42
> GmbH
> http://www.agile42.com and is focused in supporting Agilo for Scrum
> users.
> To post to this group, send email to ag...@googlegroups.com
> To unsubscribe from this group, send email to
> agilo+un...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/agilo?hl=en
> -~----------~----~----~----~------~----~------~--~---
>