Bugzilla – Full Text Bug Listing
| Summary: | Scrum Practices | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Ana Pereira <apereira> |
| Component: | EPF | Assignee: | Bruce MacIsaac <brucesclan> |
| Status: | REOPENED --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | balduino, brucesclan, colin.ocsolutions, ken.clyne |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Ana Pereira
*** Bug 267073 has been marked as a duplicate of this bug. *** *** Bug 255828 has been marked as a duplicate of this bug. *** Created attachment 187107 [details]
export of the proposed plug-ins
the practices in the attachment include: timeboxed sprints .. includes sprint planning and sprint review tasks, sprint backlog and sprint burndown and all roles value driven development - includes product backlog, estimation, prioritization, release planing and backlog grooming and product owner empirical process control - includes daily meetings and retrospectives, the team and scrum master roles, work products and are in different core plug-ins role assignements to tasks is made in assignement pug-ins that extend the base practice plug-ins Created attachment 187108 [details]
list of work to do in the practice library
Created attachment 193643 [details]
zip of the OpenUP library copy from ONeill (6MB)
Created attachment 193644 [details]
zip of the HTML export from ONeill (5MB)
Created attachment 193645 [details]
Development Case from ONeill
Attached is my attempt to document two practices currently not in the Scrum library: 1) Production Release, and 2) Documentation & Training. This new, original content is for review by Eclipse legal, as well anyone on the EPF content team. I've attached the following files: - zip of the OpenUP library copy I worked on over the past two months - zip of the HTML export from the OpenUP library - the Development Case I used to construct the aforementioned plug-ins Thanks, Colin The following are my detailed comments on Colin's OpenUP/Scrum library: Roles 1. Product owner doesn't do anything in spring 0. I was surprised by that. 2. Scrum team role is doing both collaborative tasks that involve everyone on the team, such as "daily scrum" and tasks that are assigned to individuals that take on specific responsibilities and need specific skills, such as "package the release". In our IBM practices that cover this space, we have Deployment manager deal with deployment plans, and a configuration manager deal with packaging the release. and a system administrator does installs. I suggest we introduce similar roles, and reserve "scrum team" for activities which involve the whole team. It's too bad that teams aren't compositional so that we can identify what roles are on the team. I'm facing a similar issue at IBM where I'm thinking of defining team composition using custom categories, but then I can't assign tasks to the team. However, I'm ok with that, because I assign the task to the role responsible for calling the meeting, and then in the description it says who to involve. I have a slight preference for replacing the team role with a custom category so that there is no ambiguity of what roles are considered part of the team, and what roles are considered external to the team, but that the team interacts with. I'm also not in love with calling the team a scrum team, because that suggests that if you follow a different process you're a different team. I think "development team" would be more general purpose. 3. Documentation specialist We have a similar role in our IBM content called Technical writer. How would you feel about renaming this to Technical writer? 4. Project manager is still publishing, although it only performs a supporting role. Would it make more sense to have a publish plug-in for scrum that replaces the project manager with scrum master? 5. Release team Description implies there are really 2 roles, a release manager and a release engineer. In our IBM content we have deployment manager, but no role to fill release engineer responsibilities. The tasks defined by this team might, however, be assigned to the whole team, with individual work items being decompositions of these. I would be inclined to add a task "coordinate release" assigned to the release manager or deployment manager, and have the other tasks assigned to release engineer or deployment engineer. 6. Stakeholder is still publishing with a lot of additional performing responsibilities. 7. Training specialist In our IBM content we have course developer and trainer as separate roles. How do you feel about aligning with IBM on these roles? 8. When I publish the configuration and don't limit it to the delivery process, a bunch more roles show up. These are coming from the agile_business_rules practice, which is not part of OpenUP. I suggest removing this from the configuration. Practices 1. The practices need to be added to the structured list of practices in the view. 2. Empirical process control - there is a note in the main description that this is still incomplete. Also we need to be careful not to copy others material without proper reference under fair usage rules. 3. Documentation and training - looks good. We have a similar practice in our IBM commercial library - we could align these, or allow them to co-exist as alternatives. I will need to review this further. 4. Production release - looks good. We have a similar practice, deployment management. Same issues as previous note. 5. Scrum practice publishes, but has nothing but a description. Should it be removed, having been replaced by Empirical Process Control? Publish.openup_scrum 1. This configuration needs its own Welcome page, it's not classic OpenUP. Created attachment 205285 [details]
Zip of EPF Practices library export w/ ScaledAgile contributions
Response to comments from Bruce MacIsaac dated 2011-05-11
Roles
1. The Sprint 0 workflow was mistakenly included in the draft library that was provided in May 2011. For the two practice plug-ins that are being contributed ("Production Release" and "Documentation & Training"), the Product Owner role is tangentially involved in both practices and is included in the "Production Release" practice for convenience. In the future, this role can be moved to another plug-in and assigned tasks as needed.
2. Renamed "Scrum Team" to "Development Team" and used Content Variability to contribute to the OpenUP role "Developer" in package core.default.role_def.base.basic_roles.
Because the Release discipline is not well defined in the IT industry, there are no clear roles defined for the planning, packaging, and installation of releases. Also, the overloaded role names of "Configuration Manager" and "System Administrator" are defined inconsistently across most organizations. Therefore, I have elected to keep the roles associated with the Release discipline more generic at this time by using "Deployment Manager" and "Deployment Engineer."
3. Changed "Documentation Specialist" role name to "Technical Writer" to align with RUP.
4. The Project Manager role has been removed from references to the Production Release and Documentation & Training practice plug-ins.
5. Renamed "Release Manager" to "Deployment Manager" to align with RUP. Renamed "Release Team" to "Deployment Engineer" for consistency.
6. References to the Stakeholder role have been removed from the Production Release and Documentation & Training practice plug-ins.
7. Split "Training Specialist" into two roles "Trainer" and "Course Developer" to align with RUP.
8. Removed the "Agile Business Rule Development" practice from publishing in the OpenUP configuration.
Practices
1. Created "Production Release" and "Documentation and Training" practice packages in the practice.tech path of the EPF Practices Library. Included both practices in the "OpenUP" and "All EPF Practices" configurations.
2. I'm not sure what this note is referring to. I couldn't find any reference to "Empirical process control" in the two new practices.
3. Recognizing that there is a similar practice in RUP, I wanted to provide an alternative open source version for use in OpenUP.
4. Same as #3 above.
5. It appears that the Scrum practice is no longer included in the most recent version of the EPF Practices library (v1.5.1.2).
Publish.openup_scrum
1. This configuration has been removed from the most recent version of the EPF Practices library (v1.5.1.2).
Additional Notes and General Comments
1. Added release information in both practices using the Supporting Material element and listed them in the Release Info custom categories for the OpenUP and All EPF Practices configuration views.
2. Created Standard Categories (Disciplines, Domains, and Role Sets) for both practice plug-ins.
3. For consistency, created four capability patterns (two for each new practice) as part of process.openup.base.processes.capability_patterns.technical (I'm not quite sure how the technical capability patterns are used in the OpenUP configuration).
4. Added four activities to the "openup_lifecycle" delivery process in process.openup.base under Transition Phase > Transition Iteration. These activities have the same structure and content as the new capability patterns. The activities are named "Prepare Product Documentation," "Provide Product Training," "Prepare for Release," and "Deploy Release to Production" and were inserted between the activities "Test Solution" and "Ongoing Tasks."
5. Added four new disciplines (two in each practice) and listed them in the Tasks custom category at core.default.nav_view.base.navigation_view_generic
6. Updated EPF Copyright element (core.default.release_copyright.base) with Scaled Agile copyright.
7. In addition to an export zip file, I have attached a zip of the entire library because these two practices have been completely integrated into the OpenUP & All EPF Practices views and configurations and I'm not sure that a simple export will contain all those dependencies.
Created attachment 205286 [details]
Zip of complete EPF Practices library w/ ScaledAgile contributions
Sorry for taking so long to review this. With a bit of minor cleanup, I think these will make good additions to the library. Some specific actions that should be taken: 1. Roles should be moved to core.default.role_def.base 2. Since these are generic practices, and not scrum-specific, I think we need to make them independent of scrum. That means using "iteration" in place of or in addition to "sprint", and roles should be consistent with roles in core.default.role_def.base. I would propose using the existing "analyst" role in place of product owner. That isn't to say that we can't use this practice with scrum roles - that is fine, but to be consistent, any alternate role schema should either be provided through a set of new role definition and assign plug-ins for the library, or through selective replacement via scrum-specific plug-ins. 3. I don't quite get contributing development team information to the developer role. I have no problem creating a new role to represent the team, but I think there is a big difference between a task being assigned to one developer and a task being assigned to the team. The text being contributed is describing some of the principles of "whole team". If there are some new key points about team assignment and organization, perhaps enhancing this practice would fit better. 4. Scaled Agile Inc. is your company? Just want to be clear.... 5. I think the new tasks introduced by these practices should be incorporated into the OpenUP delivery process, otherwise they are rather invisible. 6. I would like to take some more time to compare these new practices with our commercial equivalents, and I may have some more comments after that review. The first 4 comments I think should be addressed before officially releasing these practices. The last 2 could be done before or after an initial release. I have taken Colin's latest version of these practices and added them to CVS. 1. Documentation and Training 2. Production Release. I have incorporated these practices into the OpenUP delivery process. I have also incorporated the practice Project Process Tailoring into the OpenUP delivery process. In doing this, I have made the following changes to OpenUP: 1. Revised the capability patterns and delivery process to include the practices. 2. Deleted redundant copy of activity "Identify and Refine Requirements" 3. Updated "planned flags" in OpenUP delivery process. 4. Structured the roles into sets, and changed the OpenUP view to display role sets. I also updated the All EPF Practices configuration to include these practices. I also made the following changes compared with Colin's submission: 1. Renamed elements to conform with authoring conventions. 2. I had outlining deployment plan in Elaboration, developing support materials in construction, and release in transition - rather than do all this in transition. 3. Redid the assign plug-ins (plug-in dependencies were mixed up). 4. Removed "development team member" I used developer (which Colin contributed to anyways). I deleted Colin's text. 5. Used Deployment standard categories in place of new disciplines. This was reviewed at the May 10 EPF meeting. There were no objections to these changes. Reopening, as the original intent of this bugzilla, to refactor the scrum practices, is not completed. Bug 379171 was created in order to record the completion of the practices for production-release and documentation-training. This bug should remain so that the original bug description can be addressed in a future release. I have created a first version of a Scrum plug-in that is compatible withe the EPF Practices library. I will be adding it into GIT shortly. Moving this to the backlog, as this work is not sufficiently mature to include in the EPF 1.5.1.6 release. |