| <?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:rmc="http://www.ibm.com/rmc" rmc:version="7.5.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.5.0" xmi:id="-hWKKNia-vOmQZTZWO24u5w" |
| name="how_to_adopt,_ERIDQOMPEdyM47cGD2jiaQ" guid="-hWKKNia-vOmQZTZWO24u5w" changeDate="2008-07-18T09:54:49.825-0700" |
| version="7.2.0"> |
| <mainDescription><h3>
 |
| Getting started
 |
| </h3>
 |
| <p>
 |
| Iterative development is based on the idea that a software system is built iteratively in a series of increments. Each
 |
| increment adds a subset of the final system's functionality, and the system grows to become more and more complete over
 |
| the course of the project's iterations.
 |
| </p>
 |
| <p>
 |
| Consider making all of your iterations have the same duration. This is important for two reasons: it establishes the "heart
 |
| beat" of the project, and it helps understand the project team's performance. This supports the creation of successively
 |
| more accurate estimates of remaining work. Attack the hardest problems on the first iterations, but do not overload the
 |
| first iteration too much. Make sure that you can show progress at the end of each iteration. Do not extend an iteration in
 |
| order to finish work, but also do not finish an iteration without any software to be demonstrated. If needed, break the problem
 |
| into smaller, more manageable pieces so that this balance can be achieved.
 |
| </p>
 |
| <p>
 |
| Plan an iteration in detail only when it is due to start. Each iteration starts with an iteration planning
 |
| meeting with the whole project team. In this meeting, the objectives of the iteration are defined in terms of work
 |
| items, tasks are identified for these work items, and team members sign up for tasks and provide their estimates. At
 |
| the end of the iteration planning meeting, the iteration plan is comprised of a set of work items, decomposed into
 |
| tasks that individual team members sign up for. The iteration can be started. Once an iteration is under way, it should
 |
| be allowed to proceed according to its plan, with as little external interruption as possible.
 |
| </p>
 |
| <p>
 |
| During the course of the iteration, team members provide frequent status of their tasks in focused meetings. The
 |
| frequency of these meetings is decided by team: it could be daily, a couple times a week, or weekly. Team members work
 |
| on the tasks they signed up for, following the appropriate priority. Allow detailed informal peer coordination to
 |
| happen, and mark completed work items in the iteration plan. The overall iteration status is hence readily available in
 |
| the iteration plan at all times. Any work items that have not been justifiably completed by the end of the iteration
 |
| are removed from the iteration and re-assigned to the next one (or just returned to the work items list).
 |
| </p>
 |
| <p>
 |
| Make all iterations follow the same pattern. This helps the team to focus on activities that are specific to the
 |
| beginning, middle, and end of an iteration. For example, some common activities performed during an iteration are:</p>
 |
| <ul>
 |
| <li>Iteration planning</li>
 |
| <li>Iteration architecture work</li>
 |
| <li>Continuous development of micro-increments</li>
 |
| <li>Creation of stable weekly builds</li>
 |
| <li>Bug fixing</li>
 |
| <li>Iteration review and Retrospective</li>
 |
| </ul> 
 |
| <p>See <a class="elementLink" href="./../../../practice.mgmt.iterative_dev.base/guidances/concepts/iteration_lifecycle_B16552E2.html" guid="_DI_tICNaEdyCq8v2ZO4QcA">Iteration Lifecycle</a> for more information.
 |
| </p>
 |
| <h3>
 |
| Common Pitfalls
 |
| </h3>
 |
| <p>
 |
| There are common pitfalls experienced when adopting an iterative approach, including the ones listed in the following
 |
| sections. Fore more information on challenges when transitioning from waterfall to an iterative development approach,
 |
| see <a class="elementlinkwithusertext" href="./../../../core.mgmt.common.base/guidances/supportingmaterials/references.mgmt_D80619F3.html#KRU00" guid="_JlTPUM6aEdyuBO4ZIzcyig">[KRU00]</a>.
 |
| </p>
 |
| <h4>
 |
| What project managers should plan for
 |
| </h4>
 |
| <p>
 |
| One of the most difficult situations for project managers is to transition from a traditional development approach
 |
| (such as waterfall) to an iterative approach. There is more planning with iterative development than with waterfall: one
 |
| plan per iteration. At every iteration, there is negotiation with stakeholders, changes in scope, and re-planning.
 |
| Project managers need to avoid detailed planning upfront, and should work with their best estimates for the tasks at
 |
| hand in a given iteration. </p>
 |
| <p>
 |
| However, this behavior should not result in unplanned and non-prioritized requirements
 |
| creating scope-creep, nor unnecessary rework happening on elements that are not broken. The iteration plan, with iteration
 |
| objectives and planned tasks, should be collaboratively created by the project manager, the team, and stakeholders in order
 |
| to promote a common understanding and buy-in into what is expected at the end of an iteration.
 |
| </p>
 |
| <h4>
 |
| Which comes first: specifications or software? 
 |
| </h4>
 |
| <p>
 |
| In a waterfall approach, progress is often measured by the completion of specifications. For example, if the design
 |
| specification is completed and signed-off, the team advances to the implementation based on the design specification.</p>
 |
| <p> 
 |
| With iterative development, artifacts evolve throughout the iterations, and every iteration should result in an
 |
| increment in the capabilities offered by the solution: in other words, implemented, tested software that is able to be
 |
| demonstrated (and potentially shipped) to customers. Software comes first. Planning is more important than the plans.
 |
| Designing and architecting an evolving solution is more important than capturing and polishing design and architecture
 |
| models. At the end of each iteration, perform an assessment to gauge the completion of requirements that have
 |
| passed test cases. Another way to make significant progress is by focusing on the harder problems (or risks) as
 |
| early as possible, thus making sure that you create and use a sound, executable architecture as the basis for the other
 |
| requirements.
 |
| </p>
 |
| <h4>
 |
| Different iterations for the different disciplines
 |
| </h4>
 |
| <p>
 |
| A common problem found in organizations moving from a waterfall to an iterative process is that they use the iteration
 |
| concept only as an "envelope" for their engineering disciplines. For example, it is common to hear people in those
 |
| organizations talk about "requirements iteration" or "test iteration". A fundamental tenet of iterative
 |
| development is that it takes a holistic view of work items: each work item assigned to an iteration is completed in
 |
| that iteration. For example, a "Login User" work item would see all required tasks (such as design, code, and test) to
 |
| complete that work item. At the end of the iteration, the Login User behavior can be demonstrated as an integral part of
 |
| the executable system.
 |
| </p>
 |
| <h4>
 |
| No visible progress
 |
| </h4>
 |
| <p>
 |
| Some teams will have work items that are not completed during an iteration as expected, and will not report problems.
 |
| This creates a false impression that work items planned for the iteration are being closed, thus showing an inaccurate
 |
| iteration burndown.<br />
 |
| In order to avoid this, monitor active tasks closely, and address any slippage promptly. Use frequent, short status
 |
| meetings to gauge progress and detect issues. Create a "no blame" environment where everyone feels empowered by the
 |
| team and actively seeks advice and help from the team.
 |
| </p>
 |
| <h4>
 |
| Adding work to an ongoing iteration
 |
| </h4>
 |
| <p>
 |
| Management or stakeholders may impose more work to be added to an on-going iteration. While this is sometimes
 |
| legitimate (for business reasons), there is a risk that this work just gets informally accepted by the team, without
 |
| passing through the Work Items List, where it gets prioritized with the remaining work.<br />
 |
| In order to minimize the impact of new work being added to an iteration, make sure to involve stakeholders in the
 |
| planning process, so that they understand the impact a new work item brings to the current iteration. Be prepared to
 |
| negotiate the removal of lower priority work from the iteration, in order to accommodate the new requested work.
 |
| Another approach is to convince stakeholders that in a few weeks the iteration will end (with demonstrable progress),
 |
| and that the new work item can be prioritized and assigned to the next iteration.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
