| <?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.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1" xmlns:rmc="http://www.ibm.com/rmc" rmc:version="7.5.1" xmi:id="-EvdZRG7js6dnleNgGOQYfQ" name="new_concept,_WBtggJ8wEd-dppiOhprtkA" guid="-EvdZRG7js6dnleNgGOQYfQ" changeDate="2010-08-03T11:54:27.000-0700" version="7.5.0"> |
| <mainDescription><p> |
| A&nbsp; practice 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; 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> |
