What is extreme programming?
BrokenDoor (XPCHINA) September 15, 2003
Extreme Programming is a development discipline that is based on simplicity, communication, feedback, and courage. Its approach is to closely link the entire team with a valid practice rule. Through full feedback, the team can always know your current situation and the appropriate regulation rules to adapt to your own special circumstances.
In extreme programming, each project contributor is part of the "team". This team is built around a business representative that works together every day and teams - "Customers" established. Core Practice: Overall Team
Extremely programmed teams use a simple way for planning and tracking to determine what will be done next and predicting the project. Focus on business value, the team creates a software system through a series of tested tests and fully integrated small releases. Core practice: planning strategy, small distribution, customer test
Extreme programmers work together by pairing and group, and the continuous improvement of design and mandatory code, the design is always suitable for the current demand. Core practice: Simple design, pair programming, test priority development, design improvement
Extreme programming teams always keep the system to be integrated and run at all time. The programmer writes all product code in pair and works together in all times. They encode similar forms to ensure that all members can understand and improve all of the code as needed. Core practice: continuous integration, collective code ownership, coding standard
Extreme Programming Team Share a public and simple system blueprint. All members can work according to a rhythm that is synchronized from time to time. Core practice: system metaphor, acceptable pace
Core practice
All participants in the team's overall XP project are sitting together as a member of a team. This team must include a representative of a business - "Customers", he provides demand, sets the priority, and tested the direction of the entire project. It is best to be a end user, understand what is needed. The team, of course, there must be a programmer. The team may contain testers, helping customers define customer acceptance testing. Analysts can use the customer's assistant to help customers define the needs. There is usually a guidance that he helps the entire team to track and promote the development process. There may also be some administrators who provide resources, handling foreign exchanges and division of labor. There is no one in these duties that must be unique to someone: Every XP team member is involved in any way they can do, the best team does not expert, only some of the general participation of special skills By.
Planning strategies XP plan resolution Software development two key issues: presence, which things will be completed during the responsibility period, and make sure what needs to do next. The focus is to grasp the correct orbit of the project - this is quite simple - even better to predict which things will need and how much time may cost - this is quite difficult. There are two key planning steps in XP to solve these two problems:
The publishing plan is a practice that allows customers to demonstrate the features they want, and then programmers evaluate their difficulty. When there is a price assessment in your hand and the cognition of important procedures for these features, the client arranges a project plan. The initial release plan needs enough room: priority and assessment is not true and reliable, and we can't understand the development schedule of the team before the team starts working. Even the initial release plan is not enough accurately, and the XP team usually corrects the release plan from time to time.
Iterative Program is a practicality that can provide the team to provide the guidance of each developing week. The XP team creates a software system through the two-week "iteration", providing a software system that can run at each iteration. At the time of the iterative plan, the character of the customer wants to complete within two weeks. Programmers divide them into several tasks and evaluate their costs (some more than the release plan). Based on the work completed in previous iterations, the team signs the work that will be undertaken in the current iteration. These plans are very simple, but they provide customers with very good information and excellent manipulation control. Every few weeks, how many progress can be aerated. There is no "90% completed in XP": a character story is either completed, or no completion. Focusing on the visual results method is a good small opposite argument: On the one hand, it is very intuitive. If the progress cannot be satisfactory, the customer can cancel the project in a certain position. On the other hand, the progress is obvious, and it is very perfect to determine which things will be completed, so XP projects can often accomplish more required things under less pressure.
Customer Test As part of each of the demanded features, XP clients define one or more automated acceptance tests to indicate that features have been implemented. The team implements these tests and uses them to prove the characteristics of themselves and the customer has been properly realized. Due to time pressure, automation is important, manual testing will be skipped. This is like when the night is coming, you can turn off your lights.
The best XP team will treat their customer test as the test work: Once the test is running, the team will keep it can operate correctly. This means that the system can only be improved, always forward, never go back.
The small release version XP team practices a small release from two important ways:
First, the team can run, tested software systems, and provide customer-selected commercial value. Customers can use this software system for any purpose, whether it is an assessment or released to end users (strongly recommended). The most important way is that the software system is visible at each iteration, and is submitted to the customer. This guarantees that anything is open and real.
Second, the XP team issues the end user of them as much as possible. The XP website project is released every day, and the home project is released monthly or more frequently. Even the product that can be easily upgraded can be shipped every quarter.
This frequently created version may be unlikely, but the XP team is released every moment. MORE INFORMATION You can see continuous integration and note that these frequent issues have become reality through the tests visible in XP (as described in customer testing and test priority development).
Simple design XP team construction software system is a simple design. They maintain a simple design from the simple start and in the entire programmer test and design improvement. An XP team maintains a design that is always suitable for the current functional requirements. There is no extra investment here, and the software system always prepares for future.
The design is not a one-time job in XP, nor a thing from top to bottom, it is from beginning to end. There is a design step in the release plan and iterative plan, and the team's ability is collected in the fast design process and improves the design throughout the project. In the increment and iterative process similar to extreme programming, good design is essentially. This is why you must pay more attention to the design of the design throughout the development process.
Focusing on the programming in XP all product software is shared by two programmers, completed on the same machine. This practice ensures that all of the product code has at least one other programmers to review, and the result is a better design, better testing and better code.
Let the two programmers do "a programmer's work" seems to be low, but actually just opposite. Studies have shown that the programming will get better code for programmers to work alone. This proves: The two minds are more than a better than one! Many programmers oppose pair of programming without trying. This really requires some practices to do it, and you need to practice more than a few weeks more. 90% of learning have become a programmer of programming, so we highly recommend it to all the teams.
In addition to providing better code and testing, the team also provides knowledge in the middle of the team. When the partner is exchanged as a pair of programmers, everyone will learn new knowledge from other people. Programmers are studying, their technology is raising, and they become more valuable to teams and companies. Even, even if it is implemented outside the XP process, it is also a huge success of everyone.
Test priority development Extreme programming surrounds feedback, while in software development, good feedback requires a good test. The best XP team practices "test priority development", add a test in a small loop and let it work. Almost easily, the team's code is close to 100% has a test program coverage, in most cases this is very important. (If your programmer has provided more existing test programs, you will have more power. Save them, they will only provide help!)
It is still not enough to write only test programs: you have to run them. Here, extreme programming is also extreme. These "programmers test", or "unit test" is a complete collection, whenever the programmer issues any code to the code library (the paired programmer usually releases twice or more), each A programmer test must be able to run correctly. Every time is 100% run! This means that programmers can get feedback on how they do what they do. Further, these tests provide invalvation support when software design improvements.
Design Improvements Extreme Programming At each iteration is concerned about providing business value. In order to complete this goal throughout the project, the software system must have a good design. Oblective may decrease and eventually stagnate. Therefore, XP uses a process of continuous improvement, referred to as "reconstruction", from the book name of Martin Fowler, "Refactoring: Improved Existing Code Design".
The process of reconstruction focuses on deduplication (a clear sign of a poor design), and "consolidation" to increase the code, and reduces "coupling". High-intensity and low coupling have been recognized as a good design in the last thirty years. The result is that the XP team starts from a good and simple design and always allows the software system to have a good simple design. This allows them to maintain their development speed and usually improve project development speeds.
Reconstruction is naturally a strong support by comprehensive testing, these tests are used to confirm that there will be no destruction in the system when design changes. Therefore, customer testing and programmers test are effective evaluation factors. XP practices are mutual support: they will be more strong than their respective independence.
Continuous integrated extreme programming team always maintains the system completely integrated. We said that the daily constructing version is provided for the weak: XP team must build a system a few times a day. (A 40-person XP team integrates at least eight to ten times!)
The benefits of this practice can be understood by recalling the item you may have heard (or personally involved) project: When the system is constructed, it will usually fall into "integrated hell" when the system is constructed. Everything is not running there and no one knows why.
Less integration will bring a range of questions to the software project. The first, although integration is the conditions for the release of good work code, but the team does not practice it, and usually it is delegated to those who don't know much about the entire system. Second, very little integrated code is usually - I would rather say that it is always - wrong leaks. Collective code ownership In an extreme programming project, each pair of programmers can improve any code at any time. This means that all code gain more benefits under many people's concerns, so that code quality and reduces defects. There is another important benefit: When the code is only responsible for a single person, the required characteristics tend to put a wrong location because a programmer finds that he needs a feature but that code is not managed. The owner of the code is too busy and cannot add this feature, so this programmer has to add this feature to his own code that should not exist. This leads to ugly, difficult to maintain to the code, full of repeating and low (poor).
If someone makes blind modifications on the code they don't understand, the collective code ownership may bring problems. XP avoids such problems by two key technologies: Capture errors via programmer testing, indicating that the best way is to find an expert in this area when working on unfamiliar code is a partner. In order to ensure good modifications in need, this practice extends to the entire team.
The encoding standard XP team follows a public coding standard, so all the code in the system looks like a single - very capable - human hand. This standard is not important: It is important to let all the code look very similar to support the collective code ownership.
The system-metaphor Extreme Programming Team has created a consensus for the program, which we call "system metaphor". At the optimal state, the system is compared to how the program is a simple soul description, such as "this program is working like a box of bees, looking for pollen and backing the beehive" as a proxy information query system description.
Sometimes a very poetic imagination may not appear. In any case, no matter whether there is no vivid metaphor, the XP team will use a public naming system to ensure that everyone can understand how the system works, and where to find the features you need, or find you to add The correct position of the function.
Acceptable steps extreme programming teams will take a long time here. They work hard and under a pace of continuous maintenance. This means that they work overtime when they are effective, and they often work to ensure that there is the greatest productivity every week. This properly explaining the death competition project neither productivity does not create a quality software system. The XP team is here to win rather than die.
summary
Extreme programming is a development discipline based on simplicity, communication, feedback, and courage. Its practice is to closely link the entire team with a valid practice rule. Through full feedback, the team can always know your current situation and properly adjust the practice rules to adapt to your special circumstances.
