[Fiware-data] Fwd: [Fiware-wpa] Usage of potentially confidential info in full description of backlog entries (particularly, User-Stories)

[Juanjo Hierro]

-------- Original Message --------
Subject:        [Fiware-wpa] Usage of potentially confidential info in full description of backlog entries (particularly, User-Stories)
Date:   Fri, 7 Oct 2011 09:38:36 +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,

  According to Agile, a Feature (or an User-Story) should contain all the information that is enough as to allow the development team to warrant that development can be complemented with the duration of a Release (Sprint).   This would go in the "Detailed Description" field of the corresponding entry in the Backlog.

   I don't want to elaborate more on this, unless some of you believe I should, because I have already elaborated a lot in previous emails (particularly relevant, those referring to INVEST properties).   What comes next will be elaborated around User-Stories, but also apply to Features.

  Of course, it is also helpful that development teams use the User-Story entry as a placeholder for any valuable info that will help to guide the development, even in addition to that one which may be considered "enough".  It would be a way to avoid dispersing the information.

  Then the following questions come:

 *   I may have part of the information that I should introduce into the detailed description that I may have in internal documents that also hold some confidential information I don't want to disclose ... and I don't want to re-write those parts in the backlog.    What should I do ?
 *   I may be using Agile inside my company to carry out development on my asset ... but I'm not using FusionForge tools for this purpose ... I may even be using a kind of tracker, but not the one in FusionForge ... Should I replicate what I have in place for driving the development ?
 *   I may even be fine with writing some parts in the detailed description (they are not documented anywhere else I can provide an URL link to) but I would like to be careful because I maybe disclosing confidential info about how my particular implementation is developed

  I believe we should be pragmatic ... even to the risk of annoying our reviewers :-)  Remember: the backlog should be useful for us in driving our developments.

  Therefore, I would recommend following the principles below:

 *   You may structure info in the "Detailed description" field in the entry of a backlog into two sections:
    *   public: there you provide all the description that users would require to confirm that the functionality you are describing is also "enough" for them.   Remember, that an Agile principle we also have to preserve is that the backlog should become a major communication tool between users and the development team.   So don't get crazy and suddenly make everything private, come on.
    *   private: there you will provide URL links to places that are private (even links that may only work if you are on your private network).   I would highly recommend that this section comes with an initial statement such as "Following is a list of private URL resources that include additional valuable information for the development team that should be preserved as private"
 *   Among other things, we will setup a private Wiki (actually, a Wiki instance linked to some project in FusionForge only partners in the FI-WARE project will get access to).   You can also use it to bring stuff you will refer from the public backlog but relates to info you can share with the rest of the partners but still want to keep as non-accessible from the rest of the world.

  This way, I believe we can manage with all confidentiality and other practical concerns (particularly, avoid cloning what you have internally).

  Best regards,

--
Juanjo Hierro
Chief Technologist on Software Technologies
Telefonica R&D Labs

email: jhierro at tid.es<mailto:jhierro at tid.es>
phone: +34 91 48 32932
www.tid.es<http://www.tid.es>
twitter.com/JuanjoHierro

Oeste 1, Planta 5. Distrito C
Ronda de la Comunicacion s/n
Madrid 28050
Spain

________________________________
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-data/attachments/20111007/eec1193c/attachment.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ATT00001..txt
URL: <https://lists.fiware.org/private/old-fiware-data/attachments/20111007/eec1193c/attachment.txt>