[Fiware-data] Peer review of Data/Context Management Backlog entries

[Juanjo Hierro]

Hi all,

  This mail is to officially launch the peer review of entries in the Data/Context Management Backlog.

  As I already told you, input received so far can be found under the FI-WARE Data Backlog folder/group in the docman system of the FI-WARE Data project in FusionForge.

  I would like ALL of you to carry out a peer review of the input produced by the rest of the team.   Please send your comments to the mailing list instead of me or the responsible of a particular GE.   Your comments are due by this friday September 2, EOB (IBM colleagues in Haifa can submit their comments also on Sunday September 4).   Goal is that we have all comments gathered at the start of next week and then work in the addressing received comments as to get a final version by end of that week, ready for investigation/discussion during our face2face meeting.

  As promised, here you are my overall comments on the entries received so far.    They are generic and intend to be just a first "meat to eat" so that you can start addressing some comments regarding entries you have submitted.   They are not applicable to all cases, of course.   T.I+D will provide specific comments in the above mentioned due date.


 *   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 "Data/Context Management"
 *   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.   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, 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
    *   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 are open to learn about better ideas that may get assigned a higher priority.


  Hope all these comments become useful.

  Don't hesitate to formulate any question.

  Best regards,

-- Juanjo


________________________________
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-data/attachments/20110829/76dff667/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: text/x-vcard
Size: 429 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20110829/76dff667/attachment.vcf>