|
In the final installment, our authors examine what’s needed to make a practice-based approach work, and how EssWork delivers these innovations to you.
May 04, 2007
URL:http://www.drdobbs.com/architecture-and-design/enough-of-processes-lets-do-practices-pa/199204020
Ivar is one of the "fathers" of components and component architecture, use cases, UML, and the Rational Unified Process. Pan-Wei and Ian are chief scientists at Ivar Jacobson Consulting. The authors can be contacted at www.ivarjacobson.com.
As we saw in the first two parts of this article, the time has come for processes to reinvent themselves as sets of separate but collaborating practices. For this reinvention to happen, new approaches are required to make the practices more accessible, to assemble them into a coherent way-of-working, and to let you apply them in the way that you want. In this installment, we examine the innovations needed to make a practice-based approach work, and how EssWork delivers these innovations to you.
To change how people use process descriptions, we use a "card metaphor" (as in 5x3-inch index cards) to present the most important things about a practice. The cards, samples of which are shown in Figure 1, immediately bring the practice to life. They present a succinct summary of the most important things you need to remember about the practice. On their own, they provide enough information for you to apply the practice—including information such as where you are, when you can stop, and when you are finished. In most cases, all you need to apply a practice is the set of cards.
The cards also help you adapt the practice. You can scribble on the cards to make them more specific to your project needs. This provides a unique way to tune the practice on the fly and capture lessons learned using it. You can even write out additional cards to extend the practice as you come up with new ways of doing things.
Every card has a guideline presenting the next level of essential information to help you apply the practice. The guidelines are short (two to four pages) and to the point. Thus, they have more detail—but not too much. In teams, you expect members to have different backgrounds and competencies. Competent members use the cards to drive their work, while the guidelines put less experienced members on the same page. If team members are novices, no amount of textual descriptions will help. Consequently, we recommend they receive coaching from a more experienced team member, use an active practice, go for some training, or read a book.
In this way, practice descriptions are deliberately kept succinct and lightweight. This is good because their goal is to focus on essentials, which by definition are a subset of the entire practice area. Moreover, there is no need to repeat existing information (in books or papers, for instance) about the practice. The intention is not to supplant or replace the existing reference material, but to complement it with a simple description of the practice in a form that can be used on a daily basis when developing software.
The guidelines refer to additional support materials. They cite standard references and information sources, rather than trying to rewrite or replace them. This is particularly powerful when presenting your existing practices in this new format, as you need only distill the essentials for your cards and guidelines, rather than reformatting/rewriting existing information. Practices can now be presented as a set of printed cards and guidelines (and used in the way that XP projects use User Story Cards), and electronically as part of an active, integrated way-of-working.
Manipulating and accessing materials in both a physical and electronic fashion lets teams work in ways that suit them. Most teams will use a mixture of physical cards (to facilitate team communication and group events) and an electronic environment (to provide online help and access to the way-of-working).
Once practices have been separated, there needs to be some mechanism to compose the practices to form a team's way-of-working.
To enable the practices to be composed, we need a starting point—something that, although practice-independent, provides the basis for the definition and composition of practices. We call this starting point the "software development kernel" or, when using the cards and the card metaphor, the "software development game board." The kernel is a lightweight software development process, which, due to the absence of any concrete practices, is almost completely tacit. Many of the underlying concepts driving modern software development practices are embodied in the kernel. This isn't surprising, since all software development teams handle the same concepts and share the same mission—to develop good software. Having the practices share these common concepts is key to enabling them to be defined separately, yet be seamlessly composed together.
For example, the kernel contains the concept of the "specified system." Every project has to have a shared understanding of what the system is supposed to do—the system's requirements or specification, as it were. This understanding can take many forms and be communicated in many ways, and the kernel doesn't care how this is done—it just reminds you that it has to be done. There are many practices you could use to specify the system, anything from having a quick conversation with the customers to producing a formal system requirement specification. It is up to the team to pick the best practice to meet its—and its customers'—needs.
The kernel also contains the concept of a "backlog," a central concept in Scrum and other management methods. Working from a backlog and prioritizing the work it contains ensures that work is not lost. The presence of the backlog in the kernel lets the kernel be used to guide your software development, even when no practices have been selected. Again, just like specifying the system, how you address the work in the backlog is undefined and limited only by your creativity. Of course, there are practices to help you do this. The kernel provides the mechanism to link these practices together and focus the team on producing working software.
The kernel is the starting point for assembling a team's way-of-working. Practices can then be added to the kernel to assemble the team's way-of-working and make it explicit. Each practice brings its own approach to solving one of the problems of software development. For example, there are many ways of specifying the system to be built: You could use User Stories, Use Cases, or Declarative Requirements. Each of these approaches would be expressed as a different practice and define different things to produce and different things to do. This is illustrated in Figure 2, which shows how a number of different practices can fill the same "holes" in the kernel (in this case, the kernel elements are "specified system" and "specify the system").
At any point in time, the team can select a practice and compose it into its way-of-working. This results in existing cards and guidelines being augmented with the newly selected practices. The infrastructure then adjusts the tools and environment to reflect and support the new set of practices.
Using cards to help assemble and tailor the way-of-working is effective. Cards from the various practices can be compared, arranged, and annotated to provide a snapshot of the team's way-of-working. To compose the process from physical cards, you first identify the hole in the kernel you want to fill, then add one or more practices to fill the hole. Figure 3 shows how different requirements practices can be mixed-and-matched to define a specific way to specify the system.
Once the reasoning and negotiation has been completed, selected practices can be assembled within the electronic environment to capture the resulting way-of-working, and help the team apply the selected practices.
Local practices can easily be integrated into the way-of-working by creating additional cards to represent their products. This lets us align the team's actual way-of-working to the set of cards in use, and keeps the set of cards up-to-date. This provides an easy-to-use mechanism to prevent the project and process from getting out of sync.
For practices to be useful, they need to be more than just something you read as a reminder or to understand an abstract concept (such as iterations). They must also help you understand your project and progress more effectively. We do this by further refining the card metaphor. Just as we have CRC (Class Responsibility and Collaborators) cards to identify and design classes, we use cards to facilitate almost every facet of software development.
This allows the cards to play a role throughout the project, rather than just being used when the team is learning or preparing to start work. With this in mind, we would like to highlight two ways to use the cards.
One way is when you work with the practices on the project. The cards make it easy to apply the practices and create tasks for the team to undertake. Among the most important things presented on the cards are the lifecycles of the things involved in the practice. These let the cards be used to visualize the current state of the project and determine the next move(s). You can do this as part of project planning or on the fly as the team decides what to do next. As you are always looking at the next move, you always know which parts of the selected practices to apply. If things have already been done or are already in place, then practices to achieve these results aren't needed and can be ignored.
Collections of cards can be assembled to represent the work to be done. By writing on the cards, we can capture exactly what's going on: estimates, progress to date, and who's doing what. We can then use the cards to build the backlog, the task lists, and the iteration plans.
By relating the work to the practices in this way, the practice information is always immediately at hand and it is clear which practices are to be applied when. They can even be tracked by sorting and writing on the cards, or by entering the work items they represent into a spreadsheet or task management tool.
A second way to use cards is when the team applies a single practice. One of the most exciting things about this approach is the ability to apply a single practice without changing the rest of the things being done on the project or reworking the things already produced. By using the kernel to drive the project forward from its current state to its desired state, you can apply the practices you need when you need them. This means that teams can select and experiment with new practices without undertaking long and wasteful process engineering or documentation exercises. Cards can also be useful when you plan and track the project, and when you improve your way-of-working.
While physical cards provide a good mechanism for understanding and applying the practices, they don't scale up for use by large projects or distributed teams—and can be a turn off for teams that are not enthusiastic about the cards or Agile approaches in general.
An electronic environment is needed to really let us compose the practices, generate the right cards and guidelines, manage the cards, and make the practices visible within the team's selected collaborative software development environment. We call this environment "EssWork," short for "Essential Work," and have implemented it to support the electronic version of the Essential Unified Process.
EssWork provides a practice-centric infrastructure into which you can load whatever practices you need (Figure 4). By default, the infrastructure includes the new card-based user experience, the practice persistence needed to store the team's way-of-working, and the interfaces for the development of practice adaptors to integrate EssWork into the team's development environment. It can also be complemented with practice activation technology (such as Waypointer) to bring the practices to life.
EssWork (www.esswork.com) is not a branded process. It is a practice-independent framework that provides the infrastructure and foundation for teams to compose their own ways-of-working. Software developers will not learn, adopt, or follow EssWork. They will learn, adopt, and follow the practices that it brings to life. People won't say they are using EssWork when developing software anymore than they say that they are using e-mail or word processors. It will just be a natural part of the team's infrastructure, enabling them to benefit from adopting and applying practices in an agile and disciplined fashion.
The EssWork Core is freely available (www.ivarjacobson.com), and is to be donated, along with the technical practices from the Essential Unified Process, to the Eclipse Process Framework (www.eclipse.org/epf) where the EssWork community will be hosted. EssWork Core supports the use of practices over a rich set of client-access platforms and collaborative-development environments, including Microsoft Visual Studio and Eclipse, and server-side data stores such as Microsoft Team Foundation Server and JIRA.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.