12 methods of XP

12 methods of XP

The twelve methods (2) of XP define them as rules. Let's take a closer look at each method to have a more comprehensive understanding of what "execute XP" means.

1) Planning Strategy
Some may accuse XP of being a kind of well-known plagiarism, but a group of cowboy pieces a system together without any rules. Error. XP is one of the few ways to acknowledge that you are not familiar with everything at the beginning. Both users and developers gradually understand things as the project progresses. Only an effective approach is to encourage and trust such changes. The status restriction method ignores the changes. XP is concerned with changes. The method it uses to listen to is "Planning Strategy", a concept created by Kent Beck.

The main idea behind this method is to quickly develop a rough plan and then gradually improve as things become clearer. The product of the planning strategy includes a bunch of index cards, each containing a customer clip, which drives the iteration of the project and a rough plan for the next release, as Kent Beck and Martin Fowler described in their planning eXtreme Programming (see references ). The key factor that can make this form of plan play a role is to allow users to make enterprise decisions and let the development team make technical decisions. Without this premise, the entire process would collapse.

The development team should decide: estimate how long it takes to develop a material, the cost of using various technical options, the "risks" of the team, and the sequence of material development in iteration (the most risky first Development) that can reduce the risk ).
The customer needs to determine the scope (the material of a release and the material of each iteration), release date, and priority (which features are developed based on the enterprise value. In this way, customers or developers can learn new things while giving them frequent opportunities to adjust their plans.

2) paired Programming
Use XP to write all product code for paired developers. This method seems to be inefficient. Martin Fowler said, "When people say that programming is less productive, I replied, 'that's because most of the time-consuming programming is done by input. '"In fact, Pair programming provides many benefits in both economic and other aspects: all design decisions involve at least two people, at least two people familiar with each part of the system, and almost impossible for two people to conduct tests or other tasks at the same time, changing the combinations of various pairs within the team. propagation knowledge and code are always reviewed by at least one person.

Studies also show that paired programming is actually more effective than individual programming (for more information, see the costs and benefits of Pair programming by Alistair Cockburn and Laurie Williams in reference ).

3) test
There are two types of tests in XP: unit test and acceptance test.

Developers write unit tests while writing code. The customer writes the acceptance test after they define the material. The unit test promptly informs developers whether the system is "working" at a certain point ". The acceptance test tells the Team whether the system executes the operations that the user wants to perform.

Assuming that the team uses an object-oriented language such as Java, developers write unit tests for each method that may fail before writing code for some methods. Then they write enough code to pass the test. Sometimes people may find this strange. The answer is simple. Writing a test first provides you with a clear picture of a set of potentially complete tests, the simplest code that may work, and the code intent.

Developers can check the code into the source code library only after passing all unit tests. Unit testing gives developers confidence that their code can work. This leaves other developers with clues to help them understand the intent of the earliest developers (in fact, this is the best document we have ever seen ). The unit test also gives developers the courage to re-divide the code, because the test fails and developers can be immediately notified of an error. Unit tests should be automated and clear passing/failure results should be provided. The xunit framework (see references) does more than that, so most XP teams use them.

The user is responsible for ensuring that each clip has an acceptance test to confirm them. Users can write tests by themselves, recruit other members in the organization (such as QA personnel or business analysts) to write them, or combine these two methods. Test to tell them whether the system has the features they should have and whether they can work correctly. Ideally, you should write the acceptance test of those materials in the iteration before completing the iteration. The acceptance test should be automated and should be run frequently to ensure that developers do not destroy any existing features when implementing new features. Generally, the customer needs some help from the development team to compile the acceptance test. We develop a reusable automatic acceptance test framework for a project, allowing users to enter their input and expected output in a simple editor. The framework converts the input to an XML file and a test in the running file, and then displays "pass" or "fail" for each test ". Customers like this practice.

Not all acceptance tests must pass in all circumstances. The problem is how the acceptance test helps the customer determine the project completion. They also enable customers to determine whether something can be released.

4) re-Division
Re-division is to improve the code without changing the functionality. The XP team did not have a hand in Division.

There are two important opportunities for developers to redivide features: before and after implementation. Developers try to determine whether changing existing code can make new feature development easier. They checked the code they just wrote to see if there is any way to simplify it. For example, if they think there is an opportunity to abstract the code, they will re-divide it to remove repeated code from the specific implementation.

XP suggests that you write the simplest code that may run, but we also recommend that you keep learning. Re-Division allows you to add the learned knowledge to the code without damaging the test. It makes your code concise. This means that it can take a long time to introduce fewer problems to future developers and guide them in the right direction.

5) Simple Design
XP detractors say the process ignores the design. This is not the case. The problem is that we recommend that you complete most of the trivial design tasks in advance. This is like taking a picture of the static horizon, standing still, and then trying to draw a perfect map of how to get there. XP says the design should not be rushed before things will remain unchanged. XP believes that design is very important, so it should be a continuous transaction. We always try to use the simplest design that can work first, and then change it as the reality emerges.

What is the simplest design that may work? It is designed to meet the following criteria (thanks to Kent Beck for listing them one by one ): run all tests, do not contain repeated code, clearly state the programmer's intention to all code, including the minimum possible classes and methods.

The need for a simple design does not mean that all designs are small or insignificant. They only need to be as simple as possible, but still work. Do not include unused additional features. We call this thing yagni, which means "you don't need it (you aren't going to need it )." Do not let yagni destroy your chances of success.

6) aggregate code ownership
Anyone in the group should have the right to change the code to improve it. Everyone has all the code, which means everyone is responsible for it. This technology allows people to make necessary changes to some code without passing through the personal bottleneck of the code owner. Everyone is responsible for this fact to eliminate the chaos caused by no code ownership.

The statement "everyone owns all the code" is not the same as that of "no one owns the code. When no one owns the code, people can destroy it everywhere without taking any responsibility. XP said, "If it is your fault, you should make up for it ." We have some unit tests that must be run before and after each integration. If you break something, you are responsible for fixing it, no matter which part of the code it is located. This requires extreme rules. This may be another reason for the name being "extreme.

7) continuous integration
Frequent code integration helps you avoid integration nightmare. The XP team integrated the code several times a day and executed it after all unit tests run on the system.

The traditional method works as follows: Write a large amount of code, execute a Big Bang integration, and then spend a considerable amount of time to correct the problem. This clumsy form indeed slows down the speed of the project. Big-bang integration immediately brings a lot of problems to the team, and these problems are usually caused by hundreds of possible causes. If integration is performed frequently, the cause of any specific integration failure will be very obvious (tests have been run before, so errors must be made in new things ). When this method is used, the possible causes are quite limited. It is easier to modify and takes less time to keep the team moving forward as quickly as possible.

8) on-site customers
To achieve the most ideal functionality, the XP team needs a customer at the site to clarify the material and make important enterprise decisions. Developers are not allowed to do these tasks independently. Allowing customers to be present at any time can eliminate the bottlenecks that developers encounter when waiting for decision-making.

XP does not pretend that the clip card is the only indication required by developers to deliver the required code. Material is a commitment to fill in details between customers and developers in the future. Unlike writing all requirements in a static document, the idea is to communicate face-to-face to reduce the chance of misunderstanding.

We found that it could be the best scenario for customers to be on site, but this is not the only solution to the problem. The bottom line is that the customer must be free at any time to answer questions and provide instructions to the team based on enterprise value. It would be nice if the customer could do this without working with the team on site. It is more convenient to stay with the team, but it is just a suggestion.

9) Small release
Release versions should be as small as possible, while still providing enough enterprise value to prove their worth.

You can publish the system if you think it makes sense. In this way, we can provide users with value as early as possible (remember that today's money is worth more than tomorrow's money ). The minor release will provide developers with specific feedback on what meets the customer's needs and what does not meet the customer's needs. The Group can then include these lessons in the planning of the next release.

10) 40 hours a week
Kent Beck said he hopes that "... every morning, I feel energetic and passionate, and every night I feel exhausted and satisfied ." You can do this if you work 40 hours a week. The exact number of hours is not important. What is important is the principle. A long period of continuous work will result in killing performance. Fatigue developers may make more mistakes. In the long term, the development process will be much slower than the "normal" schedule.

Even if developers can work well for a long time, that doesn't mean they should. In the end, they will get bored, leave their jobs, or have non-work problems that affect their job performance. If you disrupt people's lives, you will taste the consequences. Working overtime is not the answer to the project's problem. In fact, it is a symptom of a bigger problem. If you want to perish, no medicine can be saved.

11) coding standards
There are two purposes to have coding standards: a. Prevent teams from getting overwhelmed by silly arguments such as things are not developing at the maximum speed; B. It supports other methods.

Without coding standards, code re-division will be more difficult. It is more difficult to switch to the appropriate frequency, and it is more difficult to move forward quickly. The goal should be that no one in the team identifies who wrote the code. Reach an agreement on a standard by team and then follow this standard. The goal is not to create a list of rules, but to provide guidelines that will ensure that your code can communicate clearly. Coding standards should be simple at the beginning, and then gradually evolve based on team experience. Do not spend too much time in advance. Create the simplest standards that can work, and then gradually develop.

12) system analogy
What is architecture used? It provides various system components and how they interact-A ing that allows developers to understand where new code is suitable.

The system metaphor in XP is similar to the architecture called by most methods. The analogy provides a consistent picture of the Team, which they can use to describe how the existing system works, where new components fit, and how they should take.

It is important to remember that the key is to let everyone understand how the system is combined, rather than a beautiful metaphor. Sometimes you cannot think of a good analogy. That would be great.