Team, Following Juanjo's comments below, I would like to ask you to upload to the Wiki the description of features for the first minor release as well as user stories for the first sprint (which has actually started). If you have concerns regarding confidential information in description of user-stories or features, you can use the wiki space under Cloud Hosting project in Forge, and add a link there (instead of keeping everything in the public wiki). We may also have work items not directly related to product features/user stories -- we will describe them separately (no need to have a Wiki page for them -- just a reasonable description in the tracker). As some of you might have noticed, there are some technical issues with the Tracker, so we can't finish reflecting the epics/features/stories/work items in the tracker yet (I will send a separate email on this later today). So, for now, let's make sure our Wiki is fully compliant with the project management requirements. The deadline is November 10th. We will review the plan for 1st minor release & sprint at our tomorrow's weekly call (11am CET). Please, send me your list of features and user stories/work items (essentially, things that you plan to do/accomplish in the upcoming 1 and 3 months) by the end of the day today. If you still don't have everything specified in the Wiki -- a bullet list (with some details) would be sufficient. Thanks, Alex ----- Forwarded by Alex Glikson/Haifa/IBM on 07/11/2011 04:04 PM ----- From: Juanjo Hierro <jhierro at tid.es> To: Alex Glikson/Haifa/IBM at IBMIL Cc: "fiware-cloud at lists.fi-ware.eu" <fiware-cloud at lists.fi-ware.eu>, MIGUEL CARRILLO PACHECO <mcp at tid.es>, "jhierro >> \"Juan J. Hierro\"" <jhierro at tid.es> Date: 02/11/2011 09:10 AM Subject: Re: Planning of the 1st major release On 28/10/11 14:20, Alex Glikson wrote: > Team, > > While outlining our features and user stories for the first minor > release/sprint, it is important to make sure that we are in sync in the > broader perspective of the first major release (M12) -- which is our next > official deliverable. Hence, I would like to outline the main objectives > that we should aim at, the way I see it (Juanjo -- would appreciate your > input). This will help us deciding on the exact scope of each of the two > releases (Nov-Jan, Feb-Apr). > > Our main objectives for M12 include: > detailed architecture, GEs specification > design, integration of baseline assets to create functional end-to-end > stack, detailed gap analysis > implementation of few selected enhancements (preferably including those > which can be demonstrated end-to-end) > user guide, admin guide, programming guide > detailed requirements specification for 2nd major release -- > incorporating feedback from UC projects (M24) > design of new functions to be developed targeting 2nd major release > (M24) According to the DoW, the architecture should be available by end of month 9, i.e., end of January 2012. We have to determine what format we will follow for this deliverable as to avoid too much paperwork. A different story are GEs specifications which actually have to be available by end of month 12, i.e., end of April 2012, the same way the rest of the items you have mentioned. With this minor amendment, I agree that the main objectives by end of month 12 (first major release) are the ones you described. Focus of the first major release actually should be on delivering a full IaaS Cloud Service that works end-to-end, including a self-service portal for IaaS. PaaS support may deferred to the second major release (planned to be delivered by end of month 24). It would be nice that some of the features/epics requested by any of the UC projects be covered in this first major release as long as they are related to IaaS. > Please, take the above objectives into consideration when planning the > first minor release. Of course, feel free to comment on the list above > and/or suggest improvements. > > For Resource Management GE, I envision the following features > (draft/partial list): > Setup of internal testbed > Basic environment up and running -- including partial set of baseline > assets (OpenStack, Glance, maybe others) > Education and gap analysis > Selection of enhancements to be implemented for the first major release > Implement few of the selected enhancements targeting the first major > release (TBD) > Design of individual capabilities, focusing on enhancements and new > functions tentatively targeted for the second major release (M24) > resource pooling, QoS, capacity mgmt, monitoring, network, storage, > image library, placement, federation, security, APIs, fabric, > management of physical machines, security > Design of integration with Service Manager > "Digest" requirements of the UC Projects related to Resource Management > GE > > This way the last 3 months can be dedicated to implementation of the > enhancements/new functions, further integration (including cross-GE), > documentation of M12 deliverables (especially A and D above), etc. I'm not sure I do understand this description of features ... Features should have a clear link to some functionality to be developed in the product (the Resource Management GE in this case). They shouldn't map into steps of a process, like if we were following a waterfall process ... I haven't reviewed each and every Epic linked to the Resource Management GE, but they should map into functionality of the product, not process steps. Then, as I explained in a recent email sent to WPLs/WPAs, Features can be obtained by just selecting those Epics that we believe can be addressed in the first minor release. User Stories should also map to functionality to be developed in the product. Since we may be developing a feature during a 3 months-period, we will have to refine the feature into user stories, each covering the development of some part of the functionality described in the feature. This means, that for the first sprint, we should take the features we have identified for the first minor release and derive a number of user-stories for each of them, then decide which ones will be addressed in the first sprint. Some of the activities you describe map to work to be done by the development team during sprints, but not necessarily linked to a concrete functionality of the product. Question mark here is whether we should produce an entry in the backlog for these activities. Some Agile experts suggest that Backlogs should not only comprise entries linked to functionality to be covered but also any sort of work item to be performed by the development teams. We need to discuss at WPLs/WPAs level whether we want to have this sort of entries in our backlogs or not. On one hand, it's nice because it helps to monitor the work each team is doing and will help to show it to the external world (e.g., reviewers of the project). It will be also helpful during those periods of times where we don't plan to have so much development work, mostly designing and setting up the integration of components within GEs or between GEs. On the other hand, it may lead to a explosion of entries in the backlog. For the time being, please don't create items of this nature in the backlog. Let's try to address this in our next joint WPL/WPA confcall. I'll raise this as a topic for discussion in the WPL/WPA mailing list. > > Please, note that although the final integration between GEs is planned for > months 13-15, we should explore the integration as soon as possible > (especially between Service Manager and Resource Manager) -- because I > expect this to be the most significant risk in delivering and end-to-end > functional stack by M15, and the way to mitigate it (and avoid surprised > too late in the cycle) is to start the integration sooner rather than later > -- desirably even during the first minor release. Fully agree on this. Hope my comments help. Best regards, -- Juanjo > > Would appreciate your input. > > Regards, > Alex > > > > From: Alex Glikson/Haifa/IBM at IBMIL > To: fiware-cloud at lists.fi-ware.eu > Date: 27/10/2011 12:21 AM > Subject: Re: [Fiware-cloud] WP status > Sent by: fiware-cloud-bounces at lists.fi-ware.eu > > > > My comments below > > One more important thing: it is very important to outline in the > description of each Epic the scope of work to be done -- which also implies > that we need to mention the baseline assets that will be used. It is > important that whoever reads an Epic, understands what we are trying to, > why, what already exists as part of the baseline assets, and what is the > 'delta', or work to be done, associated with this particular work item -- > integration, enhancements, new pieces, etc. > > Regards, > Alex > > P.S. I've completed the description of most of the RM epics > > > > From: Alex Glikson/Haifa/IBM at IBMIL > To: fiware-cloud at lists.fi-ware.eu > Date: 26/10/2011 08:14 AM > Subject: Re: [Fiware-cloud] WP status > Sent by: fiware-cloud-bounces at lists.fi-ware.eu > > > > Andy, Fernando -- thanks for the initiative! This is very helpful. I will > send more detailed comments later. One important comment, meanwhile: > > Regarding user stories and sprints -- I'm not sure we should manage user > stories in the same public tracker. That's why the "User Story" category > and the "Sprint" field are not there. > Moreover, strictly speaking, those are not supposed to be part of the > Backlog -- which is by definition a set of work items which have not been > scheduled to any sprint. > > So, besides completing and reviewing Themes and Epics in the backlog, and > completing the description of baseline assets we want to use, what I would > like to ask from all of you is to send me (or to the list) a much more > detailed description, in whatever format is convenient for you (sets of > bullets are fine for now -- we can then attach them to the wiki entry) of > the following: > 1) Features that you would like to include in the first minor release -- > outlining specific scope of work that you expect to be completed by > January, 31th, 2012, and > 2) User Stories that you would like to include in the first sprint -- i.e., > specific work items that will be done by November 30th. > > For both, I would like to see a very clear 'acceptance criteria' -- how > exactly will we measure and validate whether the corresponding work items > are done, and what can others expect as an outcome of this work. > > Thanks, > Alex > > > > > From: FERNANDO LOPEZ AGUILAR<fla at tid.es> > To: "Edmonds, AndrewX"<andrewx.edmonds at intel.com> > Cc: Alex Glikson/Haifa/IBM at IBMIL > Date: 25/10/2011 07:20 PM > Subject: Re: WP status > > > > Thank you Andy, > > I write them inline. > > > Tracker > * Only 2 from Alex and the rest are from Fernando (currently only EPICs and > Features -- this is OK, as explained above) > * FI-WARE Backlog Entry Type without User-Story option. > * We have release box but we have to change it to FI-WARE Release Id box > and FI-WARE Sprint Id box. > * We need to specify there for each EPIC, Feature and User Story in which > Release and Sprint we plan to develop it. Not really. Only for the first > one. The priorities might change over time, so we shouldn't try deciding up > front for longer than one minor release. > * We have to select which Feature and User Stories we want to implement in > the first minor release. > > Wiki Asset Descriptions > ? None from Cloud Proxy > ? None from Self-service Interfaces > ? Listed but not detailed from Monitoring > ? None that covers T4.2 -- Updated > * We have to differentiate between basseline asserts and needed assests. > The real asset is explained in more detail (e.g. Claudia in IaaS SM) and > the others are explained with less details (see MySQL). But the sections > that we use would be the same that all the assets have to use. > > We should describe here *only* the baseline assets. If they have > pre-requisites -- it is described in their documentation. and we may > mention that within the description of the asset. But we should not mention > them in the main list. > > Wiki Epics > * Here I want to give you some clarification about the different between > EPICs, Features and User Stories. > * EPICs is anything that we planned to develop (or have any idea about the > expended time to develop it) in a period of time bigger than a minor > release (3 months). > * Feature is anything that we planned to develop (or have any idea about > the expended time to develop it) in a period of time less than a minor > release (3 months). > * User Story is anything that we planned to develop (or have any idea about > the expended time to develop it) in a period of time equal to a sprint (1 > months). [or less] > * We have provided neither Features or User Stories except for IaaS SM and > PaaS Mgmt. Yep. As I mentioned above, we must update both the Wiki and the > Tracker with features for the first release, and also outline the stories > for the first sprint. > * Anyway, I could see some Epics like > FIWARE.Epic.Cloud.ResourceManager.Security.APIs > which is not a EPIC (IMHO), The Epic would be > FIWARE.Epic.Cloud.ResourceManager.Security. This should be a User Story. > Well, it is a matter of scope and sizing. If we figure out that the entire > Epic can be covered in a single sprint (which I don't believe is the case) > -- we can definitely 'downgrade' it to a story. > > IaaS Data Center Resource Management: 9/20 not complete > ? FIWARE.Epic.Cloud.ResourceManager.MgmtFabric -- done > ? FIWARE.Epic.Cloud.ResourceManager.QoS -- done > ? FIWARE.Epic.Cloud.ResourceManager.Mobility -- done > ? FIWARE.Epic.Cloud.ResourceManager.Placement -- done > ? FIWARE.Epic.Cloud.ResourceManager.PhysPlatformMgmt > ? FIWARE.Epic.Cloud.ResourceManager.Capacity -- done > ? FIWARE.Epic.Cloud.ResourceManager.Toolkit > ? FIWARE.Epic.Cloud.ResourceManager.Federation > ? FIWARE.Epic.Cloud.ResourceManager.Security.APIs > * IMHO, OCCI is not a basseline asset, it is a specific interface within > the rest of baseline assets (Openstack Nova, Glance, ...). > * Each Basseline assets have to describe the following subsections > Brief Description > Programming artifacts > Technologies used > Runtime pre-requisites (including Known software requirements) > IPR > Publicly available documentation > > except the needed assests like MySQL in IaaS SM that only need to describe > Brief Description > IPR > Publicly available documentation > * There are no Features and User Stories > > Object Storage > * Openstack switch, need to describe Technologies used and Runtime > pre-requisites subsections. > * No Features > * No User Stories (remenber that *.Security.SSO and *.Security.RBAC should > be a User Stories). > > Security 1/2 not complete > ? FIWARE.Epic.Cloud.Security.RBAC > * Openstack keynote, need to describe Technologies used and Runtime > pre-requisites subsections. > * Check if the Epics are Features. > > Self-Service Interfaces: 4/5 not complete > * No Baseline assets described > ? FIWARE.Epic.Cloud.SelfServiceInterfaces.UserCLI > ? FIWARE.Epic.Cloud.SelfServiceInterfaces.AdminCLI > ? FIWARE.Epic.Cloud.SelfServiceInterfaces.AdminPortal > ? FIWARE.Epic.Cloud.SelfServiceInterfaces.Security > * No Features, no User Stories > > Cloud Proxy: 5/8 not complete > * No baseline asset described > ? FIWARE.Epic.Cloud.CloudProxy.VirtualizationLayer > ? FIWARE.Epic.Cloud.CloudProxy.ManagementAPI > ? FIWARE.Epic.Cloud.CloudProxy.CloudAppProvisioning > ? FIWARE.Epic.Cloud.CloudProxy.ManagementProxy > ? FIWARE.Epic.Cloud.CloudProxy.Security > * Only Epics > > Monitoring: 5/11 not complete > * Some baseline assets without description (working in progress between > Fernando and Andy) > ? FIWARE.Epic.Cloud.Monitoring.Analysis.SLAIntegration > ? FIWARE.Epic.Cloud.Monitoring.Visualization > ? FIWARE.Epic.Cloud.Monitoring.Management > ? FIWARE.Epic.Cloud.Monitoring.Security.Metrics > ? FIWARE.Epic.Cloud.Monitoring.ServiceMgrIntegration > * Only Epics. > > Themes: 1/3 not complete > ? Accounting > > @Andy TODO: > ? Supply monitoring asset details > ? FIWARE.Epic.Cloud.Security.RBAC > ? FIWARE.Epic.Cloud.Security.APIs > ? FIWARE.Epic.Cloud.Monitoring.Visualization > ? FIWARE.Epic.Cloud.Monitoring.Management > ? FIWARE.Epic.Cloud.Monitoring.Security.Metrics > > @Alex TODO: > * Refine the tracker page. > > @All > * Refine the Epics, Features and User Stories > * Provide baseline assets with their appropriate description information > * Provide information in the tracker system (be careful, in the FIWARE > Cloud track section, not in the FIWARE track section) > * Provide the list of Features and User Stories to be implemented in the > first minor release and put this information into the tracker system. > > > I think that this information could be send to the rest of cloud members. I > hope that I could take some light into the dark. > > Best regards, > > Fernando López Aguilar > Cloud Computing > fla at tid dot es > +34 914 832 729 > Telefónica I+D (R&D) > Ronda de la Comunicación s/n > Distrito C, Edificio Oeste 1, Planta 5 > 28050 Madrid, Spain > > > > El 25/10/2011, a las 18:02, Edmonds, AndrewX escribió: > > > ------------------------------------------------------------- > Intel Ireland Limited (Branch) > Collinstown Industrial Park, Leixlip, County Kildare, Ireland > Registered Number: E902934 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > 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-cloud mailing list > Fiware-cloud at lists.fi-ware.eu > http://lists.fi-ware.eu/listinfo/fiware-cloud > _______________________________________________ > Fiware-cloud mailing list > Fiware-cloud at lists.fi-ware.eu > http://lists.fi-ware.eu/listinfo/fiware-cloud 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-cloud/attachments/20111107/12828b81/attachment.html>
You can get more information about our cookies and privacy policies clicking on the following links: Privacy policy Cookies policy