Concept: Practice
A practice is an approach to solving one or several commonly occurring problems. Practices are intended as "chunks" of process for adoption, enablement, and configuration.
Main Description

practice 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.  For more information on these elements, see Concept: Basic Process Concepts.  Practices can be informally document through one white paper, or formally documented through a combination of training courses, tutorials, process content, redbooks, etc.  Practices provide one-stop-shopping for relevant content

Why Practices?

Practices enable a new approach to building methods - practice composition.

This approach offers the following benefits:

  • Focused on business results
  • Reusability, adaptability and scalability
  • Incremental adoption
  • Easy to configure and use
  • Community development

Focused on Business Results

Practices focus on results (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!”).  Practices focus on what matters (e.g., what practices should we use to meet our business objectives vs what process is "best").

A practice has a positive impact on one or several business objectives (e.g., Time-to-Market, Improve Quality, Increase Innovation, etc.).  The adoption of a practice, and it’s impact on business objectives, can be effectively measured.

Reusability, Adaptability and Scalability

A practice is a reusable and scalable process package that may be general, domain-specific, technique-specific, organization-specific, etc. Practices can be extended/enhanced by other practices and/or techniques.  Practices can be adapted to support a range of solutions. In particular, practices can be adapted to suit your organization and supplemented by your own practices.

The core practices are the open source EPF Practices. These practices are based on a common framework that allows them to be composed.  The core practices 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 for example 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.

Extensions and additions to the practices can be:

  • used internally by an organization
  • open sourced as a part of the EPF project
  • sold commercially as an extension to the basic framework, such as the IBM(R) Practices.

Incremental Adoption

A practice is a component or aspect of a process that can be adopted independently and incrementally by an organization to build an organizational capability. Practices support easier adoption of lighter processes.  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).  

Incremental adoption is supported by the fact that each practice is described as a standalone capability and provides one-stop-shopping for all collateral related to the practice -- e.g.,  courses, tool features, services, articles, process content, enactment, etc.  

Easy to Configure and Use

Practices are designed to be interchangeable, 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.  Practices allow alternatives.  Creating a method is as simple as selecting the practices that you wish to adopt, and then publishing the results. 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.

Community Development

Since a practice can be easily authored on its own, practices are ideal for community development. The basic agile practices for the EPF Practices are, in fact, developed by the Eclipse Process Framework community. 

Practices enable a richer eco-system as it is easier to develop an individual practice than to author an entire method.