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

[TRABELSI, Slim]

Dear all,

I agree with Daniel’s issue. As far as I know according to the consortium agreement SAP development information is not public.

Thank you
Best regards
Slim

=====================================
Dr Slim Trabelsi
Researcher

Security & Trust
SAP Labs France
805, Avenue du Docteur Maurice Donat
BP 1216 - 06254 Mougins Cedex, France
T +33 4 92 28 63 45
M + 33 6 11 99 85 79
www.sap.com

From: fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of Pedro Soria Rodriguez
Sent: vendredi 7 octobre 2011 11:30
To: Seidl, Robert (NSN - DE/Munich); ext Juanjo Hierro; GIDOIN Daniel
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


Hello, I’d like to support Robert and Daniel.

In WP8,  we at Atos are also concerned about the public visibility of the backlog.

The backlog aids development, but development is a task of the consortium, and public visibility is not needed.

--
Pedro Soria-Rodriguez
Head of Sector
Atos Research & Innovation
Albarracín, 25
28037 Madrid, Spain

Email: pedro.soria at atosresearch.eu<mailto:pedro.soria at atosresearch.eu>


From: fiware-security-bounces at lists.fi-ware.eu [mailto:fiware-security-bounces at lists.fi-ware.eu] On Behalf Of Seidl, Robert (NSN - DE/Munich)
Sent: Friday, October 07, 2011 11:28
To: ext Juanjo Hierro; GIDOIN Daniel
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 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] 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
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

------------------------------------------------------------------
This e-mail and the documents attached are confidential and intended
solely for the addressee; it may also be privileged. If you receive
this e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos
group liability cannot be triggered for the message content. Although
the sender endeavours to maintain a computer virus-free network,
the sender does not warrant that this transmission is virus-free and
will not be liable for any damages resulting from any virus transmitted.

Este mensaje y los ficheros adjuntos pueden contener informacion confidencial
destinada solamente a la(s) persona(s) mencionadas anteriormente
pueden estar protegidos por secreto profesional.
Si usted recibe este correo electronico por error, gracias por informar
inmediatamente al remitente y destruir el mensaje.
Al no estar asegurada la integridad de este mensaje sobre la red, Atos
no se hace responsable por su contenido. Su contenido no constituye ningun
compromiso para el grupo Atos, salvo ratificacion escrita por ambas partes.
Aunque se esfuerza al maximo por mantener su red libre de virus, el emisor
no puede garantizar nada al respecto y no sera responsable de cualesquiera
danos que puedan resultar de una transmision de virus.
------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fiware.org/private/old-fiware-security/attachments/20111007/bd1d49b8/attachment.html>