Читать книгу The Essentials of Modern Software Engineering - Ivar Jacobson - Страница 14

3

Essence in a Nutshell

In this chapter we present key ideas resulting in Essence as a common ground for all software engineering methods. Basic concepts of Essence, the notion of a method and the architecture of Essence are introduced. In particular, this chapter introduces and explains

• the key ideas resulting in Essence and why they are important for software engineering;

• the concept of composition as a way to combine practices to form a method to guide a development endeavor;

• the common ground Essence as consisting of a language and a kernel of essential elements;

• the concepts of practices and methods built of top of Essence forming a method architecture; and

• the concept of cards as a means to give the abstract elements of Essence an attractive and tangible user experience.

This chapter shows that the main idea behind Essence is to focus on the most important things to think about when developing software (focus on the essentials only).

Essence became a standard in 2014 as a response to “the craziest thing in the world” presented in Chapters 1 and 2.

In this chapter, we will present some key ideas used as input when designing Essence. We will also separately motivate each idea and describe how it has been realized with Essence.

3.1 The Ideas Essence relies on the following insights.

• Methods are compositions of practices.

■ There are a huge number of methods (guesstimated to be > 100,000) in the world, some of which are recognized and have a large user base.

■ There are only a few hundred reusable practices in the world. With n practices the number of theoretically possible combinations of these practices can quickly grow very large.

• There is a common ground, or a kernel, shared among all these methods and practices.

• Focus on the essentials is needed when providing guidelines for a method or practice.

• Providing an engaging user experience is possible when teaching and learning methods and practices.

3.2 Methods Are Compositions of Practices

As explained in Chapter 2, a method is created with the intention to guide the software development team(s) through everything they need to do during the development process: that is, giving them all the practices they need. A practice is like a mini-method in that it guides a team in how to carry out one particular thing in their work. For instance, “requirements management” is a potential practice dealing with what a software system should do. It is obviously not all you need to do when you develop software; you need many other such practices, for instance, “design, implement, and test,” “organize your team,” “perform project management,” etc. For small endeavors, it is not uncommon that you need a dozen such mini-methods/practices.

Because a method is attempting to give complete guidance for the work, it relies on a composition of practices. This is an operation merging two or more practices to form the method. Such a composition operation has to be defined mathematically in order to be unambiguous and precise. It has to be specified by a method expert with the objective to resolve potential overlaps and conflicts among the practices, if there are any. Usually most practices can be composed easily by setting them side by side because there are no overlaps and conflicts, but in some cases, these have to be taken care of.

This is because, while practices are separate, they are not independent. They are not like components that have interfaces over which communication/inter-operation will happen. They also share elements, so let us briefly look at what these might be. Inside a practice are, for instance, guidelines for activities that a user (e.g., a developer) is supposed to perform, and guidelines for work products (e.g., components) that a user is expected to produce. Although two practices may share the same work product, they contribute separate guidelines to this work product, and composing these two practices, resolving potential overlaps and conflicts, will require that you specify how the contributions must be combined in a meaningful and constructive way.

However, not just methods are compositions, but also practices can be compositions of smaller practices. Scrum, for instance, can be seen as a composition of three smaller practices: Daily Standup, Backlog-Driven Development, and Retrospective. (We will discuss these later when we come to Scrum in Part III.)

We will come back later to compositions when we have more details about practices in our knowledge bag. (If you want to have a peek into more on compositions now, take a look at Chapter 19.)

What eventually becomes a method or a practice is just a practical decision. To reiterate, a method is closer to the complete guidance you need whereas a practice (composed or not) is just one aspect (or several) of what you need to guide the team(s) to deal with all the “things” they need to deal with when developing software. An individual can create one or a few practices based on experience, but a method is always too big to be created by one individual without “borrowing” practices from others. We say “borrowing” within quotes, because it is an act without consent of the originator. Practices are successful because of the knowledge they provide, whereas methods are usually branded (like RUP, SAFe, DAD, Nexus, Less) and success is more about great marketing than about knowledge being provided.

When we say that a practice guides a team, we mean it is described one way or another to indicate what to do. How explicit a practice should be, i.e., how detailed the descriptions should be, depends on two factors: capabilities and background.

Capability. Capability refers to team members’ ability, based upon the knowledge they already have, to figure things out for themselves. Team members with high skill and capability need only a few reminders and examples to get going. Others may need training and coaching to learn how to apply a practice effectively.

Figure 3.1 How explicit practices depend on capability and background.

Background. If the team has worked together using a practice in the past or have gone through the same training, then they have a shared background. In this case, practices can be tacit. On the other hand, if team members have been using different practices, e.g., some have been using traditional requirements specifications while others have been using user story (a more modern way of dealing with requirements), then they have different backgrounds. In this case, practices should be described to avoid miscommuni-cation.

How these two factors interact and influence the form that your practices should take is summarized in Figure 3.1.

As an example, in the case where a team’s requirements challenges relate to different backgrounds and members do not know that much about requirements collaboration techniques, the team needs explicit practices and some coaching which a more experienced team member can provide out of the box. Additional factors to be considered, contributing to the need for practices, include the size of the team and how its members are geographically distributed.

3.3 There Is a Common Ground

Using a common ground as a basis for presenting guidelines for all practices will make it easier to teach, learn, use, and modify practices and easier to compare practices described using the same common ground.

Figure 3.2 Essence and its parts.

Figure 3.3 Essence method architecture.

Figure 3.2 illustrates Essence as this common ground, providing both a language and a kernel of software engineering.

The Essence language is very simple, intuitive, and practical, as we will show later in this section.

As previously described, it was left to the software engineering community to contribute practices, which can then be composed to form methods. Figure 3.3 depicts the relationships between methods composed using practices, which are described using the Essence kernel and the Essence language. As you can see in Figure 3.3, the notation used in the Essence language for practices is the hexagon, and for methods it is the hexagon enclosing two minor hexagons.

The practices are essentialized, meaning they are described using Essence—the Essence kernel and the Essence language. Consequently, the methods we will describe are also essentialized. In Part III you will see many examples of essentialized practices.

Figure 3.4 A method is a composition of practices on top of the kernel.

Essentializing not only means that the method/practice is described using Essence; it also focuses the description of the method/practice on what is essential. It doesn’t mean changing the intent of the practice or the method. This provides significant value. We as a community can create libraries of practices coming from many different methods. Teams can mix and match practices from many methods to obtain a method they want. If you have an idea for a new practice, you can just focus on essentializing that practice and add it to a practice library for others to select; you don’t need to “reinvent the wheel” to create your own method (see, e.g., Figure 3.4. This liberates that practice from monolithic methods, and it will open up the method prisons and let companies and teams get out to an open world.

As mentioned earlier, a team usually faces a number of challenges and will need the guidance of several practices. Starting with the kernel, a team can select a number of practices and support tools to make up its way-of-working. The set of practices that they select for their way-of-working is their method.

When learning a new practice or method, perhaps about use cases, or user stories, it is sometimes difficult to see how it will fit with your current way-of-working. By basing the practices on a common ground, you can easily relate new practices to what you already have. You learn the kernel once and then you just focus on what is different with each new practice.

Even if there are many different methods (every team or at the least every organization has one), they are not as different as it may seem. Examples of common practices are user story, test-driven development (TD), and backlog driven development. These terms may not mean much to you now, but in Part III we will give meaning to them. Right now, this combination serves just as an example of the relationship between a method and its practices.

Sidebar 3.1 How Much Does a Developer Need to Know About Methods?

You may be asking yourself at this point, do I really need to care about all of this method theory? Remember, a method is a description of the team’s way of working and it provides help and guidance to the team as they perform their tasks. What the kernel does is help you structure what you do in a way that supports incremental evolution of the software system. In other words, it puts you in control of the way you work and provides the mechanism to change it.

The idea of describing practices on top of the kernel is a key theme of this book. A further discussion of how they are formed this way is found in Part III (see also Sidebar 3.1).

3.4 Focus on the Essentials

Our experience is that developers rarely have the time and interest to read detailed methods or practices. Starting to learn the essentials gets teams ready to start working significantly earlier than if they first have to learn “all” there is to say about the subject.

These essentials are usually just a small fraction of what an expert knows about a subject—we suggest 5%—but with the essentials you can participate in conversations about your work without having all the details. It helps to grow T-shaped people—people who have expertise in a particular field, but also broad knowledge across other fields. Such people are what the industry needs as work becomes more multi-disciplinary. Once you have learned the essentials it is relatively straightforward to find out more by yourself from different sources.

Some teams and organizations need more than the essentials, so different levels of details must be made optional.

3.5 Providing an Engaging User Experience

Many books have been written to teach software engineering. Some people interested in learning about ideas and trends in this space read these books, but the vast majority of software development practitioners don’t—not even if they have bought the books. Thus, textbooks are not the best way to teach practices to practitioners. Modern method-authors have taken a different approach by presenting their methods as a navigable website.

Essence has taken a different approach by providing a hands-on, tangible user experience focused on supporting software professionals as they carry out their work. For example, the kernel can be accessed (and actually touched) through the use of cards (see Figure 3.5). The cards provide concise reminders and cues for team members as they go about their daily tasks. By providing practical check-lists and prompts, as opposed to conceptual discussions, the kernel becomes something the team uses on a daily basis. This is a fundamental difference from traditional approaches, which tend to emphasize method description over method use and tend to be consulted only by people new to the team.

Figure 3.5 Cards make the kernel and practices tangible.

Cards have proven to be a lightweight and practical way to remember, but also to use in practice in a team. They make the kernel and the practices easy to digest and use. For this reason, throughout the book we will use cards to present elements in the kernel and in practices.

What Should You Now Be Able to Accomplish?

After studying this chapter, you should be able to

• name the key elements of Essence;

• distinguish between a practice and a method (give some examples of both);

• explain the concept of composition as a key technique to build methods using practices (and to support extensibility in Essence);

• explain the concept of tacit vs. explicit practices;

• explain the role of capability and background in deciding how explicit a practice should be; and

• explain the layered architecture of Essence and its elements.

Again, we point to additional reading, exercises, and further material at www.software-engineering-essentialized.com.

Given that the reader is now equipped with ability to distinguish essential (i.e., the important) steps/aspects/decisions from those of minor importance, more knowledge can now be gained by proceeding in a given project and by working on the project with other people/stakeholders involved.