| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="_a3uz4LBYEdm7Eph_l9Cn9w" name="assess_results,_0l53cMlgEdmt3adZL5Dmdw" guid="_a3uz4LBYEdm7Eph_l9Cn9w" changeDate="2006-09-22T12:12:39.478-0700" version="1.0.0"> |
| <sections xmi:id="_PABe4MQIEdmaiYJe8-Eaqg" name="Gather stakeholder feedback" guid="_PABe4MQIEdmaiYJe8-Eaqg"> |
| <sectionDescription><p> |
| The team should demonstrate the product to customer, end-users, and other <a class="elementLinkWithType" href="./../../openup_basic/roles/stakeholder,_dTa6gMAYEdqX-s4mWhkyqQ.html" guid="_dTa6gMAYEdqX-s4mWhkyqQ">Role: Stakeholder</a>s&nbsp;to collect their feedback, or better yet, have end users to use the product themselves. This |
| should be done throughout the iteration, or at least in a separate session towards the end of the iteration. Record |
| requested changes to the product in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/work_items_list,_rGNWsCbSEdqh1LYUOGRh2A.html" guid="_rGNWsCbSEdqh1LYUOGRh2A">Artifact: Work Items List</a>&nbsp;for later prioritization. Factor&nbsp;the feedback |
| into the&nbsp;overall iteration assessment. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_o28GgMMsEdmdo9HxCRR_Gw" name="Assess results" guid="_o28GgMMsEdmdo9HxCRR_Gw"> |
| <sectionDescription><p> |
| Towards the end of the iteration, the team should jointly assess whether the objectives and evaluation criteria |
| established in the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/iteration_plan,_0aQBEslgEdmt3adZL5Dmdw.html" guid="_0aQBEslgEdmt3adZL5Dmdw">Artifact: Iteration Plan</a>&nbsp;were met, and whether the team adhered to the |
| iteration plan and completed all the planned work items. Below&nbsp;are some sample questions that the team can ask |
| themselves as a part of the assessment: |
| </p> |
| <ul> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px"> |
| Were the defined goals and objectives met? Did the release meet its functionality and quality goals? Did the |
| release meet performance and capacity goals? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none"> |
| Were risks reduced or eliminated? Can we identify new risks? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none"> |
| Were all planned work items addressed? What was the teams velocity relative to plan? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none"> |
| Did the end users provide favorable feedback on what we built in this iteration? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px; LIST-STYLE-TYPE: none"> |
| Are changes to the project plan required? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px"> |
| What portion of the current release will be baselined? What portion will need to be reworked? |
| </div> |
| </li> |
| <li> |
| <div style="MARGIN-LEFT: 2em; MARGIN-RIGHT: 0px"> |
| Have there been external changes such as changes in the marketplace, in the user community, or in the |
| requirements? |
| </div> |
| </li> |
| </ul> |
| <p dir="ltr"> |
| The assessments should be based on objective measures to the greatest extent possible. For example, to assess that a |
| given requirement is developed, the team should ensure that the corresponding test cases were successfully run against |
| it, rather than considering it done when the implementation is done. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_iL7cQEpqEdup0IY9DKDPkg" name="Perform a retrospective" guid="_iL7cQEpqEdup0IY9DKDPkg"> |
| <sectionDescription><p> |
| Review the approach taken to development and team collaboration, the effectiveness of the development environment, the |
| suitability of the working environment, and other factors and discuss what things went well, what could have gone |
| better, and how things could be changed to deliver better results. Capture actions to be taken to improve the |
| development approach for next iteration in the <a class="elementLink" href="./../../openup_basic/workproducts/status_assessment,_0bA2EMlgEdmt3adZL5Dmdw.html" guid="_0bA2EMlgEdmt3adZL5Dmdw">Status Assessment</a>. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_YdoAAM1DEdmLoKw_mVTvhQ" name="Refine project scope and duration" guid="_YdoAAM1DEdmLoKw_mVTvhQ"> |
| <sectionDescription><p> |
| Depending on the results of the&nbsp;assessment and the stakeholders' feedback, the <a class="elementLinkWithType" href="./../../openup_basic/roles/project_manager,_0a0o0MlgEdmt3adZL5Dmdw.html" guid="_0a0o0MlgEdmt3adZL5Dmdw">Role: Project Manager</a>&nbsp;could need to revise the <a class="elementLinkWithType" href="./../../openup_basic/workproducts/project_plan,_0a6vcMlgEdmt3adZL5Dmdw.html" guid="_0a6vcMlgEdmt3adZL5Dmdw">Artifact: Project Plan</a>&nbsp;to adapt to those changes. If a change affects defined |
| project milestones, the project manager should consult with the stakeholders before committing to the changes. |
| </p> |
| <p> |
| Necessary changes can also encompass the need to acquire new resources, to absorb an unplanned effort increase, or to |
| implement a specific change request. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_wp2CIMMsEdmdo9HxCRR_Gw" name="Close-out phase" guid="_wp2CIMMsEdmdo9HxCRR_Gw"> |
| <sectionDescription><p> |
| This step is optional and must be performed only when the assessment period coincide with the end of a phase. |
| </p> |
| <p> |
| The end of&nbsp;a phase represents a point of synchronization of technical and management expectations and closure for |
| a project. In iterative development, it coincides&nbsp;with the end of an iteration. However, phase ends mark a point |
| when it is possible to consider re-scoping and even re-contracting a project. For example, the inception phase is |
| exploratory and may be appropriately performed under a time-and-materials contract or a cost-plus type of contract. The |
| elaboration phase could be done as a fixed-price contract or a cost-plus contract, depending on the extent to which the |
| development is unusual. By the construction and transition phases, enough is known about the system that fixed-price |
| contracts are more appealing to the acquirer and vendor. |
| </p> |
| <p> |
| The phase end is marked by a major milestone and a corresponding milestone review. The degree of formality of |
| these&nbsp;reviews depends on the project. The important thing is to take advantage&nbsp;of this milestone review to |
| achieve agreement among all stakeholders on the current state of the project. For more information, refer to <a class="elementLinkWithType" href="./../../openup_basic/guidances/concepts/milestones,_HNxbwMBJEdqSgKaj2SZBmg.html" guid="_HNxbwMBJEdqSgKaj2SZBmg">Concept: Milestones</a>. |
| </p></sectionDescription> |
| </sections> |
| <sections xmi:id="_1YHH8DLqEdueZPye-FaNgA" name="Close-out project" guid="_1YHH8DLqEdueZPye-FaNgA"> |
| <sectionDescription><p> |
| This step is optional and must be performed only when the assessment period coincide with the end of the project. |
| </p> |
| <p> |
| Involve the team and stakeholders in&nbsp;a final assessment for project acceptance which, if successful, marks the |
| point when the customer accepts ownership of the software product. Gather and record the lessons learned to be used in |
| future projects. Complete the close-out of the project by disposing of the remaining assets and reassigning the |
| remaining staff. |
| </p></sectionDescription> |
| </sections> |
| <purpose>Capture and communicate whether the project is on track, requires corrective actions, and whether there are opportunities |
| for improvement.<br /></purpose> |
| </org.eclipse.epf.uma:TaskDescription> |
