[Fiware-security] [Fiware-wpa] The Backlog is not about describing features that assets being adopted as baseline already implement

[Bohnert, Thomas Michael]

Dear all,

Upfront, let's try to avoid escalations when possible.

Transparency is a key indicator for FI-Ware to succeed. Please mind that we are part of a program and Usage Areas have justified needs and some level of expectations/rights to know what's ongoing within FI-WARE.

The FI-WARE backlog is one tool to provide evidence that FI-WARE is working towards a common goal within the PPP. As I understood the Agile approach is a "work organization" methodology and it should be possible to plan work item (user stories, epics) via Agile without disclosing deep technical, and IPR relevant aspects of our technology (assets).

I sense that the current issue is also related to the quite intense overhead we all have to deal with at the moment. FI-WARE is on center stage and has to deal with multi-stakeholder expectations. A structured approach with sound processes and capable tooling is therefore absolutely vital to avoid major havoc in such a comprehensive project.

Being aware that this means many many emails and a very steep learning curve I hope that we, as a team, can get over this period very soon by keeping level head and discussing issues constructively. Please keep telling your concerns but bear the above in mind. It is not always possible to find good compromises and we therefore need some flexibility at all ends.

At the end of the day we all want to turn FI-WARE into a successful project and the many effort we are putting into is promising!

Best - Thomas




From: fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of Juanjo Hierro
Sent: Freitag, 7. Oktober 2011 12:02
To: Seidl, Robert (NSN - DE/Munich)
Cc: fiware-security at lists.fi-ware.eu
Subject: Re: [Fiware-security] [Fiware-wpa] The Backlog is not about describing features that assets being adopted as baseline already implement

Dear folks,

  Let me start making one thing clear: the FI-WARE Backlog is setup as a PUBLIC deliverable in the DoW.   So I'm afraid you are wrong.

  Nevertheless, as I have explained, you can deal with managing private and public info in the detailed description of backlogs entries.   So I don't see any issue.

  Please take into account that the backlog itself, as well as some info in the detail description of each entry has to be shared with users.   That's a fundamental principle setup for this program (in different parts of the DoW) but also a fundamental principle in Agile (which was agreed in the DoW as method to manage the development process).    How the hell are they otherwise going to know what you intend to provide as functionality to them so that they can confirm it covers their needs or provide comments?

  Take into account, in addition, that the aim of the program is that not just UC projects may join to provide requirements and try to use FI-WARE but other Application Developer Communities as well.   Again, this is in the DoW.

  As per description of the asset, what we are proposing is a pragmatic approach to avoid that partners had to develop too much paperwork.   Since we do not start from the scratch but really rely on already developed assets, we have to create a snapshot where we provide to the users the following information:

 *   Detailed description of what we already have developed regarding a given GE (i.e., it is implemented in the assets)
 *   What our current roadmap in terms of development is regarding the GE: this is what goes as backlog

  Point was how to deal with the first point without creating too much paperwork.  Partners bringing assets didn't want to deal with all the burden of documenting something they have ... documented before, in the project where the asset considered as baseline was developed.  Nothing to say about dealing with the useless task of translating documents they may have into "FI-WARE branded" documents.   That would be rather painful.

  So we agreed on a trade off, quite straightforward to implement while still useful: We will provide publicly available info of each asset that is already bring the implementation of part of the functionality of the GE (programmers manuals, publicly available documentation, etc.) and then the user shall be able to figure out what is the full functionality of the GE in more detail by combining the pieces: the info you provide about the baseline assets, the backlog entries declaring the developments you plan on those assets, and the high-level description in the FI-WARE product vision in order to not miss the overall picture.

  Of course, if you don't want to disclose any documentation about the baseline assets, you will have to provide the detail description of the functionality that has already been developed and comes with the asset you bring to FI-WARE.   And you have to provide it before mid October (that is the extension on the deadline I could live with) ... Is it what you prefer ?

  This approach has already been discussed since long time and agreed so I don't know what do we come with this sort of surprises at this time.

  Please confirm whether you will stay with the guidelines or whether you are going to produce a full detailed description of the functionality that is already implemented with regards to each GE based on your asset as commented before.

  Best regards,

-- Juanjo




On 07/10/11 11:27, Seidl, Robert (NSN - DE/Munich) wrote:
Dear Juanjo,
I agree with Daniel and do NOT agree with your point of view.
This approach you are refering to was not agreed with all partners and is also not part of the DOW.

I support Daniel for this topic.
Please Juanjo find a solution for this issue!
Same holds for asset description.


Mit freundlichen Grüßen
Best regards
Seidl Robert
Nokia Siemens Networks GmbH & Co. KG
CTO R SWS IDM
St.-Martin-Strasse 76
81541 Muenchen
phone +49 (0)89 5159 21106
mobile +49 (0)172 3652971
email robert.seidl at nsn.com<mailto:robert.seidl at nsn.com>



________________________________

From: fiware-security-bounces at lists.fi-ware.eu<mailto:fiware-security-bounces at lists.fi-ware.eu> [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of ext Juanjo Hierro
Sent: Friday, October 07, 2011 11:22 AM
To: GIDOIN Daniel
Cc: fiware-security at lists.fi-ware.eu<mailto:fiware-security at lists.fi-ware.eu>
Subject: Re: [Fiware-security] [Fiware-wpa] The Backlog is not about describing features that assets being adopted as baseline already implement
Dear Daniel,

  Your opinion maybe, but nothing that has to do with how we decided to approach this cooperative, open and Agile project.

  Please stay with the guidelines.

  Best regards,

-- Juanjo

On 07/10/11 10:02, GIDOIN Daniel wrote:
Dear Juanjo,
in my opinion, the backlog cannot be public; otherwise we would not put very technical information.
Daniel
De : fiware-wpa-bounces at lists.fi-ware.eu<mailto:fiware-wpa-bounces at lists.fi-ware.eu> [mailto:fiware-wpa-bounces at lists.fi-ware.eu] De la part de Juanjo Hierro
Envoyé : vendredi 7 octobre 2011 09:36
À : 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>
Objet : [Fiware-wpa] The Backlog is not about describing features that assets being adopted as baseline already implement
Hi all,

  As I have mentioned several times, the Backlog in a product development project is fundamentally about functionality that has to be developed in the product.   Seeking for clarity, and because I have found it helpful when explaining Agile concepts, I have referred to it as "work to be done" because actually what you have to do when developing a software product is developing your functionality.

  On the other hand, we have to deal with a fundamental characteristic of this project: it is not about developing from the scratch but from a baseline formed by selected products (assets) generated in previous projects.   And most of them hadn't been developed using Agile so far.

  If we had developed every GE from the scratch, the backlogs would contain Themes/Epics/Features/User-stories that, all together, would summarize the whole functionality of the GE.  But this is not the case.

  You should consider that the backlog for each and every GE should contain the Themes/Epics/Features/User-stories that, at the current moment, is "pending functionality" (or development) still to be addressed.   It is not the intent that, by reading all entries in the backlog, you should have a complete view on the functionality of the GE.  Someone who wants to have a detailed picture of all target functionality should:

 1.  read the FI-WARE Product Vision, in order to understand what is overall expected for the GE
 2.  read the documentation available for the baseline assets used for materializing the GE: this should give the reader a clear picture of what is already there
 3.  read the backlog, to understand what's going on and is somehow on the roadmap
  The exercise we are doing is about setting the Agile backlogs that will drive our future developments.  It's not about documenting what he have done during many years in our respective labs.

  A last comment: some Agile authorized experts go up to the point that they believe that Backlogs should not only contain info about the functionality to be developed in the product but any "work to be done" by the development team of a product, thus, using Agile for managing every activities in a project.   That's why they mention that entries in a Backlog should be indeed named as "Work Items" rather than "User-stories" ... but that is, of course, a matter of taste.   What is mandatory is to document the Themes/Epics/Features/User-stories that will drive developments on selected assets (this include developments required for integrating the different assets, of course).  This is what should be uploaded on the Wiki and referred from tickets in the "Backlog Management" tracker.   You may create another "Backlog" trackers for additional activities (like documentation, etc.).   That's why I created a "Task Force Management" tracker in addition.

  Remember: Agile is about creating stuff that is useful in the development, not stuff for satisfying reviewers.

  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

________________________________
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/old-fiware-security/attachments/20111007/7d4308a5/attachment.html>