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