Summary of Extreme Programming

Extreme Programming is a development discipline with simplicity, communication, feedback, and courage as its basic purpose. The practice is to closely associate the entire team with effective practice rules, and enable the team to know their current situation and adjust the rules at any time through full feedback to adapt to their special circumstances.

In extreme programming, every project contributor is a complete part of the "team. This team is built around a "customer" business representative sitting with the team every day.

Core practice: entire team

The team of extreme programming uses a simple method for Planning and Tracking to determine what to do next and to predict when the project will be completed. Focusing on business value, the team creates software systems through a series of tests defined by the customer and small releases fully integrated.

Core practices: planning strategy, small release, customer Testing

Extreme programmers work together in pairs and groups, and constantly improve the design through simple design and mandatory testing Code to ensure that the design is always suitable for the current needs.

Core practices: simple design, paired programming, test-first development, and design improvement

The extreme programming team always keeps the system integrated and running at all times. Programmers write all product code in pairs and work together for all time. They are encoded in a similar way to ensure that all Members can understand and improve all the code as needed.

Core practices: continuous integration, collective code ownership, coding standards

The extreme programming team shares a public and simple system blueprint. All members can work at a regular pace.

Core practice: System metaphor, acceptable pace

Overall team

All participants in an XP project sit together as members of a team. This team must include a business representative-"customer" who provides requirements, sets priorities, and takes charge of the entire project. It is best for this customer or his assistant to be an end user to understand the field and what is needed. The Team also needs programmers. The team may include a tester who helps the customer define the customer acceptance test. Analysts can act as customer assistants to help customers define their needs. There is usually a guide that helps the entire team track and promote the development process. There may also be a manager who provides resources, handles external communication, and works in a division of labor. None of these responsibilities must be exclusive to one individual: Every member of the XP team participates in any way they can, and the best team has no experts, there are only some general participants with special skills.

Planning Strategy

XP plans to solve two key issues in software development: predict what will be completed during the responsibility period and determine what to do next. The focus is on the right track of the project-which is quite simple and clear-better than knowing exactly what will be needed and how much time it will take-this is quite difficult. There are two key planning steps in XP to solve these two problems:

A release plan is a practice that allows customers to demonstrate desired features to programmers, and then programmers evaluate their difficulty. When the customer has a cost assessment and awareness of the important program for these features, the customer arranges a project plan. There is enough room for the initial release plan: Neither priority nor evaluation is true or reliable, and we cannot know exactly the development progress of the team before the team starts to work. Even the initial release plan is not accurate enough to make decisions, so the XP team usually corrects the release plan from time to time.

An Iteration plan is a practice that provides the team with guidance for each Development Week. The XP team builds software systems through two-week "iterations" and provides practical software systems that can run at the end of each iteration. During the iteration plan, the customer demonstrates the features that will be completed in the next two weeks. Programmers divide them into several tasks and evaluate their costs (more detailed than the release plan ). Based on the work completed in the previous iteration, the team signs the work to be undertaken in the current iteration.

These plans are simple, but they provide customers with excellent information and control. Every few weeks, the progress can be clear at a glance. In XP, there is no "90% completed": a feature story is either completed or not completed. The method of focusing on visual results lies in a very small opposition: on the one hand, it is very intuitive. If the progress is unsatisfactory, the customer can cancel the project at a certain position. On the other hand, the progress is obvious, and the ability to determine what will be done is perfect, therefore, XP projects can often accomplish more things they need under less pressure.

Customer Test

As part of a demo of each required feature, XP customers define one or more automated acceptance tests to indicate that the feature has been implemented. The team implements these tests and uses them to prove to themselves and customers that the features have been correctly implemented. Due to time pressure, automation is very important and manual testing will be skipped. This is like turning off your light when the night comes.

The best XP team will treat their customer testing as a programmer's test: Once the test runs, the team will keep it running correctly. This means that the system can only be improved, always forward, and never go backwards.

Minor release version

The XP team implements minor release in two important ways:

First, the team can run and test software systems in each iteration to provide the business value of customer choice. Customers can use this software system for any purpose, whether evaluating or releasing it to end users (highly recommended ). The most important way is that the software system is visible at the end of each iteration and submitted to the customer. This ensures that everything is open and authentic.

Second, the XP team should publish to their end users as frequently as possible. XP website projects are released every day, and home projects are released every month or more frequently. Even products that can be simply packaged can be shipped quarterly.

It may be impossible to create a version so frequently, but the XP team is releasing it all the time. For more information, see continuous integration. Pay attention to the fact that these frequent releases have passed the tests that are everywhere in XP (as described in customer testing and test-first development.

Simple Design

The XP team built the software system into a simple design. They started with simplicity and maintained a simple design throughout the programmer's testing and design improvements. An XP team is always designed to meet the current functional requirements of the system. There is no extra investment here, and the software system is always ready for the future.

In XP, design is not a one-time task, nor a top-to-bottom task. It is a task from beginning to end. There are both design steps in the release plan and iteration plan, integrating the team's capabilities in the rapid design process and improving the design throughout the project process. In an incremental and iterative process similar to extreme programming, good design is essential. This is why more attention must be paid to the design throughout the development process.

Paired Programming

In XP, all product software is jointly implemented by two programmers sitting side by side on the same machine. This practice ensures that all product code is reviewed by at least one other programmer, and the result is better design, better testing, and better code.

It seems inefficient to let two programmers do "a programmer's job", but the opposite is true. Studies have shown that paired programming can get better code at the same time that allows programmers to work independently. This proves that it is much better to add two minds together!

Many programmers have opposed Pair programming without trying it. This really requires some practice to do it well, and you need to practice it carefully for more than a few weeks to see the results. 90% of programmers who have learned paired programming will like this, so we strongly recommend it to all teams.

In addition to providing better code and testing, the team also provides knowledge to pass in between teams. When programmers exchange partners with each other, everyone learns new knowledge from others. Programmers are learning, their technology is improving, and they become more valuable to the team and the company. In pairs, even if it is implemented outside the XP process, it is a great success for everyone.

Test-Preferred Development

Extreme Programming focuses on feedback. in software development, good feedback requires good testing. The best XP team practices "test-first Development", adds a test in a small loop, and then enables it to work. Almost easily, nearly 100% of the Code provided by the team is covered by testing programs, which is an important improvement in most cases. (If your programmer has provided more existing test programs, you will have more power. Save them and they will only help !)

Writing Test Programs is not enough: You must run them. Here, eXtreme Programming is also extreme. These "programmer tests" or "unit tests" are a complete set, every time programmers publish any code to a code library (usually two or more times a pair of programmers release code every day), each programmer's test must be able to run correctly. Every moment is a hundred percent run! This means that programmers can immediately get feedback on how they are doing. Further, these tests provide invaluable support for software design improvements.

Design Improvement

Extreme Programming focuses on providing business value in every iteration. To achieve this goal throughout the project, the software system must be well designed. Selectivity may decrease and eventually stagnate. Therefore, XP adopts a process of continuous Design Improvement called "refactoring", which comes from the title of Martin Fowler, "refactoring: improving the design of existing code ".

The refactoring process focuses on removing duplicates (a clear sign of poor design), improving Code cohesion, and reducing coupling ". In the past 30 years, high cohesion and low coupling have been recognized as good design features. The result is that the XP team starts from a good and simple design and always gives the software system a good and simple design. This allows them to maintain their development speed, and usually improves the project development speed.

Refactoring naturally provides strong support through comprehensive tests that confirm that nothing in the system will be damaged when the design changes. Therefore, both customer testing and programmer testing are effective evaluation factors. XP practices are mutually supported: they are stronger than when they are independent.

Continuous Integration

The extreme programming team always keeps the system fully integrated. We say that the daily build version is for the weak: The XP team builds the system many times a day. (An XP team of 40 members can be integrated for at least eight to ten times a day !)

The benefits of this practice can be learned by recalling the projects you may have heard of (or participated in): when the system is built every week or at a lower frequency, it is usually stuck in the "integration hell" where everything cannot run and no one knows why.

Very little integration brings a series of problems to software projects. First, although integration is a condition for released work code, the team does not practice it and is usually assigned to people who do not know the entire system very well. Second, the seldom integrated code is usually -- I 'd rather say always -- errors and omissions.

Collective code ownership

In an extreme programming project, Every programmer can improve any code at any time. This means that all codes get more benefits with the attention of many people, which improves the code quality and reduces defects. There is another important benefit: When the code is only owned by a single person, the required features are often put in the wrong position, A programmer finds that he needs a feature, but the code is not managed by him. The code owner is too busy to add this feature, so the programmer has to add this feature to his own code that should not exist. This leads to ugly, difficult to maintain the code, and full of cohesion focusing on recovery and low (poor.

If someone blindly modifies code that they do not understand, collective code ownership may cause problems. XP uses two key technologies to avoid such problems: capture errors through programmer testing, paired programming indicates that the best way to work on unfamiliar code is to find an expert as a partner. This practice extends the knowledge to the entire team to ensure that changes are made as needed.

Encoding standard

The XP team follows a common coding standard, so all the code in the system looks like a single-very-competent-person. This standard does not matter: it is important to make all the code look very similar to support collective code ownership.

System analogy

The extreme programming team formed a consensus on how the program operates, which we call a "system metaphor ". In the best state, the system metaphor is a simple soul description of how a program operates, for example, "This program works like a box of bees, search for pollen and bring it back to the beehive "as a proxy-based Information Query System Description.

Sometimes a very poetic imagination may not appear. In any case, whether or not there is a vivid analogy, the XP team will choose a public naming system to ensure that everyone can understand how the system works, and where to find the function you need, or find the correct position where you want to add the function.

Acceptable pace

The extreme programming team will be here for a long time. They work hard at a constant pace. This means they work overtime when they are effective, and they often work like this to ensure the maximum productivity every week. This properly explains that a race-style project will neither be productive nor create a quality software system. The XP team is here to win, not to die.

Summary

Extreme Programming is a development discipline based on simplicity, communication, feedback, and courage. The practice is to closely associate the entire team with effective practice rules, with sufficient feedback, the team can always know their current situation and properly adjust the practice rules to adapt to their special circumstances.