Extreme Programming (Extreme Programming, Abbreviation XP) is proposed by Kent Beck in 1996. In the 1990s, the Kent Beck has been jointly explored new software development methods, hoping to make software development simpler and effective. Kent carefully observes and analyzes the prerequisites, possibilities and difficulties of simplified software development. In March 1996, Kent finally introduced new software development concepts in a project made by Daimlerchrysler.
XP is a lightweight, smart software development method; it is also a very strict and careful way. Its basic and values are exchanged, simple, feedback and courage; that is, any software project can be improved from four aspects: strengthen communication; from simple order; seek feedback; XP is an near-spiral development method that decomposes complex development process into a relatively simple small cycle; through active communication, feedback, and other a series of methods, developers and customers can be very clear and developed. , Change, problems and potential difficulties to be solved, and adjust the development process in a timely manner according to the actual situation.
What is software development
Software development is: demand, design, programming, and test! Demand: Not only is user needs, it should be all the needs encountered in the development. For example, you must first know what the project is to understand; what data should be entered in the test case ... In order to clearly know these needs, you often have to communicate with customers, project managers. Design: Before the encoding, there must be a plan to tell you what to do, how the structure is equal. You must do it according to this, otherwise it may be a mess. Programming: If you are on the project's deadline, your program can't run or don't reach the customer's request, you can't get money. Test: The purpose is to let you know, when it is completed. If you are smart, you should write test first, so you can know if you are complete. Otherwise, you often don't know, what functions have been true to do, how far is it left from expected.
In software development, customers and developers have their own basic rights and obligations. Customer: • Define business priority for each user's needs; • Develop a general plan, how much investment, how long it takes, what is the purpose of achieving each working week during the project development process, can make investment to get the biggest Revenue; • By repeating the function test you specify, you can accurately grasp the progress of the project; • You can change your demand, function, or priority while avoiding expensive reinvestment; can adjust the project plan according to various changes; • • • • It is possible to cancel the project at any time; when the item is canceled, the previous development work is not a bunch of garbage. It has been developed to be required. The work is not difficult to take over. Developers: • Know what you want, and what you want to do; • Work is effective; • If you have problems or difficulties, you can get our customers, colleagues, superiors, or help; • Evaluate work, and according to the surrounding situation Change timely reassessment; • Actively undertake, rather than negative acceptance assignment; • 40 hours a week, do not work overtime.
This is software development, in addition to this, there are other problems that should be concerned!
Smart lightweight software development method
A software development method is a series of regulations, norms, and practices related to development. The heavyweight development method strictly defines many rules, processes, and related documentation. Smart lightweight development methods, the rules and documents are relatively small, the process is more flexible, and it is relatively easy to implement. Programmers develop software in the way they like in software engineering concepts. The quality of the program is difficult to control, the debugger is very cumbersome, and it is difficult to read the code written by the programmer. In 1968, Edsger Dijkstra wrote a letter to the Goto Statement Considered Harmful to CACM, and the concept of software engineering was born. The programmers began to abandon the previous practices and use more systematic and stricter development methods. In order to develop and control other products as strict, people have developed a lot of rules and practices, invented many software engineering methods, and software quality has been greatly improved. As you encounter, more rules and processes are getting fine and complicated.
Today, in the actual development process, many rules have been difficult to follow, many processes are complicated and difficult to understand, and the production process of documents in many projects is being lost. People try to make a more comprehensive and better package, or hopes to be more complex, more powerful auxiliary development tools, but always can't succeed, and development specifications and processes become more complicated and difficult Implementation. In order to catch progress, programmers often skip some specified processes, and few people can comply with those heavyweight development methods.
The reason for failure is very simple, and there is no universal medicine in this world. Therefore, some people put forward that rules and processes in the heavyweight development method have been dedupted, reorganized, and optimized, so that there is a lot of lightweight processes that adapt to different needs. In these processes, the actual needs is retained, and unnecessary complicated regulations are abandoned. Moreover, compared with traditional development methods, the lightweight process is no longer like a stream production line, but is more flexible.
Extreme Programming (XP) is such a smart lightweight software development method.
Why is it called "extreme" (limit)
"Extreme" means that XP emphasizes the limit of each method and idea it listed, and it is not advocated by other XPs; The overall design, etc.). A project that strictly implements XP, its development process should be smooth, efficient and fast, able to do a 40-hour work system for a week without delay project progress.
What is XP software development?
1 limit work environment
In order to maximize the basic rights and obligations of customers and developers during software development, XP requires the best working environment. Everyone who participates in project development will be a role (project manager, project supervisor, etc.) and perform corresponding rights and obligations. All people work in the same open development environment, it is best to work in the same big house, as well as tea supply; 40 hours a week, do not advocate overtime; every morning, everyone stands together Short meeting; there are some big whiteboards on the wall, all Story Cards, CRC cards, etc., you can write paintings above when discussing problems; you can play computer games together after get off work ...
2 extreme demand
Customers should be one member of the project development team, rather than being separated from developers; because of the project's plan to final acceptance, the customer has a very important role. Together with customers, the developers becomes a small demand module (User Story), such as "the total number of calculation grades, is accumulating the number of people in all the grades."; These modules will be based on the actual situation They are combined or broken down into smaller modules; they are recorded on some small cards, which are subsequently developed in each small cycle (Iteration, usually no more than 3 weeks). Implementation; customers specify their priority according to the business value of each module; developers must do the development risk of each demand module, high risk (usually because of the lack of similar experience) demand modules will be prioritized , Exploration and development; after developers and customers evaluate each module from different angles, they are arranged in different development cycles, customers will get as accurate development plans; customers specify acceptance for each requirements module Test (function test). Each time a development of a developed software (after a development cycle), the user can get a system that can start using, this system fully implements all the needs of the plan. In some traditional development modes, no matter what function, users have to wait until all development is completed before they can start.
3 extreme design
From a specific development perspective, the inner layer of the XP is a process based on the test drive development (Test Driven Development) week, such as the processes such as planning and design, are surrounded around these. There are many corresponding unit tests for each development cycle. Just start, because all of the unit tests are failed, so all unit tests are failed; with a small demand module completion, more and more unit tests are increasing. In this way, customers and developers are easily inspected, and whether they have fulfilled their commitments to customers. XP advocates simple design (Simple Design), using the simplest way, making programs written for each simple need to test through all related units. XP emphasizes to abandon the detailed design method (Big Design Up Front), because there are many contents in this design that you are now or recently. XP also vigorously advocates the design review, code review, reforming and optimization (Refectory), all of which are actually the process of optimizing design; constantly run unit testing and functional testing during these processes, ensuring reforming and Optimized systems are still in line with all the needs.
4 limit programming
Since programming is important, XP advocates two people to write the same process together, and the code ownership is accompanied by the entire development team (Collective Code Ownership). Programmers must strictly abide by programming specification when writing programs and reorganization optimization procedures. Anyone can modify the procedures written by other people, and then determine the new program through unit test.
5 limit test
Since the test is very important, XP advocates writing unit test before starting writing the program. Developers should always integrate development of the development, and run unit testing after each integration; do any code review and modification, run unit testing; found BUG, it is necessary to increase the corresponding Test (so the XP method does not require a bug database). In addition to unit testing, there is also an integrated test, function test, load test, and system testing. All of these tests are one of the most important documents in the XP development process, and one of the final delivery to the user. Important practices and rules in XP
1 Project Development Group (Team)
In XP, each person who contributes to the project should be one member in the project development team. Moreover, at least one of the groups must be very clear to user needs, can make demand, determine the business value (priority) of each requirement, adjust the project, etc. This person plays the "customer" role, of course, is the actual end user, because the entire project is expanded around the demand of end users. Programmers are an indispensable member in the project development team. There can be testers in the group, they help customers develop acceptance tests; there are analysts to help customers determine demand; there is often a Coach (coach), responsible for tracking development progress, solving some problems encountered in development, and promoting projects; It is also possible to further project managers, responsible for distributing resources, assisting exchange communication inside and outside the project. There are so many roles in the project team, but it is not to say that everyone doing is that others cannot intervene or intervene, and XP encourages everyone to contribute more to the project as much as possible. Equality, take the length of the best; this is the best XP development team.
2 Planning Game, acceptance test, small scale release (Small Releases)
The XP Development Team uses a simple way to conduct project plans and development tracking, and predict the progress of the project and the steps to determine the future. According to the business value of the demand, the Development Team is a series of development and integration of a group of demands, and each development will produce a system that can be used by testing.
• Plan project
The planning process of XP is mainly for two issues in software development: how much work can be completed before delivery date; what should I do now. Continuous answer, it is to serve how to implement and adjust the development process; compared to this, I hope that the beginning of the development process will do what is going to do, how much time is spent, and it is half-time. In response to these two questions, two main corresponding processes in XP:
Software Publish Plan (Release Planning). Customers describe demand, developers estimate development costs and risks. The customer develops a rough project plan based on the importance of developing costs, risks and every demand. The initial project plan is not necessary (nor possibly) is non-accurate, because the development cost of each requirement, risk and its importance are not unchanged. Moreover, this plan will be constantly adjusted during the implementation process.
Cycle Development Planning. During the development process, there should be many phases (such as a plan every three Monday). Developers may perform internal reforming and optimization (code and design) in a certain cycle, increasing new features at a certain cycle, or will do two aspects in one cycle. However, after each development cycle, users should get a system that has been implemented. Moreover, each time a cycle, the customer will reproduce the need to determine the next cycle to be completed. In each development cycle, developers will break demand into a small task and then estimate the development costs and risks of each task. These estimates are based on actual development experience, the project is much done, the estimation is naturally more accurate and accurate; in the same project, every time a development cycle, the next estimation will have more experience, reference and basis, thus more precise. These simple steps provide customers with rich, sufficient information, making it flexibly and effectively regulates development processes. Every two or three star periods, customers can always see the needs of developers have completed. In XP, there is no "fast to complete", "completed 90%" blur, or if it is done, or if it is not completed. This kind of practice seems to be favored: the advantage is that the customer can know what to do so, whether the things do it, what else to do or improve what to do; the disadvantages are what customers have seen. It may be very unsatisfactory or even abort the contract. In fact, this practice of XP is to find problems early, solve the problem, rather than waiting for a few months, the user finally saw the development system, and then told you that this is not, that change, but also increase Which content, etc. • Acceptance Test
Customers define some acceptance tests for each requirement. By running an acceptance test, developers and customers can know if the developed software meets the requirements. XP developers are as important as those of these acceptance tests and unit testing. In order not to waste valuable time, it is best to automate these test processes.
• Frequent small scale release software (SMALL Releases)
The need for each cycle is the most needed for users. In XP, the system that is published when the period is completed each cycle, the user should be able to easily evaluate, or can be used in actual use. In this way, software development is something that can't be seen, but it is true. XP requires frequent publishing software, if possible, a new version should be released every day; and after completing any changes, integration, or new demands, a new version should be released immediately. These versions of consistency and reliability are guaranteed by the development of acceptance testing and test drive.
3 Simple design, Pair Programming, test drive development, reforming and optimization
The XP programmer is not only working together as a development team, but also writes the same program with two people for a small development unit. Developers carry out simple design, write unit tests, and write code that meets the test requirements, and constantly optimize the design under the premise of meeting demand.
• Simple design
This is the most confused in XP. XP requires the easiest way to implement each small demand, provided that the software developed in accordance with these simple designs must pass the test. These designs can meet the needs of systems and customers in the current demand, do not require any design of the snake, and all of these designs will be constantly reorganized and optimized during subsequent development.
In XP, there is no one-time in traditional development model, and the overall design of all needs. In XP, the design process has been developed throughout the project: from the plan to develop a project, to develop a plan for each development cycle, to a simple design for each demand module, to the design review, and never Intermittent design reforming and optimization. The entire design process is a spiral, unpredictable process. From this perspective, XP is the ultimate of the design. PAIR Programming
In XP, all the code is written by two programmers on the same machine - this is the most controversial in XP and the most difficult thing. This ensures that all code, design, and unit tests are reviewed by another person, the quality of code, design, and testing is improved. It seems that it is a waste of human resources, but various studies have shown that the fact is exactly the opposite. - This work is greatly improved working strength and work efficiency.
Many programmers have been forced to try this (XP also requires support for administrative orders). Along the start of the start, and the efficiency of the two people will not be higher than the efficiency of one person. The effect of this approach is often necessary to stick to a few weeks or two months before it can be significant. In terms of all the programmers who have just started Pair Programming, 90% of people think that this work is more efficient in two months.
In project development, each person will continue to replace partners programming. Therefore, Pair Programming not only improves software quality, but also enhances knowledge exchanges and updates, enhances communication and understanding of each other. This is not only conducive to individual, but also benefits the entire project, developing teams and companies. From this point of view, Pair Programming is not only applicable to XP, but also for all other software development methods.
• Test driver development
Feedback is one of the four basic values of XP - in software development, full feedback can only be obtained by sufficient testing. The tests made in XP can be seen in other software development methods, such as functional testing, unit testing, system testing and load testing, etc. During the development process, the test continues to accumulate as the project progresses. In addition, since the entire development team has code, the test is also maintained by everyone. That is, anyone should run all the tests all over before picking the program (Check IN); if anyone finds a bug, it should immediately add a test to this bug, not waiting for that program. People are completed; anyone takes over the task of other people, or modifying other people's code and design, if you can pass all tests, it will prove that his work has not destroyed the system. In this way, the test can truly help get feedback effects; and, the test should be basically covered by all customer and development requirements by continuously preparing and accumulating all of the customer, so developers and customers can get as much feedback as possible.
• Reforming and optimization (Refactoring)
XP emphasizes a simple design, but simple design is not a designed water-based program, nor does it have no structure, lack of reusability programming. Although developers are simple designed for each USER Story, it is also constantly improving design, this process is called design reforming and optimization. This name appears in the "Refactoring: Improving The Design of Existing Code" written in Martin Fowler.
Refactoring is mainly working to reduce the reuse of the procedures and reuse in the program and design, enhance the reusability of procedures, and design. The concept of Refactoring is not XP first, it has been proposed for nearly 30 years, and has always been considered to be one of the characteristics of high quality code. However, XP emphasizes that Refactoring is extremely, and should be used anytime, anywhere. Of course, after each change, the programmer should run the test program to ensure that the new system still meets the scheduled requirements. 4 frequent integration, collective ownership, programming specification
The XP Development Team often integrates different modules. In order to improve software quality, in addition to test drive development and Pair programming, XP requires everyone's code to comply with programming specification, and anyone can modify the code written by others, and everyone should actively check the code written by others.
• Frequent integration (Integration)
In many projects, developers tend to integrate each module very late. In these projects, developers often discover a lot of problems during the integration process, but cannot affirm that the procedures are issues; acceptance. For customers, even if these systems can pass the test test, because there is short time, there is not much grasp of the customer's heart.
In order to solve these problems, XP proposes that during the entire project, it should be frequent, and the User Story has been developed as much as possible (a new User Story each time. Each integration must run the corresponding unit testing and acceptance test to ensure that the requirements are in line with customers and developments. After the integration, a new application system is issued. In this way, the entire project development process is almost one or two days, and a new system will be released, sometimes it will release several versions one day. With this process, customers can very clearly grasp the function and development schedule and is based on these circumstances and developers to communicate in time to ensure smooth completion of the project.
• Collective code Ownership, Collective Code Ownership
During many project development, developers only maintain their own code, and many people don't like other people to modify their own code. Therefore, even if there may be a corresponding more detailed development document, a programmer is very small, and it is not willing to read other programmed code; and because you don't know what functionally achieved, a program Members generally don't dare to change the code of others. At the same time, because it is your own code, some problems may not be discovered or solved because of the limitations of time nervous or technical level. In response to this point, XP advocates everyone to share the code. Everyone has the right and obligations to read other code, discover and correct errors, reforming, and optimizing the code. In this way, these code is not only one or two people, but is done by the entire project development team. The error will be reduced, and the reuse will be improved as much as possible, and the quality of code is very good.
In order to prevent the code from modifying other people from causing the system crash, each person should run the test program after modification. (From this point, we can see it again, how the various practices and rules of XP are combined with organically.)
• Programming specification
Everyone in the XP Development Team follows a unified programming standard, so all the code seems to be written by one person. Because there is a unified programming specification, each programmer is easier to read the code written by others, which is one of the important premise of implementing Collective Code Ownership.
5 metaphor (system metaphor), not overtime
The XP process allows everyone to have a common, concise understanding of the system by using some image metaphors. XP believes that overtime is abnormal, because this explains the estimate of project progress and arrangements.
• Metaphor (system metaphor)
To help everyone unanimously understand the customer needs to complete, the system function to develop, the XP development team describes how the system or function module works with a lot of image metaphors. For example, for a search engine, its metaphor may be "a large group of spiders, looking for things to capture on the Internet, then bring things back to the nest."
• Do not work overtime
A large number of overtime means that the original plan is inaccurate, or the program is far from knowing what work can be done. Moreover, development management personnel and customers have failed to accurately grasp the development speed; developers are therefore very fatigued. XP believes that if there is a large number of overtime phenomena, development managers (such as coach) should be able to determine overtime with customers, and adjust project planning, progress, and resources in time.
Introduction to some basic concepts in XP
User Story: Developers asked customers to write all the needs into a separate small story, each can be completed for a few days. During the development process, customers can make new User Story at any time, or change the previous User Story.
Story Estimates and Development Speed: The Development Team is estimated to each User Story and calculates the development speed based on the actual situation in each development cycle (iTeration). In this way, developers and customers can know how little USER Story can be developed every week.
Release Plan and Release Scope: During the entire development process, developers will continue to post new versions. Developers and customers determine the User Story included in each release.
Iteration (Development Cycle) and Iteration Plan: During a Release process, developers ask customers to choose the most valuable User Story as the development of the next two weeks.
The Seed: After the first development cycle is complete, the system submitted to the customer. Although this is not the final product, it has realized several customers to think that the most important Story, developers will gradually add new modules on the basis.
Continuous Integration: Assemble the development of the User Story, one by one, step by step, and even the final product.
Acceptance test (function test): For each USER Story, customers will define some test cases, the developer will automate the process of running these test cases.
UNIT TEST: Before starting the write prior, the programmer first writes the corresponding test program for most classifications.
Refactoring (Reforming and Optimization): Remove the redundancy in the code, increase the reusability and scalability of the code.
summary
A success factor for XP is to pay attention to the customer's feedback - the purpose of development is to meet the needs of our customers. The XP method enables developers to be confidently facing changes in customer needs. XP emphasizes teamwork, managers, customers and developers are one of the development teams. The team is working to develop high quality software by using XP's simple but effective way to use XP. The setup of XP is simple and efficient; the programmer obtains customer feedback through testing, and modifies the code and design according to the change, they always give the software to the customer as soon as possible. XP programmers can be brave in facing demand and technology changes. XP is very like a mental puzzle that is tied up by many small pieces. It doesn't make sense to see every small piece alone, but after assembled, a beautiful picture will be present in front of you.
