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 <[email protected]> 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 [email protected] Project Manager, Linaro M: +358504839608, IRC: ibiris Skype: ilias_biris Linaro.org│ Open source software for ARM SoCs _______________________________________________ Mailing list: https://launchpad.net/~linaro-project-management Post to : [email protected] Unsubscribe : https://launchpad.net/~linaro-project-management More help : https://help.launchpad.net/ListHelp
