linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

Hi

I am revising the wiki so here are some further answers to this earlier
email chain

On 07/05/12 04:11, Zach Pfeffer wrote:
> On 4 May 2012 01:56, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
>>> 1. The Linaro information model needs to be simplified or it needs a
>>> different visualization.
>>
>> What part of it was too complex? As information models go [1] this is
>> the simplest form I could draw. Perhaps remove the top/bottom parts and
>> just leave the JIRA/Launchpad halves to the model - is that what you had
>> in mind?
> 
> Maybe "too complex" is not the right critique. Some specifics:
> 
> 1. What does the line between Epic and Blueprint mean?

Maybe I should explain this model a little more (will also cover it at
Connect). This is a model that defines at a high level the requirements
artefacts used by our agile teams, as well as the relationships among
these artefacts. Information model or backlog model are the names used
to describe it.

The information model in the wiki shows 3 levels of information:
- at the top - blue blocks: there are abstract concepts: backlog items
are constrained by acceptance criteria (which could be either functional
or non-functional) and optionally elaborated by use cases (I updated the
model to include those)

- in the middle - orange blocks: the backlog items can be epics, cards,
blueprints (and yes there are cases where blueprints are used without
being associated with cards, so those blueprints are also backlog).
Epics (if available) are realised by a number of cards, cards are
realised by blueprints, which in turn are implemented by work items
and/or bugs.

- at the bottom -green blocks: the acceptance tests, and/or unit tests
which must pass for the blueprints to be considered complete

> 2. Do the colors of the boxes mean something?
I just tried to use colours as a way of grouping artefacts which are at
similar level of abstraction (high abstraction at the top, more concrete
as you move down ).


> 3. Why list Launchpad and Jira?
They are the main tools that hold the backlog item definitions: cards,
blueprints, bugs, work items. I did not want to spell out every tool we
use in this diagram in order to avoid making it overly complex.


> 4. If the goal is an Epic, it seems more intuitive to have it listed
> at the top and have everything else "underneath it."
> 
Perhaps so, I have chosen to follow the model given in literature such
as [1] (appendix D if you have the book, the colours were added by me in
order to make the blocks stand out more)


> Sure, but the point is you only use the term WG when platform and
> landing teams also own epics.
> 
> So this:
> 
> Which component a card belongs to. The components reflect the Linaro
> Engineering organisation structure - each component is an engineering
> Working Group
> 
> Could read:
> 
> Which component a card belongs to. The components reflect the Linaro
> Engineering organisation structure - each component is an engineering
> Working Group, Landing Team or Platform Team.

Fixed

>>> 4. Can you remove the stipple marks from the flow diagram?
>>>
>>

Fixed and updated on the page.

>>
>>> 5. We still need some way to capture recurring work.
>>>
I have created a recurring work card, i am in the process to define its
workflow (similar to the workflow for normal cards but with less
formality, and different owners at the final review).

>>

> ... snip ...
> I think  these are good ideas. As long as the recurring work shows up
> on some dashboard, in front of the TSC at some point, and they can
> just say, yup, still looks good and we can show that we completed the
> recurring work then I'm cool with any implementation (though having
> everything in Jira would be my vote, as I've noted before)
> 
>>> 6. There's nothing about how tracking will be communicated - i.e. how
>>> techleads should communicate how a card is going via BP and WIs.
>>>
>>
>> Related to the card status updates there is something mentioned:
>>
>> https://wiki.linaro.org/OPSCOM/RoadmapProcessWithJIRA#Bi-Weekly_status_update
> 
> Sure, but we still don't have the drill down from:
> 
> Epic to Card to BP to WI and Bug.
> 
> That's what I'm getting at and what I'm suggesting may be easier if
> everything moves into Jira.
> 

Drilling down from Card to BP at least is supposed to be part of the
status.l.o rework which Loic is working on. Once that is ready and
working, I would continue to support epics.

Currently we do not support epics directly: an epic issue type exists in
JIRA though it is not activated for the roadmap cards project. The
creation of an epic poses some extra questions in terms of the JIRA
workflow:
- an epic has to have cards as subtasks (structure of the info and the
filters need verification)
- an epic completion depends on the completion of all sub-cards first
(extra conditions in the workflow)
- we should also check the progress updates of epics related to the
progress of the epic cards.

We will discuss the drilling down flow of info during Connect.

regards,
Ilias

[1]:
http://www.amazon.com/Agile-Software-Requirements-Enterprise-Development/dp/0321635841/ref=sr_1_15?ie=UTF8&qid=1337634064&sr=8-15
-- 
Ilias Biris ilias.biris@xxxxxxxxxx
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs