linaro-project-management team mailing list archive

[Alexander Sack <asac@xxxxxxxxxx>]

Hi,

general comments...

I agree that missions are missing in our current systems and the new
JIRA feature presented here looks good for introducing that.  I also
believe that missions are in general not bound to cycles, but rather
open ended. They get regularly revisited and confirmed by TSC though,
but they typically have no defined end date from the beginning.

Whether JIRA should just be missions or rather missions and cards or
even mission, cards, execution iterations (currently blueprints) and
work items and bugs is not yet clear to me.

Once we have established proper use of existing tools and processes
across the organization we can think about consolidating ...
potentailly everything into JIRA. However, I feel hesitant to even
pilot yet another tools switch until we can take a look at
status.linaro.org and it looks great for the whole organization again
and until we have nice engineering reports that group our monthly
achievements alongside missions and cards.

On Tue, Oct 16, 2012 at 12:49 PM, Ilias Biris <ilias.biris@xxxxxxxxxx> wrote:
> Hey,
>
> thanks for the feedback see below for some answers.
>
> On 16/10/12 00:52, Jakub Pavelek wrote:
>> Hi,
>>
>> works well for me. However once I have visited one of those Structures I
>> will see that particular structure in every Card I have, related or not to
>> that structure. That is annoying a bit.
>>
>
> You mean the area which appears in a card view showing structures? That
> one is a quick browser of structures, with handles available to add the
> current card into an existing structure. By default it shows the latest
> structure you have seen. It comes by default collapsed - if you expand
> to see the structure it should tell you if the card is in the structure
> or not. Also you have a handle to select which structure to show in that
> area - the structures which contain the card you are viewing are already
> highlighted in the selection list. See the attached PDF screenshots I
> took with this area collapsed and open - try it out on different cards.
>
>
>> Now for a little off-topic. It got me thinking: we already have hierarchies
>> of Blueprints - and those work well for me personally. Hierarchy of cards
>> encourages small cards and small cards bring details I'm convinced TSC is
>> not interested in. Should we say "Card is a high-level mission" and stop
>> worrying too much about a card being the proper size for our 3 months
>> iterations? Make Card a roadmap item where the expected delivery matters.
>>
>
> If I understand what you ask correctly, it seems that if we do this then
> planning with cards will effectively diminish to setting missions with
> no clear delivery horizon. However, high level missions which may finish
> any time from a few months to whenever are not very useful to set
> expectations eg at the TSC level. Even though BPs are used by
> engineering there are other stakeholders which need the plan
> transparency at the roadmap level - that means cards.
>
> So my question - how would this improve our planning, and estimates?
> Using the cards and planning from Connect to Connect enables us to set a
> cadence for synchronisation of our deliverables whilst keeping the
> waiting times for the deliverables as predictable as we can (and we can
> improve there).
>
> Maybe we can discuss this - would you like to set a meeting at least
> between PMs to cover this topic?
>
> Cheers!
>
> --
> Ilias Biris ilias.biris@xxxxxxxxxx
> Project Manager, Linaro
> M: +358504839608, IRC: ibiris Skype: ilias_biris
> Linaro.org│ Open source software for ARM SoCs



-- 
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog