[Fiware-wpa] Fwd: FI-WARE replanning proposal

[Juanjo Hierro]

Hi all,

  Yesterday, a virtual meeting of the FI-PPP AB took place and I took the opportunity to explain the UC projects that we have proposed our PO to perform an adjustment of the planning of several of the short-term milestones linked to FI-WARE.     My intention was to gain their support in approval of this re-planning so it can be seen as something that would go for the sake of the programme (exactly as I see it).   Gaining the support from the UC projects was a target goal in this movement as highlighted during our last joint WPLs/WPAs confcall.

  Despite I explained this to them during the virtual meeting, we agreed that I was going to send them an email elaborating on the matter.   Below, you will find that email.   Please devote the necessary time read it carefully.

  Also, as per agreement in our joint WPLs/WPAs confcall, I have modified our proposal for re-planning so that we keep the target goal of delivering a first take of the FI-WARE Testbed by end of July.  We would just split the first release into one first deployment to be delivered by end of July and then an upgrade to happen by end of September.

  Personally, I rather doubt that UC projects are going to work hard in the FI-WARE testbed during August-September due to the summer holidays and the fact that they will be pretty much devoted to development of their proposals to phase 2.   However, I can live with keeping the milestone end of July and, of course, this should be helpful in selling the re-planning because, overall, UC projects are not affected (they will receive the FI-WARE API specifications and will be able to play with the FI-WARE Testbed more or less on the initially planned dates).   I have also informed Arian that we would keep the milestone for delivery of the FI-WARE Testbed by end of July.

  Note that, besides the educational sessions programmed in May 21st and June 4th, I have proposed to setup a dedicated team that will be devoted to follow-up and push progress on tickets issued by UC projects.   Note that they will issue tickets regarding doubts/questions/clarifications on the FI-WARE Architecture, Roadmap or Open Specifications deliverables using the "FI-WARE General Support" tracker that was setup in the FI-WARE project in FusionForge.    It's true that devoting time to handle interaction with UC projects around the trackers means devoting the necessary resources, so that is another good argument to ask for the re-planning.

  Comments, feedback are welcome.   Be aware that I'm trying to move fast in getting a final decision on the re-planning and the implementation of the action points to improve overall communication with the UC projects.

  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



-------- Original Message --------
Subject:        FI-WARE replanning proposal
Date:   Fri, 13 Apr 2012 05:08:29 +0200
From:   Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es>
To:     ab at fi-ppp.eu<mailto:ab at fi-ppp.eu> <ab at fi-ppp.eu><mailto:ab at fi-ppp.eu>


Hi all,

  In this mail, I will try to summarize what I explained to you during our confcall yesterday.

  Within FI-WARE, we feel that is rather important to improve communication with UC projects, leading to a better overall understanding of FI-WARE by UC projects.   In order to achieve this goal, we have identified two first action points:

  *   Improving overall response to tickets issued by UC projects (both regarding the "FI-WARE Theme/Feature/Epic Request" and the "FI-WARE General Support" trackers) by means of setting up a dedicated team to follow-up and push progress on tickets.
  *   Setting up two full-week f2f "educational sessions" where UC projects' and FI-WARE's teams can meet together so that:
     *   Architects and potentially members of the different FI-WARE Chapter development teams will have the opportunity to meet developers from the UC projects, elaborate on the architecture and functionality of the different FI-WARE GEs and answer their technical questions
     *   UC project architects can present the architecture of use case scenarios, elaborating on how they plan to use FI-WARE, as to collect feedback from FI-WARE members.

  Despite we have put in place a well defined process, supported by tools, to handle the interaction between UC projects and FI-WARE, the usefulness of them has been limited, leading to a sentiment of frustration both on the side of UC projects and FI-WARE.    This in my view is a consequence of starting the UC projects at the same time as FI-WARE, which has been proven not to be the best idea.   Actually, UC projects have produced a lot of tickets, but they are too much generic or high-level so it takes too much time to interact until being able to provide accurate answers.   On the other hand, UC projects can argue that they couldn't be more concrete until there is no more detailed information about FI-WARE.     We have the opportunity to recover from this situation because we are now able to discuss about more concrete stuff, namely the FI-WARE Architecture description (already available now) and the FI-WARE API specifications (to be delivered soon.)   The above mentioned action points would help to make sure that the communication between UC projects and FI-WARE around this more concrete stuff is put at the right level.



  However, despite we see this is a the right thing to do at this moment, it is also a fact that implementing the above mentioned action points would keep architects and development teams in FI-WARE apart from their current development activities at a critical point in the development, very close to a number of relevant milestones according to the FI-WARE DoW.

  Because of that, FI-WARE has made a proposal to its PO about a re-planning of some of its short-term milestones.   This would allow FI-WARE to allocate the necessary resources that would be demanded by the action points mentioned above and ensure success of that action points.   This re-planning, however, has been designed in order to minimize overall impact on UC projects.   It is also worth noticing that it would lead to adjustment of dates for deliverables due in month 12 and 15, but the rest of dates can be kept so dates linked to delivery of the FI-WARE second release would not be affected.   The proposed re-planning can be summarized as follows:

  *   Keep delivery of FI-WARE GE Open Specifications (i.e., REST API specifications) due in month 12 since they seem to be in the critical path of UC projects and there shouldn't be so much problems delivering them on that date.    Some of them may arrive sometime mid May but not later and, in any case, would be available for the educational sessions.
  *   Delay those M12 deliverables dealing with delivery of FI-WARE GE software, accompanying guides and unit testing plan 2 months, so they are delivered on month 14 (end of June).   This would also apply to deliverables linked to FI-WARE Development Support Tools also due in month 12.
  *   Keep delivery of the FI-WARE Testbed in month 15 (end of July) but split deployment of the first FI-WARE Release into two steps, so that a first set of GEs will become available by end of July, but a second set of GEs will become available in an upgrade of the testbed to take place by end of September.    Indeed, subsequent upgrades will be planned every three months after end of September, or even more frequently after each FI-WARE Sprint, following an Agile approach.   What would come by end of July instead of end of September is described in the FI-WARE Technical Roadmap (http://forge.fi-ware.eu/plugins/mediawiki/wiki/fiware/index.php/FI-WARE_Technical_Roadmap).   Note that this split into two steps would not apply to all chapters.   If no split is declared in the Technical Roadmap for a given Chapter, it means that all GEs in the first release for that chapter are planned to be available by end of July.
  *   Delay or drop some deliverables due in month 12 whose delivery is not so critical for the programme at this moment from FI-WARE's point of view:
     *   Drop deliverable on "System/software Engineering Method for FI-WARE" due by month 12, since the FI-WARE consortia considers that working on this deliverable rather makes more sense once the first release of FI-WARE has been delivered.   We have proposed to drop the first release of this deliverable, (keeping just two releases on months 24 and 33)
     *   Delay deliverables about "Third party innovation enablement in FI-WARE" and "State of the Art Analysis" due by month 12 so they are post-poned to month 21 or at least month 18.

  Hope this helps to explain the point.   As you see, the two points that may impact UC projects are the first and third and, there, we essentially don't change what we initially planned.   The other points may be considered indeed internal to FI-WARE.    However, our understanding is that our PO, Arian Zwegers, wants to verify whether UC projects agree that the measurements we intend to put in place to improve communication with UC projects, mostly preparing and carrying out the educational sessions, are rather important and would benefit the programme.   In other words, he wants to see whether delaying deliverables in FI-WARE can be justified for the sake of the programme.

  From my point of view, approval of this re-planning is required to be able to support the educational sessions and also push management of the interaction with the UC projects at the right level.    So the right thing to do would be to tell the EC that "yes, we need to have these educational sessions and to improve the management of the interaction through the tracker systems".

  If you agree that this is actually the right thing to do, our request would be that you inform your PO ASAP that this proposal is on the table and give them a positive feedback.   It may happen that they were planning to contact you soon, because our PO was going to ask them.  That was also why I wanted you to be informed.

  As per agreement in our confcall yesterday, let's have a continuation confcall on Monday afternoon to wrap up on this important matter.   In the meantime, don't hesitate to ask any question you may have so that I can answer over the email.

  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/fiware-wpa/attachments/20120413/72174136/attachment.html>