OpenUP/OpenUP_baseline_EN/exported_HTML_1_0/openup/guidances/concepts/iteration.html - epf/org.eclipse.epf.nl-libraries - Git at Google

 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
 <!-- VERSION rmc:7.1.0 -->
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
 <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
 <!-- START NON-TRANSLATABLE -->
 <title>openup&amp;#92;guidances&amp;#92;concepts&amp;#92;&amp;#92;iteration.xmi</title>
 </head>
 <!-- WARNING: do not modify the generated comments in this file below this line.  They are used as markers for the import process. -->
 <body>
 Element Name: iteration.xmi<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: presentationName<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:presentationName,_lam4ADkBEduxovfWMDsntw CRC: 1814057918 -->Iteration<!-- END:presentationName,_lam4ADkBEduxovfWMDsntw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: briefDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:briefDescription,_lam4ADkBEduxovfWMDsntw CRC: 2747283346 -->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 artifacts necessary to use this release.<!-- END:briefDescription,_lam4ADkBEduxovfWMDsntw -->
 <br/><br/><br/>
 <!-- START NON-TRANSLATABLE -->
 Attribute: mainDescription<br/><br/>
 <!-- END NON-TRANSLATABLE -->
 <!-- START:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A CRC: 4186943231 --><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 artifacts necessary to use this release. The
     executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, and 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.
 </p>
 <p>
 	Each iteration
     builds upon the results of the previous iteration, and will produce a product increment one step closer to the final
     product. Iterations are timeboxed, meaning that 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, and reduces 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.
 </p>
 <p>
 	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 of the problems were discovered at once during the single
     massive integration step, which occurred very late in the cycle, and where a single problem can halt 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, perform 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.
 	</p>
 <p>
 	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 the following table. <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
             </th>
             <th scope="col">
                 Factors leading to increased iteration length
             </th>
         </tr>
         <tr>
             <td>
                 Small teams
             </td>
             <td>
                 Large teams
             </td>
         </tr>
         <tr>
             <td>
                 Co-located teams
             </td>
             <td>
                 Distributed teams
             </td>
         </tr>
         <tr>
             <td>
                 Strong configuration management system
             </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
             </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 <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 that 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.
     </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.
     </li>
 </ul><!-- END:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A -->
 </body>
 </html>
	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE html PUBLIC "-//W3C/DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
	<!-- VERSION rmc:7.1.0 -->
	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
	<!-- START NON-TRANSLATABLE -->
	<title>openup&#92;guidances&#92;concepts&#92;&#92;iteration.xmi</title>
	</head>
	<!-- WARNING: do not modify the generated comments in this file below this line. They are used as markers for the import process. -->
	<body>
	Element Name: iteration.xmi<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: presentationName<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:presentationName,_lam4ADkBEduxovfWMDsntw CRC: 1814057918 -->Iteration<!-- END:presentationName,_lam4ADkBEduxovfWMDsntw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: briefDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:briefDescription,_lam4ADkBEduxovfWMDsntw CRC: 2747283346 -->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 artifacts necessary to use this release.<!-- END:briefDescription,_lam4ADkBEduxovfWMDsntw -->
	<br/><br/><br/>
	<!-- START NON-TRANSLATABLE -->
	Attribute: mainDescription<br/><br/>
	<!-- END NON-TRANSLATABLE -->
	<!-- START:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A CRC: 4186943231 --><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 artifacts necessary to use this release. The
	executable is demonstrable, allowing the team to demonstrate true progress to stakeholders, and 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.
	</p>
	<p>
	Each iteration
	builds upon the results of the previous iteration, and will produce a product increment one step closer to the final
	product. Iterations are timeboxed, meaning that 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, and reduces 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.
	</p>
	<p>
	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 of the problems were discovered at once during the single
	massive integration step, which occurred very late in the cycle, and where a single problem can halt 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, perform 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.
	</p>
	<p>
	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 the following table. <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
	</th>
	<th scope="col">
	Factors leading to increased iteration length
	</th>
	</tr>
	<tr>
	<td>
	Small teams
	</td>
	<td>
	Large teams
	</td>
	</tr>
	<tr>
	<td>
	Co-located teams
	</td>
	<td>
	Distributed teams
	</td>
	</tr>
	<tr>
	<td>
	Strong configuration management system
	</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
	</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 <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 that 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.
	</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.
	</li>
	</ul><!-- END:mainDescription,-vi8wxwxVZLY0SMPFxZjD7A -->
	</body>
	</html>