FYI, 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 -------- Original Message -------- Subject: Re: [Fiware-wpl] IMPORTANT Clarification Date: Mon, 03 Oct 2011 16:43:42 +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-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> On 29/09/11 14:16, Alex Glikson wrote: I'm a bit concerned that the fine-grained details of individual stories and tasks might potentially reveal internal details of our background assets -- some of which are not supposed to get exposed to the public. Also, it might be just too many details for anyone outside the development team. So, I think we should look for a reasonable level of details in the public tracker of each Chapter (and the corresponding Wiki space). It seems to me that the level of minor releases (3 months long) and features associated with each of them (as well as the prioritized backlog of unassigned features, grouped by Themes) is just about right granularity. I will respond on this in another mail. Regarding using Forge tasks for management of user stories and sprints -- in addition to the privacy issue above (e.g., we might want to keep them in Forge spaces of individual WPs), I'm not sure it is customizable enough. For example, I haven't found a way to define a custom field that would refer to the Sprint (using start/end dates is not very convenient). Also, I haven't found a way to filter tasks by Epic/Theme, which might be convenient. And there are few other limitations. This is a comment I do not understand very well. You should still work with the tracker for many of the things that deal with management of user-stories and sprints ... That is, for example, planning a user story for a given sprint. That's indeed the reason why you should assign the Sprint Id of the next sprint to a User-Story when it becomes planned for that sprint ... This should allow you to easy browse/monitor what user-stories are part of the current sprint. Creation of tasks is analogous to creation of tasks in Agile. And the Task Manager is just a useful tool that is at your service for handling tasks you would typically carry out in the context of a sprint following Agile. As simple as that. Therefore, I wouldn't rely on the Task Manager to search for the User-Stories that are being tackled in the current Sprint. I would browse/query the tracker for that purpose. Last but not least, I would consider usage of the Task Manager even something not strictly mandatory to GE development teams. It's up to you to decide whether to use it or not. Furthermore, you should use it if you really find it helpful. We have to be pragmatic and realize that we are bringing on the table a set of assets, each of which is being developed in the lab of some partner and not necessarily just for FI-WARE. I would even say that if it were only for FI-WARE I would be a bit worried :-) because it is supposed that they are asset considered strategic in their respective companies, therefore having other "customers". It will be "naive" to think that the development teams behind those assets are going to adapt the way the work to FI-WARE methodologies and tools. They may be using JIRA (for example) and therefore may be managing the tasks dealing with implementation of a user-story in a given sprint using the tools for task management that JIRA provides. Does it make sense that they throw it away their tools and start using the FusionForge Task Management instead ? Probably not. Therefore, the FusionForge Task Manager tool is there to help but not to create additional burden. Of course, what WP Leaders have to do is to negotiate with development teams behind each and every GE how they can follow-up progress of the development teams during the current sprint. Again there, is where usage of the FusionForge Task Manager tool can be evaluated to find out whether it would be helpful or not. Hope this answer helps. Best regards, -- Juanjo Regards, Alex From: "Bohnert, Thomas Michael" <thomas.michael.bohnert at sap.com><mailto:thomas.michael.bohnert at sap.com> To: Alex Glikson/Haifa/IBM at IBMIL, "'jhierro at tid.es'"<mailto:%27jhierro at tid.es%27> <jhierro at tid.es><mailto:jhierro at tid.es> Cc: "'fiware-wpl at lists.fi-ware.eu'"<mailto:%27fiware-wpl at lists.fi-ware.eu%27> <fiware-wpl at lists.fi-ware.eu><mailto:fiware-wpl at lists.fi-ware.eu>, "'fiware-wpa at lists.fi-ware.eu'"<mailto:%27fiware-wpa at lists.fi-ware.eu%27> <fiware-wpa at lists.fi-ware.eu><mailto:fiware-wpa at lists.fi-ware.eu> Date: 29/09/2011 01:02 PM Subject: Re: [Fiware-wpl] IMPORTANT Clarification ________________________________ About maintaining sprints. Recall that the reason for this solution was exactly the possibility to maintain sprints associated via associating tasks (per sprint/user story) with a tracker (generic enabler/epic/feature/release) Best, Thomas -- Please excuse smartphone brevity From: Bohnert, Thomas Michael Sent: Thursday, September 29, 2011 11:57 AM To: 'GLIKSON at il.ibm.com<mailto:GLIKSON at il.ibm.com>' <GLIKSON at il.ibm.com><mailto:GLIKSON at il.ibm.com>; 'jhierro at tid.es<mailto:jhierro at tid.es>' <jhierro at tid.es><mailto:jhierro at tid.es> Cc: '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> Subject: Re: [Fiware-wpl] IMPORTANT Clarification Alex, Yes - we promised to provide 'some level' of transparency in order to apease usage areas a bit at the first place, and secondly to maintain a means to keep the expectations on fi-ware reasonable. One can hardly argue for additional requests if the current workload is close to upper limits. Best, Thomas -- Please excuse smartphone brevity From: Alex Glikson [mailto:GLIKSON at il.ibm.com] Sent: Thursday, September 29, 2011 11:41 AM To: Juanjo Hierro <jhierro at tid.es><mailto:jhierro at tid.es> Cc: 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> Subject: Re: [Fiware-wpl] IMPORTANT Clarification Option 2 sounds reasonable. This way we also don't need to represent individual sprints in that tracker - just releases (minor and major), and mapping of features to releases. Regards, Alex P.S. BTW, do we need to keep the internal management of individual sprints and stories public? 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> Date: 28/09/2011 04:03 PM Subject: [Fiware-wpl] IMPORTANT Clarification Sent by: fiware-wpl-bounces at lists.fi-ware.eu<mailto:fiware-wpl-bounces at lists.fi-ware.eu> ________________________________ Hi, I believe there is a point that we didn't clearly fixed during our meeting in Turin. It is about the relationship between trackers and Backlogs. The notion of Backlog is someway "abstract" from my point of view. A backlog is just a set of related Themes/EPICs/Features/User-Stories. This means that we may well talk about the "Data/Context Management Chapter Backlog" as well as the "Publish/Subscribe Broker GE Backlog", being the second a subset of the first one. However, this doesn't mean that we have to use a separate tracker per each of the GE backlogs. I would like to agree on a common, consistent approach to share across the different chapters. I see several options: 1. Have a single Chapter tracker where keep track of the whole set of Themes/EPICs/Features/User-Stories associated to all GEs in the Chapter. By defining advanced queries on fields related to name of the GE, as well as the kind of entry, users may get different views, depending on their needs. 2. Have a single Chapter tracker where keep track of the whole set of Themes/EPICs/Features associated to all GEs in the Chapter. Then have a tracker per GEs dealing with User Stories for each and every GE in the chapter 3. Have multiple trackers, one per GE in the Chapter, each keeping track of the whole set of Themes/EPICs/Features/User-Stories associated to a given GE In my honest opinion, I would go for option 2. because it would make it easier to keep a reasonable large (but not that big) backlog just for Themes/EPICs/Features while the more fine-grained work is handled separately (given partners responsible of a given GE enough independence in managing the Backlog for the GE they are implementing). It may also make our life easier in front of reviewers and even UC projects who probably may just need to deal with entries at the level of granularity of EPICs/Features ... Any opinion ? If I don't hear about any objection, I would go for option 2 :-) 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_______________________________________________ Fiware-wpl mailing list Fiware-wpl at lists.fi-ware.eu<mailto:Fiware-wpl at lists.fi-ware.eu> http://lists.fi-ware.eu/listinfo/fiware-wpl ________________________________ 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/20111003/0c625b88/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy