All,
Please, see below guidelines from Juanjo on managing assets and backlog.
We will resume our weekly calls and start discussing this on August, 9th
(at our regular slot -- 11am).
Please, send *before* that meeting the initial list of assets that you
consider for each of the GEs.
Regards,
Alex
----- Forwarded by Alex Glikson/Haifa/IBM on 29/07/2011 02:47 PM -----
From: Juanjo Hierro <jhierro at tid.es>
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 point.
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)
1. 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.
2. 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.
3. 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
_______________________________________________
Fiware-wpl mailing list
Fiware-wpl at lists.fi-ware.eu
http://lists.fi-ware.eu/listinfo/fiware-wpl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110729/df8d2192/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/old-fiware-cloud/attachments/20110729/df8d2192/attachment.xls>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: jhierro.vcf
Type: application/octet-stream
Size: 443 bytes
Desc: not available
URL: <https://lists.fiware.org/private/old-fiware-cloud/attachments/20110729/df8d2192/attachment.obj>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy