Using XP methods to make software projects to get more successful original: ROY W. MILLER, Christopher T. Collins Adaptation: Xuyeli (Reprinted from Software Engineering Expert Network Www.21cmm.com) Using object-oriented programming is unprecedented. It makes software development a certain degree of change, but recent research shows that there are half of the software development projects lag, and one-third of the project exceeds budget. The problem is not in technology, but the method used by the development of software. The so-called "lightweight" or "flexible" mode provides a very interesting solution with the power and flexibility of object-oriented language. The most common flexibility is called extreme programming or XP, but many people don't really understand it. Using XP for software projects can greatly increase successful opportunities. This article provides an overview of XP and explains why it is very important - not a rumor, no scam. In the past decade, CEOs face huge pressure in terms of steady income. They solve this problem by taking a series of initiatives in many ways, such as reduced the company's scale, outsourcing, re-engineering, corporate resource planning (ERP) and so on. These for low-efficiency solutions allow many companies in S & P 500 to maintain two-digit revenue growth in the end of the 1990s. But this way also brings some negative impact. In the book of Leading The Revolution (see Resources) in Gary Hamel, he claims that there are some signs that the advantages of traditional enterprise models are not so obvious. We must find some alternatives to power the continued growth of income. He suggested that the only way to continue to grow will be a thorough innovation. We believe that this is especially true in the field of software development. Enterprise issues If you use standard software development methods, even if you develop it on a common platform, you must prepare for disappointment. As shown in Figure 1, recent research shows that half of the project will lag, and one-third of the project will exceed the budget. This speculation is not much better than the research results of the US Total Affairs Bureau in 1979. Figure 1. Successful and failure of software projects, in the past and now we hope that these numbers have significantly improved, requiring thorough innovation methods to develop software. There are two main factors that affect existing methods: fear failure, misunderstanding of software in nature. No one is intended to fail. Ironically, the method created to minimize failure is failed. Misunderstanding for software is the root of the problem. Fear is actually just a symptom. The existing approach is created by those smart people who have a good wish but forget the "soft" in the software. They assume that the development software is like a bridge. Therefore, they learn from various design specifications for optimal methods suitable for "hard" objects (such as bridges). The result is based on Big Design Up-Front (BDUF) ideology, the development method of slowing, the software is unbearable, and people cannot use them.
"XP specifies a set of core values and methods, allowing software developers to play their expertise: write code. XP eliminates the unnecessary product of most weight-based processes, by slowing the development speed, cost development personnel (for example Danteap, status report, and multi-volume demand documentation) deviate from the target. We realize that something called "extreme programming" may be difficult as a formal development process recommended to management, but if your company is engaged in the software industry You should help management bypass its name to recognize the competitive advantage that XP can provide. Kent Beck summarizes the core value of XP in the EXTreme Programming Explained: Embrace Change book (see Resources). We have Summary: 1) The issue of communication projects can often be traced back to someone on a certain moment, there is no significant problem with others. Use XP, no communication is impossible. 2) Simple XP suggest you always It is the easiest thing to do with the process and write code. According to BECK, "XP is bet. It is better to do something simple today ... not more complicated but may never use. "3) Feedback earlier and frequent feedback from customers, teams, and actual end users to provide you with more opportunities to adjust your strength. Feedback allows you to grasp the right direction, take less detours. 4) courage Courage exists in the other three values. They support each other. It is necessary to believe that the specific feedback on all the way is better than pre-knowing each matter. It is necessary to expose your ignorance. The courage is required to make the system as simple as possible, and will push it tomorrow to do it tomorrow. If there is no simple system, there is no constant exchange to expand knowledge, there is no feedback on the direction, and the courage is lost. XP Methods These values will be converted into developers to do every day. There is no fresh content. In the past few years, the industry has realized that the XP method is "optimal approach". In fact, "extreme" from XP comes from two aspects: XP takes through The proven industry is optimal. The XP combines these methods in some way so that the results they produce greater than the sum of each part. What is the scene? The code review is a good practice, so It is always written by pairing code. Test is also a good practice, so it is always done by writing tests before writing code. Document is rarely consistent with the code, so only those things most, rest The part depends on the clearly written code and test. XP does not guarantee that people do the right thing, but it allows people to do so. It combines these "extreme" methods in a mutually supported manner, significantly improved speed And effectiveness. <2> XP twelve methods XP's twelve methods (shown in Figure 2) defined them as rules. Let's take a closer study every method for "execution XP" what is more Comprehensive understanding. Figure 2. Twelve methods of XP 1) Planning strategies Some people will accuse XP is a plagiarite of a beautiful name, just a group of cowboy to put a system together without any rules. Wrong. XP is one of several ways to admit that you can't do things in the start of doing things. Whether users or developers are gradually understanding things with the progress of the project. Only encourage and believe this change The method is an effective method. Status limiting method ignores changes. The XP pays attention to changes. It is listening to the method to "planning the strategy", a concept created by Kent Beck. This method is rapidly formulating Plan, then gradually improve with the continuous clarity of things.
The product of planning strategy includes: a bunch of index cards, each contains a customer material, iteration of these material driver projects; and a rough plan for the next one or two issues, such as Kent Beck and Martin Fowler in their Planning Extreme PROGRAMMING is described (see Resources). Key factors that make this form of programs work are to let users do business decisions, let the development team do technical decisions. If there is no premise, the whole process will land. The development team should decide: It is estimated that it takes a material to develop a material, using various technical options, team organization, "risk" of each material, iterative in the order of material development (the biggest risk first You can alleviate the risk). Customers need to decide: Scope (a distribution material and every iterative material), the date of issuance, priority (developing which characteristics developed first according to corporate value) planning often occurs. In this way, while customers or developers learn new things, they provide frequent opportunities for their adjustment plan. 2) Passing the programming using XP, the paired developers write all product code. This way is listened to the lack of efficiency. Martin Fowler said, "When people say that the programming reduces productivity, I will answer, 'that is because most of the time-consuming programming part is completed by input.'" In fact, the pair programming is in the economy or other aspect It provides many benefits: All design decisions involve at least two people, at least two people are familiar with each part of the system, almost impossible to have two people to neglect test or other tasks, changing the combination of each pair can be in the team Propagation knowledge, code is always reviewed by at least one person. Studies also show that pair programming is actually more efficient than individual programming (for more information, see the Costs and Benefits of Pair Programming in Alistair Cockburn and Laurie Williams). 3) There are two tests in XP: unit test, acceptance test. Developers write unit tests while writing code. Customers write acceptance tests after they define materials. The unit test promptly tells the developer system "work" at a certain point. The acceptance test tells the team system whether or not the user wants the operation you want to perform. Suppose the team uses an object-oriented language such as Java, and developers write unit tests for each possible failed method before writing code for some ways. Then they write enough code to make it test. Sometimes people will find that this is a bit strange. The answer is simple. Write tests First provide you with: a group of possible most complete tests, the simplest code that may work, the codeworthry of the code intent. Developers can only check the code into the source code repository after testing through all units. The unit test makes the developer confident that their code can work. This leaves a clue for other developers, which can help them understand the earliest developers (actually, this is the best document we have seen). The unit test also gives the developer courage to re-divide the code, because the test failure can tell the developer's error. The unit should be automated and provide a clear pass / failed result. The XUnit framework (see Referring) is far more than these, so most XP teams use them. The user is responsible for ensuring that each material has an acceptance test to confirm them. Users can write tests themselves to recrue other members of the organization (such as QA personnel or business analysts) to write them, or combine these two methods. Tests tells them whether the system has the characteristics that should have, and whether it can work correctly. Ideally, the user should write the acceptance test of those materials in iterations before iteration is completed.
The acceptance test should be automated and to ensure that the developer does not destroy any existing features when the new feature is realized. Normally, customers need certain help from the development team to write an acceptance test. We develop a reusable automatic acceptance test framework for a project, allowing users to enter their input and desired output in a simple editor. The frame will convert the input into XML files, run the test in the file, and then "pass" or "failed" for each test. Customers like this practice. Not all acceptance tests must pass in all situations. The problem is that the acceptance test helps the customer measures the "completion" of the project. They can also make customers informed that certain things can be issued. 4) Re-dividing the re-division is to improve the code without changing the functionality. The XP team is not soft when it is re-divided. Developers have two important opportunities: Before and after realization. Developers try to determine if the existing code can make new features easier. They check the code just written, see if there is a way to simplify it. For example, if they think there is an abstract opportunity, re-dividing the repetition code from the specific implementation. XP recommends that you should write the simplest code that may run, but it is also recommended that you should continue to learn. Resets let you join the knowledge to the code and will not damage the test. It makes your code simply. This means that it can exist for a long time, introducing less problems for future developers and guiding the correct direction for them. 5) Simple design XP's calibration says that the process is ignored. This is not the case. The problem is that the weight-based method recommends that you do it in advance to complete most of the trivial design tasks. This is like a photo of a static horizon, still keeps moving, then try to draw a perfect map to get there. XP says that design should not be held in advance under the premise that things will remain unchanged. XP believes that the design is very important, so it should be a continuous transaction. We always try to use the easiest designs that work, and then change it with reality. What is the simplest design that is possible? It is a design that meets the following conditions (thanks to Kent Beck to list one by one): Run all tests, do not include duplicate code, clearly state the programmer's intentions for all code, include minimal class and methods as possible. The need for simple design is not to say that all designs are small, nor does it mean that they are insignificant. They only need to be as simple as possible, but still work. Do not include additional characteristics that are not used. We call like YAGNI, indicating that "You will don't need it (You Aren't going to need it)." Don't let YAGNI destroy your successful opportunity. 6) Anyone in the Collective Code Operating Group should have the right to change the code to improve it. Everyone has all code, which means everyone is responsible for it. This technique allows people to make the necessary changes to some code without having to pass the personal bottleneck of the code owner. Everyone is responsible for this fact that eliminates the chaos brought by no code ownership. "Everyone has all the code" and the "no one has code" and is different. When no one has code, people can destroy everywhere without having to lose any responsibility. And XP said, "If you are destroyed, you should make up." We have some unit tests that must be run before and after each integration. If you destroy certain things, you have to be responsible for patching, whether it is part of the code. This requires extreme rules. It may be another reason for "extreme" in the name. 7) Sustained integration often code integration can help you avoid integrated dreams. The XP team integrates a code several times a day, and each time all unit tests are executed after running the system. The traditional method works as follows: After writing a large number of code, perform a large explosive integration, then spend a considerable time to change the problem. This clumsy form does slow down the project speed. Big bang integration brings a lot of problems to the team, and these problems usually have hundreds of possible reasons.
If integrated frequently, any specific integration failure will be very obvious (previously running test, therefore the error must be made by new things). Using this method, when you encounter problems, possible reasons are quite limited. It is easier to modify, and the time is much less, so that the team maintains the fastest movement. 8) On-site customers should make functions, XP groups need to have a customer to clarify the material and make important business decisions. Developers are not allowed to do these things alone. Let customers have the bottleneck that will be able to eliminate the developer waiting for decision-making. XP does not pretend that the material card is the only indication required for developers to deliver the necessary code. The material is a commitment to fill in the details between customers and developers. Unlike all requirements in a static document, its idea is to face face-to-face communication and reduce opportunities for misunderstanding. We have found that it is the best way to make customers in the scene, but this is not the only solution to solve the problem. The bottom line is that customers must answer questions at any time and provide instructions to provide instructions based on corporate value. If the customer does not do this if the customer is in the field of full-time companion team, it is good. This will be more convenient if you can stay with the team, but it's just a suggestion. 9) The small distribution issued should be as small as possible, while still offering sufficient business value to prove they worth it. As long as you feel meaningful, you can release the system. This will provide users with value as much as possible (please remember, today's money is worth money than tomorrow). The small distribution will provide developers with specific feedback, telling them which meet the customer needs, which does not meet customer needs. The Group can then include these lessons include in its next release. 10) 40 hours a week, Kent Beck, said he hopes "... Every morning, there is a passion every morning, and it is tired every night." Working for 40 hours a week can make you do this. The exact amount is not important, it is important. Long-term continuous work will kill work performance. Fatigue developers will make more mistakes. From the long run, it will be much slower than the development of "normal" schedule. Even if the developer can work well for a long time, this does not mean that they should do this. In the end, they will be tired, they will leave their work or have a non-working problem that affects their performance. If you disrupt people's lives, you will taste the evil it brings. Overtion is not an answer to the project problem. In fact, it is a greater symptoms. If you want to go to the dying, you can save it. 11) There are two purposes of coding standards with coding standards: a. Prevent teams from being smashed by some things that do not develop this irrelevant to develop this irrelevant, it does not know what to do; b. It supports other methods. If there is no coding standard, re-dividing the code will be more difficult, and more difficult, fast advancement is more difficult to exchange it. The goal should be that no one is identified which part of the code written in the team. A protocol is reached with a team unit and then comply with this standard. The goal is not a guidelines that create a non-wonderful rule, but provide guidelines that will make sure your code can clearly communicate. At the beginning of the coding standard, it should be simple and then gradually evolved according to team experience. Don't spend too much time in advance. Create the simplest standard that works, and then gradually develop. 12) What is the system's comparative system structure? It provides a screen of the various components of the system and how they interact - a mapping that allows developers to understand where the new code section is suitable. The system metaphor in XP is similar to the architecture called most methods. The metaphor provides a consistent picture that can be used to describe the working mode of the existing system, the new part is suitable, and they should take. What is important is to remember that the key is to let everyone understand how the system is combined, not a beautiful metaphor. Sometimes you can't think of a good metaphor.
