New Paradigm: Practices as First-Class Citizens
Traditional processes (such as the Unified Process) are described by their different activities and artifacts. These activities and artifacts may serve different purposes—doing requirements with use cases, test-driven design, or component-based development. These practices are not explicit, not visible, and don't have a name. The process contains a "soup" of practices.
To easily identify, design, and deploy new practices, we need to let practices become first-class citizens. Process is the result of composing the practices you have selected. To make this possible, we need to be able to separate different practices from one another during design, deployment, and improvement.
In this regard, EssUP is very different from other processes or methods in how it is presented. It embodies an idea new to the process industry—Separation of Concerns (SOC), as in aspect-oriented thinking. When we apply this idea to process development, we generate a fundamentally different process—one that makes it easier and more intuitive to select your tailor-made software process. Most importantly, it will be more natural and intuitive to plan and execute a software project. To illustrate, here are a number of situations where we have applied the idea of SOC:
- Each practice is kept separately from the other practices. You choose only the practices you need without having to deselect activities and artifacts. Just select the practices you want and compose them with one another and with your existing process.
- You can easily separate elements from your existing process and from the elements of the EssUP. This lets you improve what you already have, one practice at a time, in an evolutionary way.
Starting from a generic platform, you describe your own process using a very simple technique inspired by the game industry. Based on this, you can add practices without requiring a revolutionary adoption of all practices. You take what you need and what you think your organization can adopt without severe risks.
- EssUP separates two different views of the process—the process authors' and software developers' view. In the past, processes have almost entirely focused on the authors' needs. EssUP prioritizes the developers' perspective. It uses techniques from the game industry to develop, teach, apply, and use the process to make it lightweight and agile. And, we promise, much more fun.
- We separate the essentials from the non-essentials. This lets us create a core lightweight process with unprecedented growth potential (hundreds of practices).
We have learned over the years that few people really read process materials, whether in a book or on the Web. So instead of giving developers lots of ignored information, we provide the real essence and let them learn the rest however they want. Some may want to learn it by studying, and there are a lot of articles and books available to do that. Others learn by working with people who have already gained the knowledge. The effect of this separation is that the process is lightweight, and easy to adopt and change.
- It separates explicit knowledge from tacit knowledge in a balanced way. Tacit knowledge is knowledge you acquired one way or the other—you have it in your head. Explicit knowledge exists in the form of descriptions made available to you.
In the past, processes have tried to capture all related knowledge in an explicit form. Though this is a good ambition, it makes the process heavy. EssUP makes only the essentials explicit. The rest is either tacit or referenced from the essentials. However, the most elegant form of dealing with knowledge is to deliver it through intelligent agents when needed—this is what we call a "smart practice." Such smart practices are now available in Waypointer from Jaczone (www.jaczone.com).
- It is prepared to separate creative work from no-brain work. This lets you spend your time on what humans are good at—being creative—and leaves the no-brain work to intelligent agents. We used the term "prepared" because EssUP doesn't come with agents; agents are add-ons.
- It separates two kinds of artifacts—alphas and betas. We have not yet given them any names. We think the distinction between alphas and betas are one of the most fundamental in all projects. Tentatively you may replace alpha with "key thing" and beta with "evidence" (of a key thing).
Alphas are the most important things software projects have, whether they exist in a described form or not. Actually, the alphas are not specific for any particular process. For instance, every software project has these alphas: project, implemented system, backlog, risk. Each alpha has a set of betas: A project alpha may have a project plan, an iteration plan. A risk may have a risk list. A backlog may have a feature list and change list.
Betas are evidence of alphas. They can be descriptions, diagrams, flow charts, or whatever you like to document or not document. "Not document" means that teams keep the knowledge in their heads.
Whereas alphas are stable and process independent, betas may be different based on what practices you have chosen to use. The separation of the alphas from the betas lets you keep the project documentation at a minimum. You can in a precise way discuss how much to document. This lets you be agile in a disciplined way. You can separate the essentials from the less essential.
