OpenUP/OpenUP_SP/library/openup_basic/guidances/concepts/core_principle_evolve.xmi

<?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.3/uma.ecore" epf:version="1.0.0" xmi:id="-aMD1wQVJLzzlMARfHBdOBQ" name="core_principle_evolve,_GXiogMvoEdqukPpotm3DYg" guid="-aMD1wQVJLzzlMARfHBdOBQ" changeDate="2006-09-27T16:35:31.654-0700" changeDescription="removed OpenUP from page name." version="0.02">
  <mainDescription>&lt;h3&gt;
    Introduction
&lt;/h3&gt;
&lt;p&gt;
    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. Therefore, divide the project into short, time-boxed iterations to
    demonstrate incremental value and to get early and continuous feedback.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt;
&lt;/p&gt;
&lt;p&gt;
    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, feedback is captured early and often, high-priority risks are confronted early in the
    project. By constantly identifying and attacking risks, there is more confidence in project progress and quality.
&lt;/p&gt;
&lt;p&gt;
    Not only does the product evolve, but the team also finds better ways to work together and get involved with
    stakeholders.&lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt; The process followed by the team can be adjusted accordingly
    to leverage lessons learned and adjust project pace and needs.
&lt;/p&gt;
&lt;h3 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Practices
&lt;/h3&gt;
&lt;p style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    The next sections describe the practices associated with this principle.
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Develop your project in iterations
&lt;/h4&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    Therefore, divide your project into a series of time-boxed iterations, 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. Iterative development enables teams to continuously improve software throughout the
    development &lt;a href=&quot;./../../../openup_basic/deliveryprocesses/openup_basic_process,_0uyGoMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0uyGoMlgEdmt3adZL5Dmdw&quot;&gt;lifecycle&lt;/a&gt;.
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Focus iterations on meeting the next management milestone
&lt;/h4&gt;
&lt;p&gt;
    Without a focus to bring closure to important project issues, such as stakeholder concurrence regarding scope and
    proving the proposed architecture, a project can appear to make progress while risks and unresolved issues pile up.
&lt;/p&gt;
&lt;p&gt;
    Therefore, divide the project into phases (such as Inception, Elaboration, Construction, and Transition), with each
    phase having a clearly visible management milestone. The focus of each iteration within a phase is on achieving that
    milestone. &lt;span style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt;
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Manage risks
&lt;/h4&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    Therefore, attack &lt;a href=&quot;./../../../openup_basic/guidances/concepts/risk,_0bsLgMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0bsLgMlgEdmt3adZL5Dmdw&quot;&gt;risks&lt;/a&gt; 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 Elaboration phase,
    when the architecture has been proven and baselined.
&lt;/p&gt;
&lt;p&gt;
    At the beginning of each iteration, the entire team should consider what risks they are facing, and update the risk
    list. Make it each team member’s and stakeholder’s responsibility to have the courage to speak up and openly discuss
    risks, as well as to have the courage not to criticize the people who do speak up, even though the risk may point to a
    flaw in their area of responsibility. For each risk, articulate a plan for tracking and mitigating the risk.
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Embrace and manage change
&lt;/h4&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    Therefore, both 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.
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;
&lt;p&gt;
    If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Measure progress objectively
&lt;/h4&gt;
&lt;p&gt;
    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 have a most
    amazing ability to believe all is well in the face of catastrophe.
&lt;/p&gt;
&lt;p&gt;
    Therefore, 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.&lt;span     style=&quot;mso-spacerun: yes&quot;&gt;&amp;nbsp;&lt;/span&gt;You can also define a set of objective &lt;a href=&quot;./../../../openup_basic/guidances/concepts/metrics,_0mYYkMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0mYYkMlgEdmt3adZL5Dmdw&quot;&gt;metrics&lt;/a&gt; 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 &lt;a href=&quot;./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0l53cMlgEdmt3adZL5Dmdw&quot;&gt;&lt;span     style=&quot;COLOR: windowtext&quot;&gt;iteration assessment&lt;/span&gt;&lt;/a&gt;. Do not rely on single metrics. Rather, use a combination of
    metrics and look for trends.
&lt;/p&gt;
&lt;h4 style=&quot;MARGIN: 12pt 0in 3pt; TEXT-ALIGN: justify&quot; align=&quot;justify&quot;&gt;
    Continuously re-evaluate what you do
&lt;/h4&gt;
&lt;p&gt;
    People make mistakes during a project. If we chose to hide those mistakes, then we risk repeating the same mistakes. In
    addition, such repressed social dynamic issues can poison the team.
&lt;/p&gt;
&lt;p&gt;
    Therefore, on a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team
    to&amp;nbsp;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, &lt;a href=&quot;./../../../openup_basic/tasks/assess_results,_0l53cMlgEdmt3adZL5Dmdw.html&quot; guid=&quot;_0l53cMlgEdmt3adZL5Dmdw&quot;&gt;&lt;span     style=&quot;COLOR: windowtext&quot;&gt;assess the status&lt;/span&gt;&lt;/a&gt; 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.
&lt;/p&gt;
&lt;p&gt;
    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.
&lt;/p&gt;</mainDescription>
</org.eclipse.epf.uma:ContentDescription>