Hi all,
I pass you another copy of the original message which I have updated to capture the response of to some of the valuable comments you have made during the confcall this morning. This way, we have a single source were hints about how to face next steps are described.
I have added also the remark on what should be registered in the backlog (not entries describing what a current asset may already provide but rather "work to be done")
Please don't hesitate to ask any question you may have. This is a process that we are about to launch and it is important that we launch it the right way.
Thanks and best regards,
-- Juanjo
-------- Original Message --------
Subject: [Fiware-wpl] VERY IMPORTANT: Coordination of FI-WARE backlog related activities
Date: Thu, 28 Jul 2011 03:24:44 +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>
Hi all,
Once we have dealt with the FI-WARE High-level Description (Product Vision) we have to start working in three major tasks on which we should concentrate our efforts until our plenary meeting in Turin:
1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog
2. Management of relationship with FI-PPP UC projects
3. Launch of activities dealing with development of contents of the FI-WARE website (setup of the public Wiki and start of activities in blogs)
This email elaborates on the first two points. We will review this in the confcall we have scheduled for July 28, 11:30am
Cheers,
-- Juanjo
1. Launch of activities dealing with final decision on assets and the creation of the FI-WARE backlog
At this point, I assume that you already understand the basis of how we plan to use Agile in our project. It summary, we will use it for managing the FI-WARE requirements, which will take the form of entries in what we refer as the FI-WARE backlog. In any case, please review the presentation I made during our kick-off meeting in May:
https://forge.fi-ware.eu/docman/view.php/7/37/FI-WARE+agile+Intro+vfinal.pptx
Following is the list of steps and considerations to take into account when launching the activities dealing with final decision on assets and the creation of the FI-WARE backlog:
* The first step we have to deal with has to do with closing the decision on the assets we will adopt as baseline for the reference implementation of each of the GEs. For this, every WP will have to come with a first proposal by August 31st on what asset, from what project+partner, will be adopted as baseline for the reference implementation of each of the GEs in the corresponding chapter. The different WP/chapter teams have to start this exercise now. It may not be feasible to close the mapping of assets for each of the GEs identified in a given chapter. This may be particularly the case for assets related to GEs for which there are still may points under discussion. It may also happen that we have identified assets for some of the components of a GE but not all. But at least we should have a relatively mature list of assets identified for the main GEs in each chapter by August 31st. This represents a first action point on WPLs and WPAs.
* There are some special cases in which we have a GE but two "competing" assets. Unless the contributing partners agree to carry out a joint development (open source or not), the number of GEs where this happens may allow us to make exceptions and allow two alternative reference implementations for the same GE (this instead of artificially trying to merge both). Of course, we have to work so that the two assets end up supporting the corresponding GE open specifications (APIs, protocols, visible behaviour) which should be only one. We also have to be able to provide enough rationale for this decission (e.g., reference implementations rely on different persistence technology or the combination of the two is what may allow an application provider to setup the most efficient solution in some large-scale, highly distributed architectures. We have to be very careful and analyze each of the cases where we will allow alternative reference implementations. These should be exceptions. Currently, the only one clearly identified is the Publish/Subscribe Broker GE, where two reference implementations (one from Orange, another from TI) will be developed. It has been pointed out that some of these exceptions may be found in the IoT chapter but we have to carefully analyze them and provide the rationale (here, I would add that we also have to find the way to reach the necessary alignment with APIs specified in the Data/Context Management chapter.
* Once assets have been identified (for some of the GEs, this decision may be taken right now) we have to start to populate the FI-WARE backlog.
* The fields for entries in the FI-PPP backlog (which includes the FI-WARE backlog) have already been defined and correspond to the ones described in the attached template (spreadsheet). Note that entries in the FI-PPP backlog will not comprise just features/user-stories linked to FI-WARE GEs but to other platform enablers which may happen to be common to several applications while still domain-specific. It will also comprise the backlogs of some of the UC projects, associated to their actual application development project, but only for those UC projects that have agreed to follow Agile. If you have any question/doubt regarding semantics of any field in the template, please let Thomas or me know.
* Regarding tools to create, maintain and manage requests on entries of the FI-PPP backlog, the following has been agreed:
* The FI-PPP will use Agilefant in order to perform the overall management of entries in backlogs. The FI-PPP will go for a configuration where we will define multiple backlogs in Agilefant. One per GE in each chapter, one covering entries for all the still uncategorized platform enablers, one (at least) for other platform enablers that are common but domain-specific (therefore out of the scope of FI-WARE) and one per each of the UC projects that wish to use Agilefant to manage their own application backlog (not all). This with the ability to transfer entries from one backlog to another.
* However, Agilefant is pretty simple, and entries of a backlog in Agilefant cannot be flexibly configured as to contain all of the fields we have defined for the FI-PPP backlog template (attached). Therefore, the description field of each entry in an Agilefant backlog will have to include an URL link to a page on a Wiki (based on Wikimedia) where all fields for that entry, as defined in the attached spreadsheet, can be fully specified. Regarding entries linked to the FI-WARE backlogs, and probably also for entries linked to platform enablers in general, this wiki will be provided by FI-WARE. ATOS, Thomas and me will work on defining the process and instructions on how to create backlog entries in the Wiki and in Agilefant before Thursday next week. In the meantime, you may wish to start working on entries, just using spreadsheets following the attached template.
* FI-WARE will put in place some system to manage the lifecycle of requests to create new entries in the FI-WARE backlogs or modify existing ones by third parties. This tool should not be offered just to UC projects but to the general public, because we have to be open to other communities. Most probably this tool will be the tracker system in FusionForge but we are still analyzing whether it could be managed directly through Agilefant, defining an intermediate backlog about "request for platform enablers" where request for entries formulated by UC projects would be created and only transferred to the FI-WARE backlogs when agreed with FI-WARE. However, the issue of dealing with other third parties/communities may lead to the need to put a more formal system such as tracker. ATOS, Thomas and me will work on this matter during the following days and will inform you before Thursday next week about what tool has been decided and what will be the procedures to follow.
* One point that was already understood and agreed during the FI-PPP AB is that requirements from end-users on applications to be developed by UC projects are different from requirements on FI-WARE (on platform enablers in general). During investigation of a end-user requirement "X" (no matter if it is a Theme, an EPIC or an user-story), a given UC project may conclude that it needs to rely on a platform that support a number of features "a", "b", and "c" plus develop an application implementing functionalities "M", "N", "O" on top of that platform. These "a", "b" and "c" features should translate into entries initially linked to the "platform enablers" backlog. Some of them will finally be addressed in FI-WARE so therefore will be transferred to the FI-WARE backlog. Whether we will manage this transference directly on Agilefant or through a tracker system, is something to decide. Nevertheless, note that specification of "X", "M", "N", "O" will not be part of the FI-WARE backlog. The level of concreteness is also different: "X" and even "M", "N" and "O" may be very concrete, with a quite detailed specification. However, "a", "b" and "c", at the time they are formulated by a UC project, may be just in the form of a "theme" or "epic", according to Agile terminology.
* Entries in backlog should evolve from Themes, to EPICS up to user-stories. Following remarks apply:
* The frontiers between Themes and EPICs use to be diffuse, they correspond to description of features at different levels of granularity. However, what is important is that user-stories provides all the details of WHAT has to be done that a development team need to know to perform their development work. Themes and EPICs matches different stages of approximation during the interaction process you have to perform until you end up having well detailed user-stories. Note that when refining an EPIC, you may end up having it split into several finer-grain EPICs, but still EPICs. You may also end up having it split into several finer-grain EPICs and some user-stories (covering part of the original EPIC)
* When planning a given sprint in Agile, only highest priority user-stories are considered. Themes and EPICs obviously not. This is because, at a given sprint, you only work on what can be done (get finished) by the end of the sprint. This means that if we have a MUST Theme or EPIC, it will never be developed before a COULD user-story. Themes and EPICs simply cannot be done (because development teams do not have all the info they need to implement them).
* At a given point in time, features "a", "b" and "c" will be submitted to FI-WARE for consideration. This means they will first be submitted to the "platform enablers" backlog. FI-WARE will then determine whether the feature can be considered inside the scope of FI-WARE and what priority is finally assigned. This decision will most probably imply several interactions with the UC projects that have identified the features. As mentioned before, we will come in the coming days with a concrete proposal on tools and procedures adopted for managing this process.
* Parallel to this process, UC projects may additionally require further clarifications about what we intend to deliver in a given chapter, for a given GE. In other words, they may ask for clarifications on parts of the FI-WARE High-level Description (Product Vision). This should be driven in a formal manner, to avoid getting into chaos. Therefore, a specific tracker system associated to the High-level Description (Product Vision) will be put in place for UC projects to formulate their questions. Explanations given to resolve tickets should lead to creation/update of contents in a FAQ Wiki we should start creating. This system will be also offered later to the general public,
* Parallel to UC projects running the process described above, FI-WARE should, own its own, work in defining entries for the FI-WARE backlogs. Whether they will be still generic ("themes" or "epics") or already detailed user-stories ready for implementation will depend on how clear we have things regarding the GEs in each of the chapters. There are three different types of entries that FI-WARE chapter teams should be able to generate from now until the Turing meeting (as a first milestone)
* Entries related to new functional or non-functional features we need to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to cover the gap between what that given asset supports at the time it is contributed by a given partner to the project and what it should support to actually become (part of) a reference implementation of the given GE. This will map to features we want to support during lifetime of FI-WARE. They should have a MUST or SHOULD MoSCoW priority assigned.
* Entries related to new functional or non-functional features we wish to implement in an asset adopted as baseline for the development of the reference implementation of a given GE (or part of it), in order to further evolve it and therefore, evolve the corresponding GE (since GEs specifications may evolve over time and offer different functionality in subsequent releases of FI-WARE). This will map to features we may not support during lifetime of FI-WARE, for sure won't fit in the first release. They should have a SHOULD or COULD MoSCoW priority assigned.
* Entries related to integration of assets, in those cases where an asset has to be combined with other assets to build the reference implementation of a given GE. Note that these entries are different than those ones related to implementing interfaces/protocols, etc in an asset implementing (part of) a GE, in order to support integration with another GE, because interfaces/protocols enabling integration of GEs should be part of their open specifications and, therefore, should be considered a particular case of points 1. or 2.
A very IMPORTANT note: entries in the backlog should not describe what the assets adopted as baseline already provide, but what must, should, could be developed in those assets (see MoSCoW priority field in the attached template for FI-WARE backlog entries). A reminder about semantics linked to MoSCoW priorities:
* MUST - Features that absolutely have to be done are categorized as Must. If any of these features are not done, the project will be considered a failure.
* SHOULD - Features that are important to the success of the project, but are not absolute musts (they have a workaround or will not cause the project to fail) are categorized as Should
* COULD - Features that are nice to have but are not core features are categorized as Could.
* WON’T - Features that are not going to be implemented this time are marked as Wont.
Remember that entries in the backlog are about "work to be done". User stories are, besides (and this distinguish them from themes and epics) work that is well-defined/detailed enough as to able to be done. Sometimes, it will be appropriate to create an user-story related to the specification of the API (or part of the API) that a given GE will have to provide and differentiate it from implementation (support) of some of the operations of that API, once it has been specified.
* Note, that regarding a given feature request, there will be essentially five scenarios:
* The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, and for which an asset has already been identified (therefore we have already identified entries for it in the FI-WARE backlog)
* The feature applies to some of the GEs we have already identified in the FI-WARE High-level Description, but for which an asset hasn't already been identified (it is a gap we have already identified that none of the partners in FI-WARE is able to fill contributing an asset)
* The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it in the roadmap, despite no partner has an asset that can be contributed as baseline for development of a reference implementation
* The feature applies to some GE we hadn't identified initially in FI-WARE (in the FI-WARE High-level Description) but we agree to incorporate it, and there is a partner that has an asset that may be contributed as baseline for development of a reference implementation
* The feature applies to some enabler we hadn't identified initially in FI-WARE and we don't agree to accept it as GE since it is a common, yet domain-specific, platform enabler, but not a GE
The first case will lead to negotiation of priorities between us and the UC project. The second and third case will lead to requirements that we should take into account in our Open Calls. The fourth case require careful consideration because we won't be able to change the assignment of resources to a given partner. We need to calibrate whether the partner can adjust its efforts to deal with more GEs that the originally planned (maybe addressing less new functionality in each) or we should finally issue an Open Call for the GE being considered.
* Despite the most active UC projects may start creating some initial requests for entries in the FI-WARE backlog during August, I do not expect so much activity, so keep going on your own, generating entries in the FI-WARE backlogs based on the principles of the previous point. During September negotiations with UC projects should become more intense. We indeed agreed with the UC projects to have a milestone by end of September in which we should already have produced a number of entries in the FI-WARE backlogs on our own, and they should have been produced some requests for entries in our FI-WARE backlogs. A period of negotiation/consolidation is then planned, which should end by end of November, with the first official release of the FI-WARE backlog to be considered for the first release of FI-WARE and also a clear definition of what we are going to request in the first Open Call of FI-WARE
* Some people have asked to me what should we do regarding the the second release of the FI-WARE High-level Description (Product Vision). We will transfer contents of the first official release of the FI-WARE High-level Description (Product Vision) to the public Wiki at the website. From then on, we will work making updates on the Wiki, so we will get rid of editing MS Word documents, etc. Therefore, delivery of the second release of the Product Vision will consist essentially in ... passing an URL. Note that major changes will be incremental, located in very concrete places and delivered in a "continuous". The type of changes that I would expect would distinguish the second release compared to the first one are the following:
* we should include a dedicated section per GE elaborating on the asset selected as baseline, which mostly will contain links to existing documentation which explains what the asset already provides today (user's/programmers guide, etc, whatever valuable documentation is available). This mostly what is going to be new in this "second release" (despite talking about releases would not make sense any more ... we will work in a continuous)
* we will probably need to update/add some content as a result of tackling some of the "topics still under discussion"
________________________________
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
________________________________
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-wpl/attachments/20110729/417f38ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Backlog entries description v0 1 11-07-12.xls
Type: application/vnd.ms-excel
Size: 52224 bytes
Desc: not available
URL: <https://lists.fiware.org/private/fiware-wpl/attachments/20110729/417f38ac/attachment.xls>
-------------- 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/fiware-wpl/attachments/20110729/417f38ac/attachment.vcf>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy