XP of Agile Development

One common feature of agile methodologies is that they point to "documentation", which argues that the traditional software engineering approach is too "heavy", called a "heavyweight" approach, and that the corresponding agile approach is a "lightweight" approach. It is because of the "lightweight" feeling that there is no power, not only can not effectively reflect flexibility, but it seems to be a methodological approach to solve the problem. As a result, there was an epoch-making meeting that created the Agile Alliance.

In the field of agile methodologies, the more well-known, influential, is the extreme programming (EXtreme programming) with the same acronym--XP as Microsoft's operating system. The extreme programming methodology can be said to be the most vivid banner in the Agile Alliance, and it is also one of the most mature methodologies to be researched, tried, applied, praised and criticized.

This prototype of the methodology known as "hacker Culture" was originally formed in 1996-1999, when Kent Beck, Ward Cunninggham, Ron Jeffrey developed the C3 project (Chrysler Comprehensive Compensation) In practice, summarizes the basic elements of XP. After that, Kent Beck and some of his best friends worked together to improve the practice, and finally formed the extreme programming methodology.

Analytic Extreme Programming

So what is XP? XP is a lightweight (agile), efficient, low-risk, flexible, predictable, scientific, and fun-filled approach to software development. The biggest difference compared to other methodologies is that:

• Provide specific, ongoing feedback earlier in the shorter cycle.
• In the iteration of the planning, first at the very beginning of the rapid generation of a master plan, and then throughout the project development process to continuously develop it.
• Relies on automated test programs to monitor development progress and to capture defects early.
• Rely on verbal communication, testing and communication with the source program.
• Advocating for continuous evolutionary design.
• Relies on close collaboration within the development team.
• Maximize the balance between short-term benefits for programmers and long-term benefits for projects.

Kent Beck once said that "driving" is an example of XP, and even if it seems to be going well, don't take your eyes off the road, because changes in road conditions will make it necessary for you to make some such adjustments at any time. In software projects, the customer is the driver, and they have no way of knowing exactly what the software should do, so the programmer needs to provide the steering wheel to the customer and tell us where we are.

What does XP include to write? ,XP consists of four parts of values, principles, practices, and behaviors that are interdependent, interrelated, and through behavior throughout the life cycle .

Four values

The core of XP is its summary of communication (communication), simple (simplicity), feedback (Feedback), Courage (courage) four values, they are the foundation of XP, but also the soul of XP.
It also extends the fifth value: Humility (modesty). XP relieves development pressures and burdens with "communication, simplicity, feedback, courage and humility," and the XP spirit can inspire us to learn and treat fast-changing, diverse development techniques. The key to successful learning XP is to use "communication, simplicity, feedback, courage and humility" attitude to treat XP, relaxed and happy to feel the practice of XP, self-practice, through the real feedback analysis, to determine the value of XP, have the courage to accept it, or improve it.

1. Communication

The impression that the programmer left is "introverted, not talkative," and then many of the problems in the project are among those who lack communication. Often due to a programmer to make a design decision, but can not notify you in a timely manner, resulting in collaboration and cooperation with the results of a lot of trouble, and in the traditional methodology, do not care about the problem of oral communication is not smooth, but hope that with the help of the perfect process and exhaustive documents, reports, plans to replace, But at the same time, it introduces new problems with low efficiency.

The XP methodology argues that if there is no continuous, uninterrupted communication between team members, there is no point in collaboration, and from this perspective it can be found that communication through artifacts such as documents and reports is a huge limitation. As a result, XP combines best practices such as programming, encouraging verbal communication, resolving problems through communication, and improving efficiency.

2. Simple

XP methodology advocates the idea of "good enough" in the work, which is as simple as possible, as long as it is enough today, regardless of the new problems that will be discovered tomorrow. It's easy to look at, but it's hard to really keep a simple job. Because in traditional development methods, you are required to do some pre-planning for the future in order to set aside some expansion space for future changes that may occur.

As with the traditional approach to development, many developers also question XP, it is important to maintain the scalability of the system, if all is kept simple, then how to make the system can have good extensibility? In fact, there are two reasons to keep it simple:

• The development team's planning at the time of development does not guarantee that it meets the needs of the customer, so most of the work will be frustrated, resulting in a duplication of unnecessary work in the development process, leading to a reduction in overall efficiency.
• In addition, in XP to promote the time to refactor the code, has maintained its good structure and scalability. In other words, extensibility is not the same concept for tomorrow's design, and XP is against working for tomorrow's consideration, not to say that the code is going to be out of scale

And there is a relatively subtle relationship of mutual support between simplicity and communication. The more you communicate with one team, the easier it is to understand what needs to be done and what needs to be done. On the other hand, the simpler the system, the less content you need to communicate, and the more comprehensive the communication will be.

3. Feedback

What causes our clients and management to understand the development team so much? Why do customers and management always like to give us a trip to death? The crux of the problem is the lack of necessary feedback in the development process. In many projects, when the development team has experienced the requirements analysis phase, there is no feedback for a long period of time. The entire development process is like a black box for customers and management, and the progress is completely visible.

And in the process of the project, this phenomenon not only occurs between the development team and the customer, management, but also within the development team. All of this requires us to focus more on feedback. , feedback is critical to the success of any software project, and the XP methodology is further developed to expose the state of the software through continuous, clear feedback. In particular, it is:

• In the development team, by writing unit test code in advance, always feedback the problem and progress of the code.
• In the development process, you should also strengthen the integration work, to achieve continuous integration, so that every increment is an executable version of the work, that is, the software grew up, the whole process, should be through to the customer and management to demonstrate these operational versions, in order to early feedback, early detection of problems.

At the same time, we also find that feedback and communication also have good cooperation, timely and good feedback to facilitate communication. And a simple system is more conducive to test box feedback.

4. Courage

In applying the XP methodology, we are dealing with change every moment: Because of good communication, there will be more opportunities for change, and because of the simplicity of the system at all times, new changes will bring some re-development needs, and as feedback is timely, there will be more new requirements that interrupt your thinking.

All of this makes you instantly in a change, so you need to have the courage to face rapid development and the potential for redevelopment. Maybe you think, why let our development become so messy, but in fact these changes if you do not let it early exposure, then it will be late to appear, and will not perish, therefore, XP methodology let them early appearance, early resolution, is to achieve "small step fast" development rhythm of a good way.

That is, the XP methodology requires developers to wear powerful, automated tests of armor, moving forward, with the support of refactoring and coding specifications, to develop quickly and purposefully.

Courage can come from communication, because it makes high-risk, high-reward trials possible; Courage can come from simplicity, because it is easier to muster up courage in the face of simple systems, and courage comes from feedback because you can get the status of each step in time (automated testing), which makes you more likely to refactor the code.

5. Beyond the four values

Under these four values, there is a deeper thing hidden, that is respect. Because it's all based on mutual interest and mutual understanding among team members.

5 Principles 1. Quick Feedback

Get feedback in a timely and fast manner, and put the knowledge you have learned into the system as quickly as possible. This means that developers should quickly understand whether the current product meets the customer's needs through a short feedback loop. This is also a further complement to the value of feedback.

2. Simplicity hypothesis

Similarly, the simplicity assumption principle is a further complement to the simple value. This principle requires developers to see each problem very easily, that is, to consider this iteration, not to think about what might be needed in the future, and to believe in the ability to add complexity to the system if necessary in the future, that is, to call on everyone to accomplish today's task.

3. Gradual revision

Just like driving the steering wheel, don't make a big change at once, which will make the controllability worse, and the more appropriate way is to fine-tune it. In software development, the same applies, and any problem should be solved by a series of minor changes that can bring about differences.

4. Advocating for change

In the software development process, the best way is to retain the most options when solving the most important issues. In other words, try to prepare for the next modification.

5. Quality work

In practice, it is often seen that many developers prefer to leave some small problems behind. For example, the interface buttons have some uneven, because it does not affect the use of the first regardless, a one or two member function is temporarily useless without writing. This is a work of the phenomenon of the muddy, such a bad habit once developed, will inevitably make the code quality greatly discounted.

In the XP methodology, the implementation of the "small step fast Walk" principle of development, so the quality of work can not be discounted, usually using a test-first encoding to provide support.

13 Best Practices

In XP, integrating 13 best practices, interestingly, none of them is an innovative concept, and most concepts are as old as programming. The main innovation is to provide a good idea, to combine these best practices, and to ensure that they are implemented as thoroughly as possible, so that they are able to support each other to the fullest extent, and next, we understand each of the best practices.

1. Plan the game

The main idea of planning a game is to quickly make a summary plan, and then gradually refine the plan as the details of the project continue to clear. The result of the planned game is a set of user stories and a summary plan for the following one or two iterations.

"The customer is responsible for business decisions, and the development team is responsible for technical decisions" is a prerequisite for the success of the planned game. In other words, the scope of the system, the release time of the next iteration, and the priority of the user story should be determined by the customer, and the development team should decide on the development time, cost of different technologies, how to assemble the team, the risk of each user story, and the specific development sequence for each user story.

Well, knowing this can be a game of planning. First, the customer and the developer sit in the same room, everyone prepares a pen, some pieces of paper to record the user story, preferably a whiteboard, you can start.

• The customer writes the story: The customer talks about what the system should accomplish, then uses its own vocabulary in popular natural language, and writes it on the card, which is the user story.
• The developer estimates: first the customer divides the user story into a priority, wants it, if there's a better three, and then the developer estimates each user story, starting with a high priority. If, at the time of estimation, you feel that some stories are too large to estimate, or that the results of an estimate exceed 2 people/week, then you should break it down and split it into 2 or more small stories.
• Determine the cycle of the iteration: The next step is to determine the time period for this iteration, which can be determined based on the actual situation, although the best iteration period is 2-3 weeks. With the time of iteration, the total amount of work that can be completed is calculated in conjunction with the number of developers involved. Then, based on the results of the estimates, negotiate with the customer to pick out the time-appropriate, prioritized user story combinations to form a plan.

2. Small release

The XP methodology adheres to the philosophy of "continuous integration, fast walking", which means that each release should be as small as possible, although the premise is that each version has enough commercial value to be published.

Because small releases can make integration more frequent, customers receive more frequent intermediate results, and more frequent feedback, customers are able to get a real-time view of the progress of the project, thus providing more ideas for planning in the next iteration. To achieve higher customer satisfaction.

3. Metaphor

In contrast, the best practice of metaphor is the most puzzling. What is metaphor? According to the explanation in the dictionary, "the expression of a language is used to imply similarities between things that are not similar in literal sense." So what's the use of this in software development? In summary terms, it is often used in four areas.

• Seek consensus: to encourage developers to seek a common understanding of the problem, they can use some of the things they are familiar with to make analogies to help you better understand the key structure of the solution, that is, to better understand what the system is and what it can do.
• Invented shared vocabulary: through metaphor, it helps to propose a generic name for the relationship between objects and objects. For example, a policy pattern (used to represent design patterns that can implement a variety of different strategies), a factory pattern (to indicate that the desired class design pattern can be "produced" on demand), etc.
• Innovative weapons: Sometimes, other things can be used to find new ways to solve problems. For example, "We can consider a workflow as a production line."
• Describe architecture: Architecture is relatively abstract, and the introduction of metaphor can greatly reduce the complexity of understanding. For example, a piping architecture refers to the communication between two artifacts through a "pipeline" that delivers messages.

Of course, if you can find the right metaphor is very happy, but not every situation can find the right metaphor, you do not need to force

4. Simple design

Emphasizing the value of simple design, it leads to the principle of simple hypothesis, and to implement is "simple design" practice. This practice seems to be easy to understand, but often misunderstood, and many critics accuse XP of ignoring the design is incorrect. In fact, the simple design practice of XP is not to ignore the design, and think that the design should not be done one time before coding, because it can only be based on "the situation will not change" or "we can foresee all the changes" on the basis of lies.

The simple design of Kent Beck concept is this:

• Able to pass all the test procedures.
• No duplicate code is included.
• Clearly shows all the intentions given to the programmer.
• Include as few classes and methods as possible
• He argues that to maintain a simple system, you need to have the ability to think simple, have the courage to understand the code and the changes, and periodically refactor the habit to eliminate the "bad taste" of the code.
• So how do you start a simple design? XP practitioners have also summed up some specific, actionable ways to think about them.
• Write the test code first: it will be described in detail later.
• Keeping each class accountable is only one thing: the SRP (single responsibility principle) is a fundamental principle of object-oriented design.
• Use Demeter (Dimitri) Law: Dimitri Law, also known as LOD Law, least knowledge principle. This means that an object should know as little as possible about other objects. The metaphorical way to explain is to "only communicate with your direct friends", "Don't Talk to strangers."
• Use CRC cards to explore.

5. Test-first/test-driven development

When I first saw the concept of "test-first", I was puzzled, caught in the "program has not been written out, test what?" "Myth. I began to look for the relevant metaphors and finally found the craftsmen who could enlighten me, first of all, let's see how two different craftsmen work.

• Craftsman One: First pull up a horizontal line, the building of each brick, and this is compared with the horizontal line, so that each brick to maintain the level.
• Craftsman Two: First a row of bricks are finished, and then pull a horizontal line to see which bricks have problems, the problem of the bricks to make appropriate adjustments.

Which method of work would you choose? You must scold the craftsmen. This is a waste of time! But think about it, how do you do it when you write a program? We are working according to the two methods of craftsmen! Even sometimes more stupid than the craftsman, is the whole wall is finished, direct "integration test", often let the entire surface of the wall collapsed. See here, you still think your method is brilliant? This even the craftsmen understand the truth, but he restricting ah.

Not only do we not adopt the work method of craftsman one, but sometimes the programmer will ignore the test work for the reason that "development work is too tense". But this has led to a vicious circle, the more the lack of space to write test procedures, code efficiency and quality of the worse, spend more time to find bugs, solve the bug more and more, the actual capacity of the big hit down. Because of the reduced capacity, the time is more tense and the pressure is greater. Think about it, why not pull a horizontal line? Shouldn't we be able to spend the wasted time on unit tests, making our programs more robust and easier to modify from the start? However, writing a test program is certainly more than pulling a horizontal line, so we need to introduce "automated testing tools", the free Xunit testing framework is your best choice.

To encourage programmers to write test code even before writing a program, the XP methodology provides many compelling reasons.

• If you've kept a simple design, it's not hard to write test code at all.
• If you are programming in pairs, then if you come up with a good test code, then your partner will be OK.
• When all the tests pass, you'll never worry that the code you're writing will "stabbing" in the future, and that feeling is pretty good.
• When your customers see that all the tests pass, they have an unprecedented level of confidence in the program.
• When you need to refactor, the test code will give you more courage because you want to test whether refactoring succeeds only requires a button.

Test-First is a very important best practice in XP methodology, and the knowledge and methods contained in it are very rich.

6. Refactoring

Refactoring is a technique that improves code without compromising functionality, and XP requires that developers have the courage to refactor code when they smell the bad taste of code. The goal of refactoring is to reduce the risk of change, making code optimization easier. Typically refactoring occurs in both cases.

• Before implementing a feature: Try to change the existing code structure to make it easier to implement new features.
• After you have implemented a feature: After checking the code you just finished, check it carefully to see if it can be simplified.

In refactoring, the author, Martin Fowler, suggests that when considering refactoring, you should develop the habit of writing and running test code often, writing code before refactoring, and making every add-on a good time to refactor, and every corrective error as an important time to refactor. The book also lists a number of scenarios and refactoring methods that require refactoring.

Finally, in a similar way, a programmer who is not brave enough to refactor will be given a few injections of strong heart needles:

• XP advocates collective code ownership, so you can be bold to make changes wherever you need to.
• Since there is a complete coding standard in the XP project group, there is no need to redefine the format before refactoring.
• There are difficulties in refactoring, and your pair programming partner can help you effectively.
• A simple design can be a great help for refactoring.
• Test-first allows you to have an effective tester, run at any time to know whether your refactoring work has brought impact.
• As XP continues to integrate, the destruction of your refactoring can quickly be exposed and resolved.

Refactoring technology is a good complement to the design of simplicity, and it is also a reflection of the importance of "quality work" in XP, which is an essential skill for a good programmer.

7. Pair programming

What Two people sit together and write a program? Wouldn't that be a huge waste of manpower? And I don't like to have a man sitting on the side of the D.A. while I'm at work. "Yes, as the problem is listed here, pairing programming has been questioned by many people.

However, since the the 1960s, similar practices have been carried out, and long-term research results have given the other picture, that is, pair programming efficiency is higher than the individual programming. At first, although some speed will be sacrificed, but slowly, the development speed will gradually accelerate, the main reason is that the pair programming big dozen reduce the cost of communication, provide the quality of the work, specific performance in:

• All design decisions are made to ensure that it is not done by a single person.
• Any part of the system is sure to have at least 2 people familiar with the above.
• It's almost impossible to have a test item or other task that 2 people ignore.
• The dynamic of pair combination is a good way for enterprise knowledge management.
• The code is always guaranteed to be reviewed.
• and other best practices for integrating XP methodologies can make pairing programming easier:
• Coding standards can eliminate some meaningless disagreements.
• Metaphors can help pairs of partners better communicate with each other.
• Simple design allows pairs of partners to better understand the work they are doing.

The pair programming technology is praised as the XP to maintain the work quality, the emphasis humanist's one typical practice, the application is also able to make the development team's prior collaboration smoother, the knowledge exchange and the sharing more frequently, the team's stability also will be more stable.

8. Collective code Ownership

Because the XP methodology encourages the team to do pair programming, it is considered that the combination of pair programming should be dynamically paired with the best combination of different tasks and professional skills. Because everyone is sure to encounter different code, the ownership of the code is no longer suitable for private, because that will make the modification work a great inconvenience.

That is, every member of the team has the right to improve the code, everyone has all the code, and all the code is responsible. At the same time, XP emphasizes who destroyed the code (that is, a problem after the change) and who should fix it.

Because there are some best practices to match in XP, you don't have to worry about using collective code ownership to make your code more chaotic:

• Because the integration work is a recurring task in the XP project, when someone modifies the code and brings up the integration problem, it will be discovered in a very short period of time.
• Since each class will have a test code, whoever modifies the code needs to run the test code so that the probability of accidental damage will be minimal.
• As each code is modified to think through the two programmers who are closing the pair, the usual modifications are beneficial to the system.
• Because everyone adheres to the same coding standards, the code is readable, modifiable, and avoids frequent code changes due to small problems such as nomenclature and indentation.

The integration of code ownership is a big difference between XP and other agile methods, and it also embodies the deep coding scenario in XP from another aspect.

9. Continuous Integration

When it comes to best practices such as small release, refactoring, pair programming, collective code ownership, we've seen "continuous integration" many times, and continuous integration is the basic support for these best practices.

There may be confusion about the meaning of continuous integration with a small release representative, in fact, a small release is a frequent intermediate release during the development cycle, while continuous integration means that the XP team is required to do the code integration as many times a day as possible, each time after the unit tests that make sure the system is running.

This allows for early exposure and elimination of errors introduced by refactoring and collective code ownership, thus reducing the pain of problem solving

It is not easy to do continuous integration in the development process, first of all need to develop this habit. and integration work is often tedious and cumbersome, so it is necessary to introduce the daily integration tools appropriately. XP recommends that you first use the Configuration Management Server to manage the code, then use XP tools such as Ant or Nant, write the integration script, call the Xuint, and so on, so that whenever the programmer will check the code in to the configuration server, ant will automatically complete the compilation and integration, and call the test code to complete the appropriate test work.

10. Work 40 hours per week/at a sustainable pace

This is the most fun for developers, managers oppose a best practice, overtime, overtime has long been a developer's routine, but also managers most often use a strategy, and XP methodology that overtime will eventually kill the team's enthusiasm, resulting in project failure, This also fully reflects the XP approach to focus on human factors more than the factors that concern the process.

Kent Beck believes that developers should not do this even if they can work longer, because doing so will make it easier for them to get bored with programming, resulting in some other problems that affect their effectiveness. Therefore, working 40 hours a week is a kind of homeopathic behavior, which is a rule. In fact, it is not worthwhile for developers and managers to violate this rule.

• Developers: If you do not know how to rest, then you can not adjust their rhythm to the best state, then there will be a great negative impact. And in the state of mental concentration, the quality of development can not be guaranteed.
• Manager: Perhaps this can be called the "second kind of people's month myth", that is, you have to extend the daily work time to get more people months. This is because each developer's work is limited and impossible to grow indefinitely, and not only is the quality of the code not guaranteed, but it can also have a regressive effect on the project. Therefore, the use of overtime is not a rational way, is not worth the candle.

One thing to explain, though, is that 40 of "working 40 hours a week" is not an absolute, which means that the team should be guaranteed to work at "normal times". So how do you do that?

First, define "normal working hours" that match your team's situation.

Second, gradually adjust the working time to "normal working time".

Again, unless your time plan is a mess, you should not compromise on time.

Finally, summon up the courage to make a reasonable timetable.

As Milù once said, "Enjoy the football", as well, every developer should "enjoy programming", then "work 40 hours a week" is your starting point.

The team only has a lasting chance of winning. They work hard at a long-term pace, and they conserve their energy by seeing the project as a marathon rather than a full-speed dash.

11. On-Site customer

In order to ensure that the results developed are close to the expectations of the customer, the XP methodology considers that the most important need is to invite the customer to the development site. As mentioned in the planning game, in an XP project, you should always ensure that the customer is responsible for business decisions and that the development team is responsible for technical decisions. Therefore, it is very important for XP project to have customers to clear user stories and make corresponding business decisions in the project.

Perhaps someone will ask, after the customer has submitted the user story does not complete the work? In fact, many people who have tried the story of the user will find it too simple, contain very little information, XP methodology does not understand, therefore, the user story will not be used as the developer of the only instructions to deliver code. User stories are just a starting point, and the latter details need to be complemented by good communication between developers and customers.

As an experienced developer, there is absolutely no doubt about the value of the on-site customer, but it will be difficult for the customer to realize the site. To achieve this, customers need to be communicated to understand that, for the development team, project success is more important to the customer. And on-site customers are an important measure to ensure the success of the project, think when you decorate the house, you are often in the role of the customer in the field? In fact, this metaphor is the best way for customers to understand the importance of customer presence.

In fact, on-site customers in the specific implementation, also not necessarily need customers have been and development team together, but in the development team should and customers can communicate at any time, can be an interview, can be an online chat, can be a telephone, of course, the interview is essential. The key is that when a developer needs a customer to make a business decision, they need to be able to find the customer at any time when they want to know more about the business details.

However, there are some projects that you can not engage with on-site customers:

• When there are already relevant domain experts in the development Organization.
• As some kind of exploratory work, and the customer does not know what he wants (such as new products, new solutions research and development).

To try it, on-site customers can not only strive to get, but also to make the team a fresh, and customers to establish good cooperation and trust.

12. Coding standards

The coding standard is a "vulgar sharing" best practice, whether it represents the heavy methodology of the RUP,PSP, or on behalf of the agile methodology of XP, that the development team should have a coding standard. The XP methodology argues that having coding standards can prevent teams from arguing over details that are not relevant to the progress of the development process, and can cause serious problems with refactoring and pairing programming. Imagine what it would be like if someone changed the name of the code you wrote last time, and the next time you needed to change that part of the code.

However, the goal of the XP methodology coding standard is not to create a single, exhaustive list of rules, but to provide a guideline that ensures that the code is clear and easy to communicate.

If your team already has a coding standard, you can use it directly and refine it in the process. If not, then you can first code, and then in the process of gradually summed up the coding rules, edge-making edge formation. Of course, in addition to this text specification, you can also use some methods such as automatic format Code tools for code specification. , in fact, you just need to implement other practices well and communicate, and coding standards can easily emerge.

13. Coordination is the key

There is a classic saying that "1+1>2" is best for expressing XP, and Kent Beck believes that the best value of XP methodology is to use 12 best practices in a project, rather than using them alone. You can certainly use some of these practices, but that doesn't mean you're using XP methodologies. The XP methodology can truly play its role, and it must be fully applied to 12 of practices.

Reprinted article, original link http://www.cnblogs.com/luoht/archive/2011/05/20/2051714.html

XP of Agile Development