linaro-project-management team mailing list archive

[Ilias Biris <ilias.biris@xxxxxxxxxx>]

Hi

Thanks for the feedback! Some clarifications inline, mind you the
recurring work issue deserves a separate thread.

On 03/05/12 19:31, Zach Pfeffer wrote:
> Feedback:
> 
> 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?

> 
> 2. Wouldn't it be simpler to just ditch Launchpad, and run everything
> out of Jira?
> 

Perhaps I will echo what Ricardo replied but add a bit more of my
thinking here:

I agree that fewer tools is better. However, before we can answer the
question you ask we should understand all the requirements we have for

- Card lifecycle management and Kanban
- Work breakdown and Planning releases
- Reports, monitoring, estimates

LP is used not only for work breakdown and planning releases - it is
also used to handle bugs and code and PPAs.

So for the long term I believe consolidating into 1 tool is the way to
go, but we need to approach this in phases to make sure we do not lose
in terms of support to do our work. We are just coming through the first
phase, making sure Jira can replace papyrs and kanbantool and that it
hooks to our custom reports like through s.l.o. After some practical
experience with JIRA we will look into requirements of LP and status and
see if we can incorporate them into JIRA. At the moment I do not see
that we could deprecate LP or status.


> 3. This is inflexible and inaccurate:
> 
> "Which component a card belongs to. The components reflect the Linaro
> Engineering organisation structure - each component is an engineering
> Working Group"
> 
> The Android team is not a WG yet it owns cards and most of the cards
> it would own would be composed of cross team efforts. With this we're
> just reinforcing the Silo system we have in place.
> 

A JIRA component reflect the owner of a requirement. Even if we have
requirements shared amongst teams, we should have clear ownership. That
is what the component in JIRA stands for.

We could have silos with or without JIRA components. What JIRA supports
does not dictate how we communicate and agree at blueprint or work item
level about work-splits across teams.

I can change the wording to make this point clear, though in my mind it
is obvious.

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

Yup!

> 5. We still need some way to capture recurring work.
> 

The recurring work elements are part of one's work and they do provide
value.

Thinking aloud here, please chime in to debug my thinking.

Related to recurring work, we can either
- use cards and follow the same process OR
- we could introduce a new issue type,  different than the current
"roadmap card" in terms of the workflow process it follows. Let's call
it the "recurring work card" (RWC). An RWC would get still the TSC
approval at the beginning, but would not necessarily depend on more TSC
reviews after that, provided that the deliverables are signed off by eg
OPSCOM.

For example handling the recurring release-related tasks could be an
RWC, get planned/estimated and presented to the TSC along with the ret
of a team's scope for the upcoming cycle. The approval needed there is
over the planned usage of resources - how many folks over how much time
each month (Estimates). However, once approved at TSC for the cycle, the
deliverables themselves need not be approved by the TSC - those would be
the monthly recurring updates to the release, for example, and OPSCOM
would follow up on those in order to resolve impediments and help with
correction next time around.

Why bother having the recurring elements linked to RWCs?  Because that
helps visualize how much a group is doing as recurring work vs
introducing new functionality. My understanding is that the goal should
be to kill off out-of-sight-out-of-mind management. It behooves you to
visualize as much as you can - so it follows that to be successful we
would need monitoring in place in order to identify the balance of
resources used for RWCs vs normal Cards.

I cannot claim to have the complete answer for the monitoring part - I'd
like to think of the RWCs as tags to be associated with blueprints or
bugs that are done repeatedly.

Any other ideas?

> 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



> On 2 May 2012 00:23, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
>> Hello folks
>>
>> Since there was no comment on this write-up, I will move it under the
>> OPSCOM wiki area, today. Feel free to send your feedback if you have any.
>>
>> Cheers,
>> Ilias
>>


[1]
http://scalingsoftwareagilityblog.com/agile-enterprise-requirements-information-model-subset-for-agile-project-teams/



>>
>> On 26/04/12 04:09, Ilias Biris wrote:
>>> Hello
>>>
>>> I have put together a first draft of the roadmap process as implemented
>>> in JIRA. The draft can be found in
>>>
>>> https://wiki.linaro.org/IliasBiris/RoadmapProcessWithJIRA
>>>
>>> It describes the Linaro high-level  information model regarding JIRA and
>>> Launchpad artifacts (eg cards vs blueprints) and also shows how the card
>>> workflow looks like in JIRA (also showing which user types have access
>>> to the various transitions available).
>>>
>>> If you would like to review this page and give feedback I would be
>>> grateful. Any questions or issues that you may have are welcome. Once
>>> this is updated based on comments I receive it will be moved under
>>> https://wiki.linaro.org/Process/ to serve as more "formal" document.
>>>
>>> Note there are some sections at the end of the document which are not
>>> filled in yet, those are going to be added by the end of the week,
>>> however their absence does not need to stop this RFC from going out.
>>>
>>> Best regards,
>>>
>>
>>
>> --
>> Ilias Biris ilias.biris@xxxxxxxxxx
>> Project Manager, Linaro
>> M: +358504839608, IRC: ibiris Skype: ilias_biris
>> Linaro.org│ Open source software for ARM SoCs
> 
> 
> 


-- 
Ilias Biris ilias.biris@xxxxxxxxxx
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs