| <?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.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" |
| name="core_principle_evolve,_GXiogMvoEdqukPpotm3DYg" guid="-aMD1wQVJLzzlMARfHBdOBQ" |
| changeDate="2007-05-22T10:09:54.111-0700" 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="./../../../openup/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 href="./../../../openup/deliveryprocesses/openup_lifecycle_2CB8A7DA.html" guid="_0uyGoMlgEdmt3adZL5Dmdw">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="./../../../openup/guidances/concepts/inception_phase_C4456871.html" guid="_0hmKgBOMEduCNqgZdt_OaA">Inception</a>, <a class="elementLinkWithUserText" href="./../../../openup/guidances/concepts/elaboration_phase_BE880435.html" guid="_2plxwBOMEduCNqgZdt_OaA">Elaboration</a>, <a class="elementLinkWithUserText" href="./../../../openup/guidances/concepts/construction_phase_873B6559.html" guid="_48EKsBOMEduCNqgZdt_OaA">Construction</a> and <a class="elementLinkWithUserText" href="./../../../openup/guidances/concepts/transition_phase_DD5986E5.html" guid="__ca5UBOMEduCNqgZdt_OaA">Transition</a>),
 |
| with each phase having a clearly visible management <a class="elementLinkWithUserText" href="./../../../openup/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="./../../../openup/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="./../../../openup/guidances/guidelines/risk_management_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="./../../../openup/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="./../../../openup/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="./../../../openup/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> |
