| <?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:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-B5vGpJpmJL4lyW4vGSSuYw" |
| name="practices.kellih,_hOfqgF_fEd2zpKtX6B7lBg" guid="-B5vGpJpmJL4lyW4vGSSuYw" |
| changeDate="2008-08-01T08:44:50.375-0700" version="7.5.0"> |
| <mainDescription><p>
 |
| A&nbsp;<a class="elementLink"
 |
| href="./../../../core.default.uma_concept.base/guidances/termdefinitions/practice_94B5C550.html"
 |
| guid="_wxYvkMaGEduMlb2cQZNTYw">practice</a>&nbsp;is a documented approach to solving one or several commonly occurring
 |
| problems. Practices are intended as "chunks" of process for adoption, enablement, and configuration. Practices are
 |
| built from the basic method elements.&nbsp; For more information on these elements, see <a class="elementLinkWithType"
 |
| href="./../../../core.default.uma_concept.base/guidances/concepts/basic_process_concepts_C90EF089.html"
 |
| guid="_FxJEkFUKEd2_rMtRMt_EMg">Concept: Basic Process Concepts</a>.&nbsp; Practices can be informally document through
 |
| one white paper, or formally documented through a combination of training courses, tutorials, process content,
 |
| redbooks, etc.&nbsp; Practices provide one-stop-shopping for relevant content
 |
| </p>
 |
| <h3>
 |
| Why Practices?
 |
| </h3>
 |
| <p>
 |
| Practices enable a new approach to building methods - practice composition.
 |
| </p>
 |
| <p>
 |
| This approach offers the following benefits:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Focused on business results
 |
| </li>
 |
| <li>
 |
| Reusability, adaptability and scalability
 |
| </li>
 |
| <li>
 |
| Incremental adoption
 |
| </li>
 |
| <li>
 |
| Easy to configure and use
 |
| </li>
 |
| <li>
 |
| Community development
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Focused on Business Results
 |
| </h3>
 |
| <p>
 |
| Practices <em><strong>focus on results</strong></em> (provided capabilities and resulting work products). They
 |
| translate ideas into action and deliver high value. Practices are refined based on experiences and lessons learned
 |
| (“practice makes perfect!”).&nbsp; Practices focus on what matters (e.g., what practices should we use to meet our
 |
| business objectives vs what process is "best").
 |
| </p>
 |
| <p>
 |
| A practice has a <strong><em>positive impact on one or several business objectives</em></strong> (e.g., Time-to-Market,
 |
| Improve Quality, Increase Innovation, etc.).&nbsp; The adoption of a practice, and it’s impact on business objectives,
 |
| can be effectively <em><strong>measured</strong>.</em><br />
 |
| </p>
 |
| <h3>
 |
| Reusability, Adaptability and Scalability
 |
| </h3>
 |
| <p>
 |
| A practice is a <strong><em>reusable</em></strong> and <strong><em>scalable</em></strong> process package that&nbsp;may
 |
| be general, domain-specific, technique-specific, organization-specific, etc. Practices can be extended/enhanced by
 |
| other practices and/or techniques.&nbsp; Practices can be adapted to&nbsp;support a range of solutions.&nbsp;In
 |
| particular, practices can be adapted to suit your organization and supplemented by your own practices.
 |
| </p>
 |
| <p>
 |
| The core practices are the open source EPF Practices.&nbsp;These practices are based on a common framework that allows
 |
| them to be composed.&nbsp; The core practices&nbsp;are tool-agnostic, low-ceremony practices that can be extended to
 |
| address a broad variety of development concerns, such as SOA, geographical distribution, model-driven architecture and
 |
| embedded systems. Tool and technology specific guidance can be added, such as guidance on J2EE, and a variety of
 |
| development tools. Some of these extensions can be quite modest, adding&nbsp;for example&nbsp;just tool specific
 |
| guidance to existing tasks, while others can be comprehensive, defining processes that provide a radically expanded
 |
| scope with new or altered artifacts, new or altered tasks, and new or altered roles.
 |
| </p>
 |
| <p>
 |
| Extensions and additions to&nbsp;the practices&nbsp;can be:
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| used internally by an organization
 |
| </li>
 |
| <li>
 |
| open sourced as a part of the EPF project
 |
| </li>
 |
| <li>
 |
| sold commercially as an extension to the basic framework, such as the IBM(R) Practices.
 |
| </li>
 |
| </ul>
 |
| <h3>
 |
| Incremental Adoption
 |
| </h3>
 |
| <p>
 |
| A practice is a component or aspect of a process that can be <strong><em>adopted independently</em></strong>
 |
| <strong><em>and incrementally</em></strong> by an organization to build an organizational capability. Practices support
 |
| easier adoption of lighter processes.&nbsp; Organizations only use what they really need. They can adopt one or a few
 |
| practice at a time and/or adopt a practice at higher levels over time (evolutionary and incremental
 |
| adoption).&nbsp;&nbsp;
 |
| </p>
 |
| <p>
 |
| Incremental adoption is supported by the&nbsp;fact that&nbsp;each practice is described as a standalone
 |
| capability&nbsp;and&nbsp;provides one-stop-shopping for all collateral related to the practice -- e.g.,&nbsp; courses,
 |
| tool features, services, articles, process content, enactment, etc.&nbsp;&nbsp;
 |
| </p>
 |
| <h3>
 |
| Easy to Configure and Use
 |
| </h3>
 |
| <p>
 |
| Practices are designed to be <strong><em>interchangeable</em></strong>, they may be mixed and matched or swapped out
 |
| for alternative practices. Practice-based techniques recognize that "one-size fits all" is too limiting for
 |
| processes.&nbsp; Practices allow alternatives.&nbsp; Creating a method is as simple as selecting the practices that you
 |
| wish to adopt, and then publishing the results.&nbsp;Each practice adds itself into the framework so that content can
 |
| be viewed by practice, or across practices by work product, role, task and so on.
 |
| </p>
 |
| <h3>
 |
| Community Development
 |
| </h3>
 |
| <p>
 |
| Since a practice can be easily authored on its own, practices are ideal for community development.&nbsp;The basic agile
 |
| practices for the&nbsp;EPF Practices are, in fact, developed by the Eclipse Process Framework community.&nbsp;
 |
| </p>
 |
| <p>
 |
| Practices enable a&nbsp;richer eco-system as it is easier to develop an individual&nbsp;practice than to author an
 |
| entire method.
 |
| </p></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
