[Fiware-iot] weekly meeting minutes, 24 August 2011

[thierry.nagellen at orange-ftgroup.com]

Hi Ricardo,

 

Thanks for your examples. Some comments about them we will discuss tomorrow:

1 - Do we have to define that a GE is a theme? (I'm not sure but it could be)

2 - We need at least 1 EPIC per component but I'm sure we would have several EPICs per component (not so much but probably 2 or 3)

3 - Entries names: there should be "explicit" in 4 or 5 words (check below Juanjo comments). It is very difficult but somewhere we would link names and IoT architecture description (GEs & components, not module). So in the case of your EPIC "Resolution Infra", this is not clear to me with which part of the Resource Management GE it is associated.

4 - UserStory.NewSensorRegister: it is not clear at FI-Ware level how we would submit some user stories to describe how we expect to use some features from the other technical chapter. Maybe you are aware of this Publish/Subscribe broker as you worked in this area before but it is a very good point to define how we can submit cross-WP requirements. But in this case we have to keep the source of the story in the cell "chapter": IoT Se and not DCM.

 

BR

 

Thierry

 

Juanjo additional comments to fulfill backlog entries:

There are some comments that have applied to the first take on the entries within the Data/Context Management WP so that I'm sharing them with you because may be they are helpful in collecting your own entries.  They are, of course, generic:

*	Try to stick to the formula proposed for goals in the example templates ("Applications should be able to ..." / "It should be possible ...").   This is common practice in Agile.   So, as far as it feasible, and not too much artificious, try to follow it.   Following a defined formula, we gain in uniformity but, overall it will be easier to extract <performed action>, <scenario> and <derived results>.   Note that in Agile, some people like to use a cannonical form which is "As a <role>, I can <activity> so that <business value>".   We tried just to adapt this a bit to description of stories for a software platform, but the notion of "cannonical form" itself is something we should try to stick to. 
*	Chapter field: should be the name of your chapter: "Cloud Hosting", "Data/Context Management", "IoT Service Enablement", ...
*	Source and Stakeholder fields:  You should write "FI-WARE" in here, at least for the time being.   Keep Source contact empty for the time being.
*	Owner and Owner contact: this should be the name of your company (the company or companies behind the asset being considered as "baseline").   Fill the owner contact with your email for the time being but we'll see how to handle this later (we don't want that making entries publicly available becomes a source of spam :-)
*	We mentioned that "name" should be an acronymun (indeed the last part of the Id) but I have found itself a little bit useless itself if it is actually part of the Id.  Therefore, I suggest that we follow the approach of Thales and use it as a short description (should not be longer than 7 words, preferably 4-5 excluding "and"s "the"s and similar auxiliary articles, prepositions, etc) 
*	The Description field is free.   Put there whatever makes sense to you and would be helpful to understand the entry.   Don't hesitate to add URLs to complementary documents, standards, whatever you believe may be useful if read.   You can upload a document to the docman system at FusionForge and then use the link if you wish. 
*	Regarding the Rationale: at least for entries prioritized with a MUST MoSCoW, try to give more info about why "it would have no sense" if we do not develop the corresponding feature.   Note that a MUST priority is considered to be assigned for features that "If not done, the project will be considered a failure".  In other words: the product doesn't make sense to you unless it supports that feature.   UC projects may argue that some of the features they propose are going to be of a higher priority than these ones, so that better you work the rationale for keeping your priority.
*	About the MoSCoW priority:   It is assumed that you are bringing here an asset that your company had developed and had plans to keep evolving because it is of relevant priority to you.   Therefore, here you are some guidelines that I would suggest you to bear in mind when reviewing the MoSCoW priorities you had assigned. 

	*	You should assign a MUST priority to features you would plan to address in the following 12 months in your product (asset), no matter whether FI-WARE had existed or not.   Again, the product doesn't make sense if you are not allowed to address this MUST priority.   That's why you had it in your roadmap no matter if FI-WARE exists or not.
	*	You may assign a SHOULD priority to features that were in your roadmap and you believe were important although perhaps you couldn't address them in the next 12 months prior existence of FI-WARE because lack of resources.  FI-WARE actually gaves you the opportunity to address them. 
	*	You should assign a COULD priority to features you believe are nice to have and could be addressed thanks to FI-WARE.    But you are open to learn about better ideas that may get assigned a higher priority. 

 

 

De : fiware-iot-bounces at lists.fi-ware.eu [mailto:fiware-iot-bounces at lists.fi-ware.eu] De la part de Ricardo de las Heras
Envoyé : vendredi 26 août 2011 14:50
À : Farkas, Lorant (NSN - HU/Budapest)
Cc : fiware-iot at lists.fi-ware.eu
Objet : Re: [Fiware-iot] weekly meeting minutes, 24 August 2011

 

Dear Lorant, colleagues,

I just uploaded at 
https://forge.fi-ware.eu/docman/view.php/11/327/BacklogFiware-T5.2-v0.2.xls

a first Excel draft including some EPICs for T5.2, 
next week we'll try to include new ones and to refine them,

have a nice week-end,
best,
Ricardo.

Farkas, Lorant (NSN - HU/Budapest) wrote: 

Dear All, 

Please find the meeting minutes under the following link: 
https://forge.fi-ware.eu/docman/view.php/11/321/IoT-Minutes-Telco-08242011.doc <https://forge.fi-ware.eu/docman/view.php/11/321/IoT-Minutes-Telco-08242011.doc>  

Thanks & Br, 

Lorant 

 

-- 
-------------------------------------
Ricardo de las Heras
M2M Research Project Manager
E-mail: <mailto:rheras at tid.es>  rheras at tid.es
Phone1: (+34) 983 367625
Phone2 OCS: (+34) 91 31 29511
Phone3 Skype: (+34) 91 1878107 + Ext: 327
Telefónica I+D <http://www.tid.es> 
-------------------------------------

 

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-iot/attachments/20110830/a8a5d82d/attachment.html>