[Fiware] Clarification on task dealing with documentation of Features describing FI-WARE GEs

[Juanjo Hierro]

Dear all,

  Let me clarify, at the risk of repeating myself a bit, some aspects about the task dealing with documentation of Features describing FI-WARE GEs.    I believe that what I'm going to explain in this email has already been explained several times, at leas communicated to WPLs and WPAs, but I hope that repeating it again is not harmful and may be helpful.

  The target goal of the task is to end up with a set of "Features" for each FI-WARE GE that provides a complete description of the functionalities supported by that GE.

  When we created the first version of the backlogs linked to all FI-WARE GEs back in month 7, it was agreed that it was only necessary to include entries (Themes, Epics, Features, User Stories) linked to new functionalities that we were going to develop on top of selected baseline assets during the course of the FI-WARE project.   This agreement was captured on the wiki page where we describe how we were planning to use Agile:


In defining how we were going to use Agile in FI-WARE, we have had to deal with a fundamental characteristic of the project: it is not about developing from the scratch but from a set of selected products (assets) resulted from previous projects, many of which hadn't been developed using Agile. If we had started development of every FI-WARE Generic Enabler (that's the way we name components in FI-WARE) from the scratch, the FI-WARE GE backlogs would contain Themes/Epics/Features/User-stories that, all together, would summarize the whole functionality of FI-WARE. But this is not the case.

When creating the backlog for a given FI-WARE GE, we have considered that it should contain the Themes/Epics/Features/User-stories that, at the start of the FI-WARE project, map to "functionality to be developed" in the reference implementation of the GE we are building based on a number of baseline products. We won't capture all the functionality that was already implemented in the baseline products. That would mean trying to carry out a kind of "reverse engineering" of baseline products, deriving User-Stories from what those baseline products already support. This, apart from meaning a huge effort would not be be that useful to development teams and would simply delay start of our development.

  This didn't prevent the development team behind a given FI-WARE GE to define the whole set of Features characterizing all the functionalities of a given FI-WARE GE, including functionality already supported by the selected baseline assets.   We simply didn't force them to do so (it was not mandatory).    However, apparently some of the teams did this at month 7.   That's fine and this only means they don't need to add entries for Features now.

  Remember: the target goal now is to end up with a set of "Features" per FI-WARE GE that provides a complete description of the functionalities supported by the GE.

  Why are we doing this exercise if we had agreed that documenting Features already supported in baseline assets was not mandatory ?   Essentially because we have had to deal with a comment made by reviewers on the Technical Roadmap deliverable that was the major cause why they rejected that deliverable: we were not giving enough details of what was going to be provided by each GE in each major release (including functionalities supported already by baseline assets in the case of the first major release).   The decision was to handle this comment by means of completing the backlogs of FI-WARE GEs to add "Features" that describe the complete set of functionalities of the GE.

  Those teams that already identified the complete set of Features describing a FI-WARE GE back in month 7 would not need to do anything.   On the other hand, this shouldn't be that difficult for the rest of the teams that didn't include features describing functionalities supported by baseline assets at that time.   And we will solve the comment for sure (do you want to know what a given FI-WARE GE will give in the first major release ?   just take a look a the following Features description).   It's true that it would be something that overrides what we explained on the wiki about following Agile (the text copied above) but we will certainly fix that text on the wiki after the task is finished.

  Do we need to create entries in the trackers corresponding to added Features ?   I would say it is not mandatory but certainly highly desirable and a goal to achieve not later than September (it would be a matter of one hour - two hours maximum once the Features are registered on the Wiki).   When doing so, we agreed that teams should assign a value "FI-WARE.Release.0" to the "FI-WARE Release Id" field.

  Note that you don't need to derive any short of User Story from Features linked to functionality supported by baseline assets.   User stories should map to Features that have been planned for development during the course of the FI-WARE project.

  How are we going to elaborate on what Features of a given GE are going to go for the first major release and what Features are going to go for later major releases within the revised version of the Technical Roadmap deliverable ?   This is something that we have not closed yet but will be closed in the joint WPLs/WPAs follow-up confcall that will take place on July 23rd.   For the time being, we prefer that you concentrate on all what is needed to meet the July 23rd deadline (maximum extension of the original deadline by end of June that we communicated to our POs regarding late delivery of deliverables linked to FI-WARE GEs).

  Are we going to distinguish between Features planned to be developed in the first Release and Features already supported by baseline assets within the Technical Roadmap deliverable ?   I believe it is not needed.   All of them together comprise the Features that describe what is going to be supported in the first major release and that is what really matters to a potential user of a given FI-WARE GE in the first major release: what is the set of features that the GE will support that they can use.

  Hope this helps, although I guess most of what is being explained was already understood by you.

  Best regards,


-- Juanjo

-------------
Product Development and Innovation (PDI) - Telefonica Digital
website: www.tid.es<http://www.tid.es>
email: jhierro at tid.es<mailto:jhierro at tid.es>
twitter: twitter.com/JuanjoHierro

FI-WARE (European Future Internet Core Platform) Chief Architect

You can follow FI-WARE at:
  website:  http://www.fi-ware.eu
  facebook: http://www.facebook.com/pages/FI-WARE/251366491587242
  twitter:  http://twitter.com/FIware
  linkedIn: http://www.linkedin.com/groups/FIWARE-4239932


________________________________

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/20120718/c1714617/attachment.html>