[Fiware] Fwd: IMPORTANT: General comments regarding addition/revision of Features linked to FI-WARE GEs

[Juanjo Hierro]

Hi,

  Please take your time to review the following email that may anticipate some actions that may apply to the GE you are responsible for.

  Best regards,

-- Juanjo


-------- Original Message --------
Subject:        IMPORTANT: General comments regarding addition/revision of Features linked to FI-WARE GEs
Date:   Tue, 24 Jul 2012 10:57:45 +0200
From:   Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es>
To:     fiware-wpl at lists.fi-ware.eu<mailto:fiware-wpl at lists.fi-ware.eu> <fiware-wpl at lists.fi-ware.eu><mailto:fiware-wpl at lists.fi-ware.eu>, fiware-wpa at lists.fi-ware.eu<mailto:fiware-wpa at lists.fi-ware.eu> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu>


Dear Chapter Leaders,

  We will send each of you an email with specific comments on your chapter, but we have decided to compile a number of generic comments you have to take into account.  You have to find out to what extend they are applicable to your chapter.

  Note that rejection of work made regarding addition/revision of Features linked to FI-WARE GEs will impact the justification of resources that were supposed to work contributing to development of WP2 deliverables (the Technical Roadmap deliverable in this case) and the development of Unit Testing Plans (since they should be formulated upon defined Features).  Not up to 100% of those resources but significantly.

  Cheers,

-- Juanjo Hierro

1. General Comments regarding addition/revision of Features linked to FI-WARE GEs

1.1 Completeness of the set of Features linked to GEs

  We have commented many times that any third party should be able to understand what a GE is about and what functional and non-functional features it will support by means of reading the complete set of Features defined in the Backlog (that's why they are called Features).   Adding Epics to this reading (though excluding Epics that are mere ascendants of identified Features), a third party may also gain a general idea of what topics are planned in the future for that GE.

  If someone ask you tomorrow to develop the technical brochure of any GE in your chapter, it should be an easy exercise you should be able to complete based on text of the goals linked to Features of that GE.

  Are these general rules applicable to FI-WARE GEs in your chapter ?   We sincerely believe that not in all cases.   Please check it yourself.   It hadn't been a bad idea if you have carried out some sort of peer-review process within your chapter having this goal in mind.


1.2 Single-Featured GEs

  There are several GEs that are characterized by just a couple of Features.   We believe that this is a rather poor description and most probably we will ask to improve it.

  There are even some GEs that are just characterized by a single Feature.   If it were the case that the Feature contains a long description with a rather elaborated description of all the functionality covered by the GE we would recommend to split the Feature into several.   However, in many (if not all) the cases where this happens, the Feature comprises a rather brief and too high-level description.   We believe this is unjustifiable.  We will reject this.

  One general formula that some GE owners have followed is that of identifying at least one Feature per operation exported by the GE.   Sometimes a given operation is too complex and admit several variants that will not all be supported in the first release of FI-WARE (e.g., it receives arguments of different nature and there are special type of arguments that will not be supported until certain Release of FI-WARE).   This circumstance should lead to several Features, one per variant.      You may also identify some additional Features linked to description of how the GE can be configured by users.   Last but not least, you may also identify some non-functional features linked to certain requirements that, at minimum, any product that would be considered a valid implementation of the GE should comply with.


1.3 Features map to functional or non-functional characteristics, not to Work Items.

  We have seen some Features linked to some GEs that are indeed Work Items and not Features.   Setting up a working testing environment to ease development of the GE cannot be considered a Feature but a Work Item that we understand could have been needed during development of the project.   But it doesn't have anything to do with characteristics of the GE.

  Note that Work Items should only be visible on the trackers and not in the backlog of the Wiki.


1.4 Shouldn't some User Stories be labeled as Features ?

  There are some cases in which we have found that some of the User Stories had fit nicely as Features.   They had helped to compile a final set of Features that allow to meet the goal described in section 1.1. above.   However, the Features that may be considered as "Ascendants" of those User Stories include descriptions that are too high-level or vague, thus making it difficult to meet the goal described in section 1.1. if considered alone.

  We suggest that you address this issue in any of the two following ways:

  *   Were these User Stories actually resolved in the course of a Sprint (i.e., one month) ?
     *   If the answer is 'Yes', then we propose to follow any of the two following options:
        *   clone the User Stories as Features.   There is no Agile principle that would go against it.  We would justify that each Feature had led to a single User Story because we have realized it could be addressed in the course of a Sprint.
        *   refine the description of the 'father' Feature (there should be some and, if not, just create it) so that it contains a bullet list of related functions, each item in the list mapping to one of the User Stories
     *   If the answer is 'No', transform the User Story into a Feature.   This will imply that you didn't refine the Feature into User Stories that you could address in the course of each of the Sprints that belonged to a Release.   We can't relax and forget meeting this rule for this first major release of FI-WARE.   We'll try to do it better during development of the second major release of FI-WARE

1.5 Description of some Features is missing or is very poor

  The Description of some Features is simple missing or is very poor (almost a copy and paste of the goal).   While goals should try to capture the functional or non-functional feature supported by the GE in one or maximum 2 lines, the Description should be more elaborated.

1.6 Formula for Goals

  Following Agile principles, the definition of Goals should follow patterns such as "<GE-users> will be able to <short description of features/functions>" or "By means of invoking the <operation-name> exported by the <name-of-GE> GE, <GE-users> will be able to <short description of features/functions>" or even following a more typical Agile approach "As a <role>, I will be able to do <whatever>"   ...

  However, certain Goals do not follow any similar approach.

  Please review it.





________________________________

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/attachments/20120724/2d6b7c43/attachment.html>