| <?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" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-vi8wxwxVZLY0SMPFxZjD7A" |
| name="new_concept,_lam4ADkBEduxovfWMDsntw" guid="-vi8wxwxVZLY0SMPFxZjD7A" changeDate="2007-05-24T11:34:55.636-0700"> |
| <mainDescription><h3>
 |
| What is an Iteration
 |
| </h3>
 |
| <p>
 |
| An iteration is a set period of time within a project in which you produce a stable, executable version of the product,
 |
| together with any other supporting documentation, install scripts, or similar, necessary to use this release. The
 |
| executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, get feedback on how they
 |
| are doing so that they can improve their understanding of what needs to be done, and how to do it, Each iteration
 |
| builds upon the results of previous iteration, and will produce a product increment one step closer to the final
 |
| product. Iterations are timeboxed, meaning the schedule for an iteration should be regarded as fixed, and the scope of
 |
| the iteration's content actively managed to meet that schedule.
 |
| </p>
 |
| <p>
 |
| At each iteration, artifacts are updated. It is said that this is a bit like "growing" software. Instead of developing
 |
| artifacts one after another, in a pipeline fashion, they are evolving across the cycle, although at different rates.
 |
| </p>
 |
| <p>
 |
| Iterative development is very disciplined: the iteration length is fixed; the objectives of iterations are carefully
 |
| planned; the evaluation criteria are established when each iteration is planned; and the tasks and responsibilities of
 |
| participants are well defined. Additionally, objective measures of progress are captured. Some reworking takes place
 |
| from one iteration to the next, but this too is done in a structured fashion.
 |
| </p>
 |
| <p>
 |
| Each iteration should address the most critical risks, and implement the highest-priority Work Items. This ensures that
 |
| each iteration adds maximum stakeholder value, while reducing uncertainty. Iterative development is typically combined
 |
| with frequent or continuous integration: as unit-tested components become available, they are integrated, then a build
 |
| is produced and subjected to integration testing. In this way, the capability of the integrated software grows as the
 |
| iteration proceeds, towards the goals set when the iteration was planned. Regular builds, such as daily or more
 |
| frequent builds, let you break down the integration and test issues and spread them across the development cycle. These
 |
| issues have often been the downfall of large projects because all problems were discovered at once during the single
 |
| massive integration step, which occurred very late in the cycle, and where a single problem halts the whole team.
 |
| </p>
 |
| <h3>
 |
| What Problem Do Iterations Address?
 |
| </h3>
 |
| <p>
 |
| Today’s software applications are too complex to allow you to sequentially define the requirements, come up with an
 |
| architecture and design, do an implementation, carry out testing, and get it all right. With waterfall development, you
 |
| typically do not get meaningful feedback on what improvements can be made until it is so late in the project that it is
 |
| too costly to make them. By contrast, dividing the project into a series of time-boxed iterations allows you to deliver
 |
| capabilities that can be assessed by stakeholders at the end of each iteration. This approach provides rapid and timely
 |
| feedback loops enabling issues to be addressed and improvements made at a lower cost while budget and time still allow,
 |
| and before the project has gone so far ahead that major rework is required.
 |
| </p>
 |
| <h3>
 |
| Iteration Length
 |
| </h3>
 |
| <p>
 |
| Iterations are typically 4 weeks long, although some teams will work with iterations as short as a week or as long as
 |
| six weeks. For factors driving iteration length, see Table 1.
 |
| </p>
 |
| <p>
 |
| <strong><em>Table 1. Factors Impacting Iteration Length.</em></strong><br />
 |
| &nbsp;<br />
 |
| </p>
 |
| <table style="WIDTH: 547px; HEIGHT: 356px" cellspacing="2" cellpadding="2" width="547" border="1">
 |
| <tbody>
 |
| <tr>
 |
| <th scope="col">
 |
| Factors leading to reduced iteration length&nbsp;
 |
| </th>
 |
| <th scope="col">
 |
| Factors leading to increased iteration length
 |
| </th>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Small teams&nbsp;
 |
| </td>
 |
| <td>
 |
| Large teams
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Collocated teams&nbsp;
 |
| </td>
 |
| <td>
 |
| Distributed teams
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Strong configuration management system&nbsp;
 |
| </td>
 |
| <td>
 |
| Poor configuration management system
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Dedicated, full-time resources
 |
| </td>
 |
| <td>
 |
| Matrixed or part-time resources
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Automated testing
 |
| </td>
 |
| <td>
 |
| Lack of automated testing
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Integrated tool environment&nbsp;
 |
| </td>
 |
| <td>
 |
| Absence of good automation and tool integration
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Team experienced with iterative development
 |
| </td>
 |
| <td>
 |
| Team inexperienced with iterative development
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Fast decision making
 |
| </td>
 |
| <td>
 |
| Policies and bureaucracy preventing fast decision making
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Unclear requirements
 |
| </td>
 |
| <td>
 |
| Well-understood requirements
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| Unclear or brittle architecture
 |
| </td>
 |
| <td>
 |
| Well-defined and stable architecture
 |
| </td>
 |
| </tr>
 |
| <tr>
 |
| <td>
 |
| New and poorly understood technology
 |
| </td>
 |
| <td>
 |
| Well-understood technology
 |
| </td>
 |
| </tr>
 |
| </tbody>
 |
| </table><br />
 |
| <br />
 |
| <h3>
 |
| Why Iterate?
 |
| </h3>
 |
| <p>
 |
| The iterative approach has proven itself superior to the waterfall approach for a number of reasons, see&nbsp;<a class="elementlinkwithusertext" href="./../../../openup/guidances/supportingmaterials/references_6CCF393.html#KRO05" guid="_9ToeIB83Edqsvps02rpOOg">[KRO05]</a> for more details:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| You are more likely to build an application that addresses user needs. Involve the customer in the development
 |
| project and implement and validate the capabilities deemed most essential in each iteration.
 |
| </li>
 |
| <li>
 |
| Integration is not one “big bang” at the end of a project. Each iteration evolves executable code that is
 |
| continuously integrated to enable rapid feedback and minimize later revision.
 |
| </li>
 |
| <li>
 |
| Risks are usually discovered or addressed during early iterations. Implement the most essential capabilities
 |
| partially and demonstrate them to key stakeholders to make sure that you are on the right track.
 |
| </li>
 |
| <li>
 |
| Your ability to work effectively is fine-tuned. During early iterations, team members are walking through all
 |
| lifecycle activities, which ensures they have the tools, skills, organizational structure, and so on to work
 |
| effectively.
 |
| </li>
 |
| <li>
 |
| Management has a way of making tactical changes to the product. Iterative development allows you to evolve partial
 |
| implementations of the end product quickly and use these for quick release of a reduced-scope product to counter a
 |
| competitor's move.
 |
| </li>
 |
| <li>
 |
| Reuse is facilitated. Discussions and reviews of the design in early iterations allow team members to spot
 |
| potential opportunities for reuse and then develop a mature common code for these opportunities in subsequent
 |
| iterations.
 |
| </li>
 |
| <li>
 |
| Defects can be found and corrected over several iterations. Flaws are detected in early iterations, rather than
 |
| during a massive testing phase at the end.&nbsp;
 |
| </li>
 |
| <li>
 |
| Project personnel are better used. An iterative process encourages widening the scope of expertise of the team
 |
| members, allowing them to play many roles and thus enabling a project manager to make better use of the available
 |
| staff and simultaneously remove problematic handoffs.
 |
| </li>
 |
| <li>
 |
| Team members learn along the way. The project members have several opportunities within a development cycle to
 |
| learn from their mistakes and improve their skills from one iteration to another.
 |
| </li>
 |
| <li>
 |
| The development process itself is improved and refined along the way. The end of iteration assessment includes a
 |
| retrospective where the team identifies what can be improved in the next iteration in both the organization and the
 |
| process.&nbsp;
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |