| <?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" rmc:version="7.2.0" xmlns:epf="http://www.eclipse.org/epf" |
| epf:version="1.2.0" xmi:id="-vysTxqikgsqd3pYIkSofjg" |
| name="new_concept,_S80VwCNbEdyCq8v2ZO4QcA" guid="-vysTxqikgsqd3pYIkSofjg" changeDate="2008-02-22T10:26:49.500-0500" |
| version="7.2.0"> |
| <mainDescription><p>
 |
| <strong>[*** To Fix:&nbsp; If this content is to remain in this practice, it needs to remove the references to
 |
| OpenUP.&nbsp; If you want to keep it OpenUP-specific, then it needs to move to the publish.openup plug-in.&nbsp; Also,
 |
| need to fix the reference to Project Lifecycle...it can't be made from here with the current construction.&nbsp; Maybe
 |
| a new Concept: Project Lifecycle that is independent of Unified Process lifecycle terminology needs to be
 |
| created&nbsp;(maybe it should be in common) and that concept referenced from here. ***]</strong>
 |
| </p>
 |
| <p>
 |
| Personal contribution on an OpenUP project is organized in <strong>micro-increments</strong>. A micro-increment
 |
| represents the outcome of a few hours to a few days of work for one, or typically a few people collaborating to reach
 |
| the goals of the iteration. The concept of a micro-increment helps the individual team member to partition their work
 |
| into small units that each delivers something of measurable value to the team. Micro-increments provide an extremely
 |
| short feedback loop that drives adaptive decisions within each iteration.
 |
| </p>
 |
| <p>
 |
| A micro-increment should be well defined, and you should be able to track daily progress of each micro-increment.
 |
| Micro-increments are specified and tracked by a work item. Change sets represent the physical outcome in terms of the
 |
| files are modified as a part of completing the work item. Let’s have a look at some sample micro-increments:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| <em>Identify Stakeholders.</em> Defining the Vision is a task that can drag on for weeks, so to ensure that you
 |
| make and track daily progress, divide the task into small and well-defined micro-increments. Describing and getting
 |
| buy-in on what Stakeholders to put into a Vision document is a meaningful result, and may take a few hours, or at
 |
| most a few days, and thus represents a suitable micro-increment.
 |
| </li>
 |
| <li>
 |
| <em>Develop Solution Increment.</em> Defining, designing, implementing, and testing a use case or even a scenario
 |
| can take weeks or longer. To ensure continuous progress, we seek to divide the work into smaller increments, each
 |
| of which can be done in a couple of days. A more suitable micro-increment may be to only define, design, implement,
 |
| and test a subflow of a use-case or step within a scenario.
 |
| </li>
 |
| <li>
 |
| <em>Agree on Technical Approach for Persistency.</em> Agreeing on your technical solution may take quite some time,
 |
| so we need to narrow the task to something that can be defined and agreed to in a short time. One way to partition
 |
| the work is according to the issues you need to resolve, such as persistency or reporting. This micro-increment
 |
| will probably involve defining requirements, surveying available assets, prototyping, and documentating the
 |
| decisions.
 |
| </li>
 |
| <li>
 |
| <em>Plan Iteration.</em> This micro-increment could include setting up a meeting for creating the iteration plan,
 |
| doing some preparation for the meeting, such as reviewing candidate work items, coaching the team through the
 |
| iteration planning meeting, and posting the iteration plan for easy access. The end result is something complete
 |
| and measurable, a posted plan that has buy-in from the team.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| Your application evolves in micro-increments through simultaneous execution of a number of work items. By openly
 |
| sharing progress on your micro-increments through daily team meetings and team collaboration tools, you achieve the
 |
| transparency and insight into each other’s work required for effective teamwork. At the same time, you demonstrate
 |
| continuous progress by evolving your application one micro-increment at the time.
 |
| </p>
 |
| <p>
 |
| OpenUP provides a set of activities. Each activity is captured as a set of tasks, steps within tasks, and guidance.
 |
| Even thought micro-increments are not an explicit construct in the process, you will find descriptions of how to carry
 |
| out a set of related micro-increments that are commonly found in projects within the activity. OpenUP does not provide
 |
| a complete description of potential micro-increments, and each organization should consider adding their own ‘recipes’
 |
| for commonly occurring micro-increments.
 |
| </p>
 |
| <p>
 |
| OpenUP provides a powerful learning tool and makes it easier to find relevant guidance by outlining when you are most
 |
| likely to carry out various tasks. This is done through a visualization of the delivery process which provides a
 |
| time-based organization of the tasks within the context of a <a class="elementLink"
 |
| href="./../../../practice.mgmt.risk_value_lifecycle.base/guidances/concepts/project_lifecycle_203F87.html"
 |
| guid="_nSfVwCNYEdyCq8v2ZO4QcA">Project Lifecycle</a>. As an example, you are more likely to agree on a technical
 |
| approach early in the project. This doesn’t mean you wouldn’t make technical decisions late in the project. A process
 |
| is like a map, use it to understand the big picture and as a reference, but when reality and map don’t match, trust
 |
| reality.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
