Agile Software Development: principles, patterns and practices--the 2nd Chapter Overview of Extreme Programming

Chapter 2nd Overview of Extreme Programming

As a developer, we should remember that XP is not the only option. --pete McBreen, software technology expert

In the 1th chapter, we outline the content of the Agile software development approach, but it does not tell us exactly what to do; it gives some general statements and goals, but does not give practical guidance. This chapter will change this situation.

2.1 Extreme Programming practices

2.1.1 Complete Team

We want customers, managers, and developers to work closely together to get to know each other's problems and solve them together. Who is the customer? Customers in the XP team are the people or groups that define the characteristics of the product and prioritize those attributes. In some cases, a customer is a group of business analysts, quality assurance experts, and/or market experts who are part of the same company as the developer. Sometimes, a customer is a user delegate that is delegated by the user community. Sometimes the customer is actually the person who pays the development fee. But in the XP project, no matter who is the customer, they are team members who can work with the team.

The best case scenario is that the customer and the developer work in the same room, and the next point is that the customer and the developer work within 100m. The greater the distance, the more difficult it is for the customer to become a true team member. If a customer is working in another building or another state, it will be difficult for him to integrate into the team.

What if you really can't work with the customer? My advice is to find someone who can work together, be willing, and be able to replace a real customer.


2.1.2 User Stories

In order to plan for a project, you need to understand the requirements, but don't need to know too much. For planning purposes, it is sufficient to understand the requirements only to the extent that they can be estimated. You might think that in order to estimate requirements, you have to understand all the details of that requirement. Not really. You have to know that there are a lot of details, and you have to know the general classification of the details, but you don't have to know the specific details.

The specifics of the requirements are likely to change over time, even more so once customers begin to see systems that are integrated together. Seeing the advent of new systems is the best time to focus on demand. Therefore, do not capture specific details of a requirement that will be fulfilled over a long period of time, or it is likely to lead to a failure of effort and an immature focus on demand.

In XP, we talked to our clients over and over again to get an understanding of the details of the requirements, but not to record the details. We prefer the client to write some common words on the index cards that remind us to remember this conversation. Basically at the same moment when the customer is writing, the developer writes the estimate on the card that corresponds to the demand on the card. Estimates are based on an understanding of the details obtained during a conversation with the customer.

The user story is a mnemonic of the ongoing conversation about demand. It is a planning tool that customers can use and schedule the time to implement that requirement based on the priority and estimated cost of the requirement.

2.1.3 Short Delivery cycle

XP projects deliver work-ready software every two weeks. Each of the two-week iterations implements a number of stakeholder needs. At the end of each iteration, the stakeholders are presented with iterations of the generated system to get their feedback.

Iteration Plan

Each iteration typically takes two weeks. Iterations are a small delivery that may or may not be added to the product. An iteration plan consists of a set of user stories that are selected by the customer based on a budget determined by the developer.

The developer sets a budget for this iteration by measuring the amount of work done in previous iterations. As long as the total estimated cost does not exceed the budget, customers can select any number of user stories for this iteration.

Once the iteration begins, the customer agrees not to modify the definition and priority level of the user story in the iteration。 During iterations, developers are free to break down user stories into tasks and develop these tasks in the most technical and commercially meaningful order.

Release plan

The XP team typically creates a release plan to plan the content for the next approximately 6 iterations. This is called a release plan. A single release usually takes 3 months to work. It represents a larger delivery, which is usually added to the product. A release plan is comprised of a set of user stories that the customer chooses to prioritize based on the budget that the developer gives.

The developer sets a budget for this release by measuring the amount of work done in previous releases. As long as the total estimated cost does not exceed the budget, customers can select any number of user stories for this release. Customers can also determine the order in which user stories are implemented in this release. If the development team is strongly required, the customer can work out the first few iterations of the release by indicating which user stories should be completed in which iteration.

The release plan is not immutable. Customers can change the content of the publication at any time. He can cancel user stories, write new user stories, or change the priority level of user stories. However, customers should try not to change the iteration.

2.1.4 Acceptance Test

You can record details about a user story in the form of a customer-specified acceptance test. The acceptance test for a user story begins before the user story is realized, or when the user story is implemented. Acceptance tests are written in scripting languages so that they run automatically and repeatedly. These tests work together to verify that the system operates according to customer-specified behavior.

Acceptance testing is written by business analysts, quality assurance experts, and testers during the iteration. The language used to write acceptance tests is easy for programmers, customers, and business people to read and understand. Programmers learn the real-world details of the stories they are implementing from these tests. These tests become real project requirements documentation. The acceptance test describes all the details of each feature and serves as a conclusive basis for verifying that these features have been properly completed.

Once an acceptance test is passed, the test is added to the acceptance test collection that has passed, and the test is never allowed to fail again. This growing collection of acceptance tests runs several times a day and runs this acceptance test set whenever the system is created. If an acceptance test fails, the system creation fails. Thus, once a requirement is fulfilled, it is no longer compromised. When a system migrates from one working state to another, during which time the system cannot work for more than a few hours.

2.1.5 Pair Programming

The code is done together by a pair of programmers using the same workstation. Pair of people, one control keyboard and enter code. The other looked at the input code, looking for errors in the code and where to improve. Two of people engage in serious interactions. They all threw themselves into the writing of the software.

Two people swap roles frequently. Control of the keyboard may be tired or difficult, his companion will gain control of the keyboard. Within one hours, the keyboard may be passed back and forth several times between them. The resulting code was designed and co-authored by both of them, and the two were equally meritorious.

The relationship between pairs should be changed frequently. Change at least once a day so that each programmer can work on two different pairs in a single day. During an iteration, each team member should work with all other team members, and they should be involved in each of the work involved in this iteration.

Pair programming greatly facilitates the dissemination of knowledge in the team. There is still a need for expertise, and tasks that require a certain amount of expertise often require the right experts to do it, but those experts will almost certainly be aligned with all the others on the team. This will accelerate the spread of expertise across the team. That way, at a critical juncture, other team members will be able to replace the required experts. Research by Williams and Nosek shows that, instead of reducing the efficiency of programmers, the pair will significantly reduce the defect rate.

2.1.6 Test-driven development

The 4th chapter will discuss this topic in detail. Here, we only make a general introduction.

All product codes are written for the purpose of allowing failed unit tests to pass. Write a unit test first, and it will fail because the feature it is testing does not yet exist. Then, write the code to make the test pass.

The speed of change between writing test cases and code is fast, basically in minutes or so. Test cases and code evolve together, where the test cases guide the writing of the Code incrementally (see the example in Chapter 6th).

As a result, a very complete set of test cases is developed along with the code. Programmers can use these tests to check whether the program works correctly. If the pairing programmer makes minor changes to the code, they can run tests to ensure that the changes do not cause any damage to the program. This can be very useful for refactoring (described later in this chapter).

When you write code to make a test case pass, the code you write is inherently testable. More importantly, doing so will strongly motivate you to decouple the modules so that they can be tested independently of each other. Thus, the design of code written in this way tends to have weaker coupling. The principle of object-oriented design is of great help in this decoupling (see Part Two of this book).


2.1.7 Collective

Each pair of programmers has the power to check out any module and improve it. Each programmer is not solely responsible for any particular module or technology. Everyone participates in the work of the GUI, everyone is involved in the work of the middleware, everyone participates in the database work. No one has more authority than others in a module or technology.

This does not mean that XP does not require expertise. If your area of expertise is about the GUI, you are most likely to be working on GUI tasks, but you will also be invited to work on middleware and database tasks with others. If you decide to learn another professional knowledge, you can take on the relevant tasks and work with experts who can impart your knowledge. You will not be confined to your area of specialization.

2.1.8 Continuous Integration

Programmers check in and integrate their code multiple times a day. The rule is simple: the first check-in is done as soon as the check-in is complete, and all the people who check in later are responsible for the merge of the code.

The XP team uses non-blocking source control tools. This means that programmers can check out any module at any time, regardless of whether someone else has already checked out the module. When the programmer finishes modifying the module and checks it in, he must merge any changes he made with the programmer who checked in with the module before him. To avoid merging for too long, members of the team check their modules very frequently.

A pair of people will work on a task for one to two hours. They create test cases and product codes. At an appropriate interval, perhaps long before the task was completed, they decided to check the code back in. They first ensure that all tests are passed, and then integrate the new code into the current code base. If needed, they will merge the code. If necessary, they will negotiate with other programmers who are in conflict with the check-in. Once they are integrated into their changes, they build a new system. They run every test in the system, including all currently valid acceptance tests. If they destroy the part that they can work on, they will fix it. Once all the tests were passed, they completed the check-in process.

As a result, the XP team makes multiple system builds every day. They will create the entire system from scratch. If the final result of the system is a CD, they burn the CD. If the final result of the system is a Web site that can be accessed, they install the Web site and may install it on a test server.

2.1.9 Sustainable development speed

Software project is not a full-speed dash, it is a marathon running. Those teams that jump off the starting line will be exhausted before they get far away from the finish line. To get the development done quickly, the team must move at a sustainable pace. The team must maintain a strong energy and a keen vigilance. The team must consciously maintain a steady, moderate speed.

XP rules do not allow teams to work overtime. The one week before the release is the only exception to the rule. If the release target is in sight and can be accomplished overnight, overtime is allowed.

2.1.10 Open Work space

The team works together in an open room. There are some tables in the room. Two or three workstations were placed on each table. There are two chairs in front of each work station. The walls are filled with status charts, task schedules, UML diagrams, and so on.

The room was full of chatter, and the pair of pairs of programmers sat in the distance they could hear each other, and everyone could tell if the other was in trouble, everyone knew the other person's work, and the programmers were in a position that was appropriate for a heated discussion.

Some people may think that this kind of environment can distract people's attention. It's easy to worry about getting nowhere because of constant noise and interference. In fact, that is not true. Moreover, a study by the University of Michigan suggests that, in a "room full of active discussion", productivity will not decrease but multiply exponentially.

2.1.11 Planning Game


In the 3rd chapter, the XP plan game is described in detail. Here, just a brief introduction.

The essence of Planning games (planning game) is to divide the responsibilities between business and development. The business person (i.e. the customer) determines the importance of the feature, and the developer determines the cost of implementing a feature.

At the start of each release and iteration, the developer provides a budget to the customer. The customer chooses those cost totals that are less than the user story equal to the budget. The budget provided by the developer is based on the amount of work they have done in the last iteration or release.

Based on these simple rules, with short cycle iterations and frequent releases, customers and developers will soon adapt to the development rhythm of the project. Customers will understand the developer's development speed. Based on this understanding, customers can determine how long the project will last and how much it will cost.

2.1.12 Simple Design

The XP team makes their designs as simple and expressive as possible. In addition, they focus only on the user stories that are planned to be completed in this iteration, regardless of the future user stories. The team is more willing to constantly change the design of the system over and over again, so that it remains optimal for the user stories that are being implemented.

This means that the work of the XP team may not start with the infrastructure. Instead of choosing a database or middleware, they first implement the first batch of user stories in the simplest possible way. This infrastructure is only introduced when a user story is in dire need of infrastructure.

The following 3 XP guidelines (Mantra) can guide the developer.

(1) Consider the simplest thing that can work. XP teams always try to find the simplest design that will enable the current user story. In implementing the current user story, if you can use a flat file, you do not use the database, if you can use a simple socket connection, you do not use the Orb or Web Service, if you can not use multi-threading, do not use it. We try to think of the simplest way to implement the current user story. Then, choose a solution that we can actually get the closest to that simplicity.

(2) You don't need it. Yes, but we know that someday we'll need a database, we'll need the orb, and someday we'll have to support multiple users. So, we need to get ready for those things right now, don't we?

What happens if you refuse to introduce the infrastructure before you really need it? The XP team will take this seriously. They began by assuming that the infrastructure would not be needed. The team will only introduce these infrastructures if there is evidence, or at least there is a very clear indication that the infrastructure is now more cost-effective to introduce them than to continue waiting.

(3) Once, and only once. The extreme programmer cannot tolerate duplicate code. No matter where the duplicated code is found, they will eliminate these duplicates.

There are many factors that lead to code duplication. The most obvious thing is to select a piece of code with the mouse and paste it around. When the duplicated code is found, we eliminate them by creating a function or a base class method. Sometimes two or more algorithms are very similar, but there are subtle differences between them, and we'll turn them into functions, or use the template method pattern (see Chapter 22nd). No matter where the duplicated code originates, it must be eliminated once it is discovered.

The best way to eliminate repetition is to be abstract. After all, if two things are similar, there must be some kind of abstraction that can unify them. Thus, eliminating repetitive behavior forces the team to distill many abstractions and further reduce the coupling between the code.

2.1.13 re-construction

The 5th chapter will discuss the refactoring in detail, the following is just a simple introduction.

Code tends to be corrupt. As we add one after another to deal with one error after another, the structure of the code is gradually degraded. If you ignore this, this degradation will eventually lead to confusing and difficult-to-maintain code of confusion.

The XP team reverses this degradation with regular code refactoring. Refactoring is a series of small modifications to improve the practical activities of the system structure without changing the behavior of the code. Every transformation is trivial and hardly worth doing. But all of these modifications are stacked together, resulting in significant improvements in system design and architecture.

After every minor retrofit, we run unit tests to make sure that the retrofit doesn't cause any damage, and then the next makeover. So round and round. In this way, we can change the system design while maintaining the system can work.

Refactoring is ongoing, not at the end of the project, at the time of release, at the end of the iteration, or even every day when it's almost time to work. Refactoring is something we're going to do every one hours or half an hour. By refactoring, we can keep the code as clean, simple and expressive as possible.

2.1.14 Metaphor

Metaphor (metaphor) is the only non-specific, non-straightforward XP practice and one of the hardest to understand in all XP practices. The extreme programmer is essentially a pragmatist, and the lack of a concrete definition of metaphor makes us feel uncomfortable. Indeed, some XP supporters often discuss the removal of metaphors from XP practice. In a sense, however, metaphor is one of the most important practices in all XP practices.

Imagine a jigsaw puzzle toy. How do you know how to put all the pieces together? Obviously, each piece is adjacent to the other block, and its shape must fit perfectly with the adjacent block. If your eyes are invisible but have a good sense of touch, then by consistently sifting through each small piece and constantly trying their place, you can also spell the entire graph.

However, there is a more powerful force to assemble these complex pieces together relative to the shape of each small block. This is the pattern of the whole puzzle. The pattern is the true guide. Its power is so great that if the next two blocks in the pattern do not have a matching shape, then you can conclude that the creator of the puzzle toy made the toy wrong.

This is metaphor. It is a global view that ties the entire system together. It is the vision of the system and it makes the position and appearance of all individual modules visible and intuitive. If the appearance of the module does not match the metaphor of the whole system, then you know that the module is wrong.

Metaphors can often be attributed to a name system. These names provide a glossary of system elements and help define the relationships between them.

For example, I have developed a system that outputs text to the screen at a speed of 60 characters per second. At such a speed, the character fills the screen for a period of time. So we let the text-generating program put the resulting text into a buffer. When the buffer is full, we swap the program to disk. When the buffer is about to become empty, we swap the program back and let it run.

We use loading and unloading trucks to haul rubbish to metaphor the whole system. The buffer is a small truck. The screen is a junkyard. Programs are garbage makers. All the names fit together, which helps us to think about the system as a whole.

For another example, I have developed a system that analyzes network traffic. Every 30 minutes, the system polls dozens of network adapters and obtains monitoring data from them. Each network adapter provides us with a small piece of data that consists of several separate variables. We call these data blocks "slices of bread". These slices of bread are the raw data to be analyzed. The analysis program "bakes" these slices and is thus referred to as "toasters". We refer to the individual variables in the data block as "breadcrumbs". In short, it is a useful and interesting metaphor.

Of course, metaphor is more than just a name system. Metaphor is the vision of a system that guides all developers in choosing the right name, putting the function in the right place, creating new and appropriate classes and methods, and so on.

2.2 Conclusion

Extreme programming is a set of simple, concrete practices that combine to form an agile development process. Extreme programming is a kind of good and common software development method. For most project teams, you can use it directly, add some practice, or modify some of these practices before you use them.

Excerpt from: "Agile Software Development: principles, patterns and Practices (C # Edition)" Robert C.martin Micah Martin

Agile Software Development: principles, patterns and practices--the 2nd Chapter Overview of Extreme Programming