| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.4/uma.ecore" |
| xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" |
| name="core_principle_evolve,_GXiogMvoEdqukPpotm3DYg" guid="-aMD1wQVJLzzlMARfHBdOBQ" |
| changeDate="2008-03-10T19:20:37.312-0400" changeDescription="removed OpenUP from page name." |
| version="0.02"> |
| <mainDescription><h3>
 |
| Introduction
 |
| </h3>
 |
| <p>
 |
| It is usually not possible to know all stakeholders' needs, be aware of all project risks, comprehend all project
 |
| technologies, or know how to work with your colleagues. Even if it were possible to know all of these things, they are
 |
| likely to change over the life of the project. Promote practices that allow the team to demonstrate incremental value,
 |
| and to get early and continuous feedback from stakeholders.
 |
| </p>
 |
| <p>
 |
| The intention behind this principle is to continuously get feedback, and to improve both the product and the process of
 |
| the project team. When you provide structure and create a mindset for continuous feedback and improvement, changes are
 |
| accommodated more easily. In addition, feedback is captured early and often, and high-priority risks are confronted
 |
| early in the project. By constantly identifying and attacking risks, there is more confidence in project progress and
 |
| quality.
 |
| </p>
 |
| <p>
 |
| Not only does the product evolve, but the team also finds better ways to work together and get involved with
 |
| stakeholders. The process followed by the team can be adjusted accordingly to leverage lessons learned and adjust
 |
| project pace and needs.
 |
| </p>
 |
| <h3>
 |
| Practices
 |
| </h3>
 |
| <h4>
 |
| Develop your project in iterations
 |
| </h4>
 |
| <p>
 |
| Developing a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new
 |
| knowledge. Worse, it can delay the discovery and mitigation of risks, because development efforts are scheduled later
 |
| in the lifecycle.
 |
| </p>
 |
| <p>
 |
| Divide your project into a series of time-boxed <a class="elementLinkWithUserText"
 |
| href="./../../../core.mgmt.common.base/guidances/concepts/iteration_C20B1904.html"
 |
| guid="_lam4ADkBEduxovfWMDsntw">iterations</a>, and plan your project iteratively. This iterative strategy enables you
 |
| to incrementally deliver capabilities (such as an executable, usable subset of implemented and tested requirements)
 |
| that can be assessed by stakeholders at the end of each iteration. This provides rapid and timely feedback loops, so
 |
| that issues can be addressed and improvements made at a lower cost. Also, this is accomplished while you still have
 |
| sufficient budget and time left to do so, and you have not gone so far ahead that major rework is required.
 |
| </p>
 |
| <p>
 |
| Iterative development enables teams to continuously improve software throughout the development <a
 |
| class="elementLinkwithusertext" href="./../../../process.openup.base/deliveryprocesses/openup_lifecycle_EE511F3A.html"
 |
| guid="_SuWj4dOPEdyqlogshP8l4g">lifecycle</a>.
 |
| </p>
 |
| <h4>
 |
| Focus iterations on meeting the next management milestone
 |
| </h4>
 |
| <p>
 |
| A project can appear to make progress while risks and unresolved issues pile up. Focus on bringing closure to important
 |
| project issues (such as stakeholder concurrence regarding scope, and proving the proposed architecture).
 |
| </p>
 |
| <p>
 |
| Divide the project into phases (such as <a class="elementLinkWithUserText"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/inception_phase_C4456871.html"
 |
| guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>, <a class="elementLinkWithUserText"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/elaboration_phase_BE880435.html"
 |
| guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>, <a class="elementLinkWithUserText"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/construction_phase_873B6559.html"
 |
| guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a> and <a class="elementLinkWithUserText"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/transition_phase_DD5986E5.html"
 |
| guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>), with each phase having a clearly visible management <a
 |
| class="elementLinkWithUserText"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/phase_milestones_5678231E.html"
 |
| guid="_HNxbwMBJEdqSgKaj2SZBmg">milestone</a>. The focus of each iteration within a phase is on achieving that
 |
| milestone.
 |
| </p>
 |
| <h4>
 |
| Manage risks
 |
| </h4>
 |
| <p>
 |
| Deferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such
 |
| procrastination may lead to investing in the wrong technologies, a bad design, or a set of requirements that may not
 |
| address stakeholder needs.
 |
| </p>
 |
| <p>
 |
| Attack <a href="./../../../core.mgmt.common.base/guidances/concepts/risk_AF5840DA.html"
 |
| guid="_0bsLgMlgEdmt3adZL5Dmdw">risks</a> early, or they will attack you. Continuously identify and prioritize risks,
 |
| and then devise strategies to mitigate them. Determine the focus of iterations based on risks. For example,
 |
| architecturally significant risks should be addressed early in the project, no later than the end of the Elaboration
 |
| phase, when the architecture has been proven and baselined.
 |
| </p>
 |
| <p>
 |
| Fore more information, see <a class="elementLinkWithType"
 |
| href="./../../../core.mgmt.common.base/guidances/guidelines/managing_risks_B1256EB4.html"
 |
| guid="_VNxL4ACsEdu8m4dIntu6jA">Guideline: Managing Risks</a>.
 |
| </p>
 |
| <h4>
 |
| Embrace and manage change
 |
| </h4>
 |
| <p>
 |
| Change is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will
 |
| result in a bloated, deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a
 |
| change is made, the more the change is likely to cost.
 |
| </p>
 |
| <p>
 |
| Embrace and manage change. Embracing change helps you to build a system that addresses stakeholder needs, and managing
 |
| change allows you to reduce costs and improve predictability of those changes. Changes made early in the project can
 |
| usually be made with limited cost. As you progress in your project, changes can become increasingly costly.
 |
| </p>
 |
| <p>
 |
| To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware
 |
| of the impact that those changes have on the project cost and schedule. Understand the impact of a change in the
 |
| current phase, and isolate team members from disruptive changes during the current iteration. Change requests are
 |
| reviewed and prioritized during the current iteration, but are not acted upon until assigned to a future iteration.
 |
| </p>
 |
| <p>
 |
| If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
 |
| </p>
 |
| <h4>
 |
| Measure progress objectively
 |
| </h4>
 |
| <p>
 |
| If you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding.
 |
| Uncertainty and change make a software project’s progress difficult to measure objectively, and people are prone to
 |
| making objective assessments from subjective information.
 |
| </p>
 |
| <p>
 |
| Get a clear picture of project status by objectively measuring progress. The best measure of progress is the delivery
 |
| of working software, which is something that you do by taking an evolutionary approach. You can also define a set of
 |
| objective <a href="./../../../core.mgmt.common.base/guidances/concepts/metrics_37698708.html"
 |
| guid="_0mYYkMlgEdmt3adZL5Dmdw">metrics</a> to collect during an iteration (for example, requirements that were
 |
| implemented and validated, number of defects issued compared with number fixed) and review them as part of the <a
 |
| href="./../../../practice.mgmt.iterative_dev.base/tasks/assess_results_EC34D88D.html"
 |
| guid="_0l53cMlgEdmt3adZL5Dmdw">iteration assessment</a>.
 |
| </p>
 |
| <h4>
 |
| Continuously re-evaluate what you do
 |
| </h4>
 |
| <p>
 |
| On a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team to track
 |
| status and identify risks and issues. This can be done daily when the team gathers to share the status of individual
 |
| responsibilities and identify and address issues. At the end of iterations, <a
 |
| href="./../../../practice.mgmt.iterative_dev.base/tasks/assess_results_EC34D88D.html"
 |
| guid="_0l53cMlgEdmt3adZL5Dmdw">assess the status</a> of what has been done and look for areas of improvement that can
 |
| be addressed in the next iteration. Have a retrospective review at the end of the project and capture lessons learned
 |
| to run future projects in a more efficient way.
 |
| </p>
 |
| <p>
 |
| If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads
 |
| to improved project results.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |