What is extreme programming (extreme Programming, abbreviation XP)

Programming                                                  What is extreme programming (Extreme programming, abbreviation XP)                                                           Source: Chinaxp   http://www.xpchina.org     waltson     extreme programming (Extreme Programming, Abbreviated as XP) was proposed by Kent beck in 1996. Kent beck, working with Ward cunningham in the early 90, has been exploring new software development methods, hoping to make software development simpler and more effective. Kent has carefully observed and analyzed a variety of prerequisites, possible lines, and difficulties in simplifying software development. In March 1996, Kent finally introduced a new concept of software development in a project for DaimlerChrysler--xp. XP is a lightweight, agile approach to software development, and it is also a very rigorous andA careful approach. Its foundation and values are communication, simplicity, feedback and courage; that is, any software project can be improved from four aspects: strengthening communication, starting from simple, seeking feedback, and being realistic. XP is a kind of near-helix development method, it decomposed the complex development process into a relatively simple small cycle, through positive communication, feedback and a number of other methods, developers and customers can be very clear development progress, changes, pending problems and potential difficulties, etc. and adjust the development process in time according to the actual situation. What is software development software development content is: requirements, design, programming and testing! Requirements: Not just the needs of users, it should be all the requirements encountered in development. For example, you should first know what to do with this project, what data should be entered in the test case ... To be clear about these needs, you often communicate with customers, project managers, and so on. Design: Before coding, there must be a plan to tell you what to do, how the structure is, and so on. You must do this, or you may be in a mess. Programming: If on the project deadline, your program can not run up or reach the customer's request, you can not get the money. Test: The goal is to let you know when it's done. If you are smart, you should write the test first so that you can know in time if you are really done. Otherwise, you often don't know what functions are really done, how far from the expected goal. In software development, both the customer and the developer have their own basic rights and obligations. The customer:    Define the business priorities for each user's needs;    develop an overall plan, including how much investment, how long, what to achieve,;    each work week in the project development process, Can get the most out of your investment;    by repeatedly running the functional tests you specify, you can accurately control the progress of your project;    change your needs, functions, or priorities at any time, avoid expensive reinvestment, and be able to adjust the project plan in a timely manner according to various changes;  ·  can cancel the project at any time, when the project is canceled, the previous development work is not a pile of garbage, the developed function is in line with the requirements, the work in progress or unfinished should be not difficult to take over. Developers:    know what to do and what to prioritize;    work efficiently;    problems or difficulties can be answered or helped by customers, colleagues, superiors;    Evaluate the job and reassess the situation in a timely manner,;    active commitment to work, rather than negative acceptance;    40-hour work per week, no overtime. This is software development, and beyond thatThere are other issues to be concerned about! Smart lightweight software development methodology a software development approach is a series of rules, specifications, and conventions related to development. The heavyweight development approach defines a number of rules, processes, and related document work. Smart lightweight development methods, with relatively few rules and documentation, more flexible processes, and relatively easy to implement. Before the concept of software engineering appeared, programmers developed software in the way they liked. The quality of the program is difficult to control, debugging procedures are cumbersome, programmers are also difficult to read each other's written code. In 1968, Edsger dijkstra wrote a letter to CACM entitled goto statement considered harmful , the concept of software engineering was born. Programmers are beginning to discard their previous practices and instead use more systematic and rigorous development methods. In order to control software development and control other products as strict, people have developed a lot of rules and practices, invented a lot of software engineering methods, the quality of the program has been greatly improved. As more problems are encountered, rules and processes are becoming more sophisticated and complex. Today, in the actual development process, many rules have been difficult to follow, many processes complex and difficult to understand, many projects in the process of document production is out of control. People try to propose a more comprehensive and better package, or hope for more complex, more powerful auxiliary development tools (Case tools), but always fail, and development specifications and processes become increasingly complex and difficult to implement. In order to make progress, programmers often skip some of the specified processes, and few people can fully follow those heavyweight development methods. The reason for failure is simple, there is no panacea in this world. As a result, some people have suggested that the rules and processes in the heavyweight development approach be pruned, restructured, and optimized, resulting in a lot of lightweight processes that adapt to different needs. In these processes, the rules that conform to the actual needs are preserved, unnecessarily complicating the development of the regulations that are discarded. And, compared with traditional development methods, lightweight processes are no longer like pipelining, but more flexible. Extreme programming (XP) is such a smart lightweight software development approach. Why is it called "Extreme" (limit)   "Extreme" (limit)   means that, in contrast to the traditional project development approach, XP emphasizes that each of the methods and ideas that it lists is the limit and best, and that other XP does not advocate, is ignored (such as the overall design of early development, etc.). A strict implementation of XP project, its development process should be smooth, efficient and fast, can do 40 hours a week without delaying the project progress.  XP Software Development is what the 1  limit of the working environment in order to be the largest in the software development processdegree to achieve and meet the basic rights and obligations of customers and developers, XP requires the work environment to do the best. Each person participating in the project development will assume a role (project manager, project supervisor, etc.) and fulfill the corresponding rights and obligations. All people are working in the same open development environment, it would be better for everyone to work in the same big house and refreshments; 40 hours a week, not to encourage overtime; Every morning, everyone stands for a short meeting; there are some big white boards on the wall, all the story cards, CRC cards, etc. When discussing a problem, you can write and draw a picture on it, and you can play computer games together after work ... The requirements of the 2  limit customers should be part of the project development team, rather than being separated from the developer, because the customer has been playing an important role from the project's plan to the final acceptance. Together, developers and customers turn a variety of requirements into small requirements modules (user story), such as "the total number of grades in the calculation, which adds up the number of all classes in the grade." These modules are grouped together or broken down into smaller modules, which are recorded on small cards (Story card) and then implemented by programmers in each small cycle (iteration, usually not more than 3 weeks), respectively. Customers specify their priorities based on the business value of each module; What the developer needs to do is to identify the development risks for each requirement module, which is highly risky (usually because of a lack of similar experience) and will be prioritized for research, exploration, and development; After each module is evaluated from different perspectives by the developer and the customer, They are arranged in different development cycles, and the customer will get a development plan as accurate as possible; the customer assigns acceptance tests (functional tests) to each requirement module. Every time the software is released (through a development cycle), the user gets a system that can be started and the system fully implements all the requirements of the corresponding plan. In some traditional development mode, no matter what function, the user waits until all the development is complete to begin to use.  3  Limit design   from a specific development point of view, the XP inner process is a test-driven development (test driven development) cycle, The outer processes, such as planning and design, are all centered around these. Each development cycle has a number of corresponding unit tests (unit test). At first, because nothing was achieved, all unit tests failed, and as a small demand module was completed, more and more unit tests were passed. In this way, it is easy for both customers and developers to test and fulfill their commitment to the customer. XP advocates for simple design (simple design), is to useThe easiest way to do this is to make the program written for each simple requirement pass through all the relevant unit tests. XP emphasizes abandoning that package of detailed design (Big design up front) because there is a lot of content in this design that you don't need right now or recently. XP also strongly advocates design Review (Review), code review, and re-engineering and optimization (Refectory), all of which are in fact the process of optimizing design, in which unit tests and functional tests are run continuously to ensure that the restructured and optimized systems still meet all requirements.  4  limit programming   since programming is important, XP advocates two people writing the same program (pair programming), and code ownership is attributed to the entire development team (Collective code  ownership). Programmers must strictly follow the programming rules when writing programs and re-engineering optimization programs. Anyone can modify a program written by another person to make sure that the new program passes the unit test.  5  limit test   since testing is important, XP advocates writing unit tests before you start writing programs. Developers should often integrate the developed modules together (continuous integration), run unit tests after each integration, and do any code reviews and modifications to run unit tests; You need to add the appropriate tests (so the XP method does not require a bug database). In addition to unit testing, there are integration testing, functional testing, load testing and system testing. All of these tests are one of the most important documents in the XP development process and one that is ultimately delivered to the user. Key practices and rules in ============================================================ XP 1  Project development team (teams) in XP, Everyone who contributes to a project should be a member of the project development team. Moreover, there must be at least one person in the group who is very clear about user needs, can make demands, determine the business value (priority) of each requirement, and adjust the project plan according to changes in requirements. This person is playing the role of "customer", of course, the best is the actual end user, because the whole project is centered around the end-user needs. Programmers are essential members of the project development team. The team can have testers who help customers develop acceptance tests, have analysts to help customers identify needs, and usually coach (coaches) to track development progress, solve problems encountered in development, and drive projects;The project manager is responsible for allocating resources, assisting communication and communication within and outside the project. There are so many roles in the project team, but that's not to say that everyone does the work that others can't intervene or interfere with, and XP encourages everyone to contribute as much as possible to the project. be equal to each other; This is the best XP development team. The 2  project (planning game), acceptance testing, small release (small releases) XP development team uses a simple approach to project planning and development tracking, and forecasts project progress and steps to determine the future. Depending on the business value of the requirement, the development team carries out a series of development and consolidation for a group of requirements, each of which produces a tested, available system. The planning process for    plan Project XP focuses on two issues in software development: Predicting how much work can be done before the delivery date, and what to do now and next. The answer to these two questions is to directly serve how to implement and adjust the development process; In contrast, it would be less effort to define exactly what the entire development process is going to do and how long everything will take to begin with. In response to these two issues, there are two major corresponding processes in XP: Software release plan (release planning). Customers describe requirements, and developers estimate development costs and risks. The customer develops an approximate project plan based on development costs, risks, and the importance of each requirement. The initial project plan is not necessary (and impossible) to be accurate, because the cost, risk and importance of each requirement are not immutable. Moreover, the plan will be continuously adjusted to be precise in the course of implementation. Cycle Development Plan (iteration planning). During the development process, there should be many stages of planning (for example, one plan every three weeks). Developers may be able to restructure and optimize the system internally (code and design) in one cycle, add new functionality to a cycle, or do both at the same time in one cycle. However, after each development cycle, users should be able to get a system that has implemented some functionality. Moreover, each cycle, the customer will be asked to determine the next cycle to complete the requirements. In each development cycle, developers break down requirements into small tasks and then estimate the cost and risk of development for each task. These estimates are based on actual development experience, the project is much more accurate and accurate in estimating nature, and in the same project, every development cycle, the next estimate will have more experience, reference and basis, thus more accurate. These simple steps provide customers with a wealth of information that allows them to flexibly and efficiently control the development process. Every two or three weeks, customers can actually see what developers have already done. In XP, nothing "is almost done."," completed 90% "vague statement, if not completed, or is not completed. This approach seems to have pros and cons: The advantage is that customers can immediately know what has been done, what is being done, what to do or what to improve, and so on; the downside is that the customer sees what is done and may be dissatisfied or even suspend the contract. In fact, the XP approach is to find the problem early, solve the problem, rather than wait until a few months later, the user finally see the development of the system, and then tell you this is not good, that changed, and add what content and so on.    Acceptance Test the customer defines a number of acceptance tests for each requirement. By running acceptance tests, developers and customers can know whether the software that is being developed meets the requirements. XP developers see these acceptance tests as important as unit tests. In order not to waste valuable time, it is best to automate these testing processes.    frequently small-scale release software (small releases) development requirements for each cycle (iteration) are what users need most. In XP, users should be able to easily evaluate a system that is released at the end of each cycle, or they can be put into actual use. In this way, software development for customers, is no longer invisible things, but real. XP requires frequent software releases and, if possible, a new release every day, and a new version should be released immediately after any changes, consolidations, or new requirements have been completed. The consistency and reliability of these versions is ensured by acceptance testing and test-driven development. 3  simple design, pair programming, test-driven development, re-engineering and Optimization XP programmers not only work together as a development team, but also write the same program for a small development unit with two people. Developers perform simple design, write unit tests and then write code that meets the requirements of the test, and continually optimize the design to meet the requirements. This is what makes beginners feel most puzzled by    simple design XP. XP requires the simplest way to achieve each small requirement, provided that the software developed in accordance with these simple designs must pass the test. These are designed to meet the needs of the system and the customer in the immediate future, without any superfluous design, and all of these designs will be continuously restructured and optimized during the subsequent development process. In XP, there is no single, one-time, overall design for all requirements in the traditional development paradigm. In XP, the design process has almost always been through the development of the project: from project planning to planning for each development cycle (iteration), to simple design for each requirement module, to design review, and continuous design re-engineering and optimization. The whole design process is a spiral, progressive andDevelopment of the process. From this point of view, XP is designed to achieve the ultimate. In   PAIR PROGRAMMINGXP, all the code is written by two programmers on the same machine--one of the most controversial and difficult to implement in XP. This ensures that all code, design, and unit tests are reviewed by at least one other person, improving the quality of code, design, and testing. It may seem like a waste of human resources, but studies have shown that the opposite is true. --  this way of working greatly enhances the work intensity and the working efficiency. Many programmers were forced to try this at first (XP also requires Executive command support). The beginning is always not used to, and two of people's efficiency is not higher than the efficiency of a person. The effect of this practice is often to persist for a few weeks or two months before it can be significant. According to statistics, of all the programmers who have just begun to pair programming, 90% of the people in the first few two months think that this way of working is more efficient. In the development of the project, each person will continue to change the partner of cooperative programming. Therefore, pair programming not only improves the software quality, but also enhances mutual knowledge exchange and update, and enhances the communication and understanding between each other. This is not only beneficial to individuals, but also to the entire project, development teams and companies. From this point of view, pair programming not only applies to XP, but also to all other software development methods.    test-driven development feedback is one of the four basic values of XP-in software development, full feedback can be obtained only through adequate testing. The tests presented in XP are available in other software development methods, such as functional testing, unit testing, system testing, and load testing; the difference is that XP combines tests into its unique spiral incremental development process, and the tests accumulate as the project progresses. In addition, because of the emphasis on the entire development team to have code, testing is also common maintenance. That is, anyone who puts a program (check in) into a code base should run all of the tests; anyone who finds a bug should immediately add a test to the bug, rather than waiting for the person who wrote the program to do it; or modify other people's code and design, after the change, if you can pass all the tests, it will prove that his work is not broken willing system. In this way, the test can really help to get feedback, and by continually prioritizing and accumulating, testing should be able to basically cover all of the customer and development requirements, so developers and customers can get as much feedback as possible.    re-engineering and optimization   (Refactoring) XP emphasizes simple design, but simpleDesign is not a design of the flow of the program, nor is there no structure, the lack of reuse of the program design. While the developer has a simple design for each user story, it is also constantly improving the design process called redesign and optimization (Refactoring). The name first appeared in Martin fowler's written "Refactoring: improving the design of existing code "In this book. Refactoring is designed to reduce the repetition of programs and designs, and to enhance reusability of programs and designs. The concept of refactoring is not an XP initiative, it has been proposed for nearly 30 years, and has been considered to be one of the characteristics of high-quality code. But XP stressed that the refactoring to achieve the ultimate, should be anywhere, whenever possible to carry out refactoring, as long as possible, programmers should not be distressed before the program, but to relentlessly improve the program. Of course, after each change, the programmer should run the test program to ensure that the new system still meets the predetermined requirements. 4  frequently integrates, collectively owning code (COLLECTIVE CODE OWNERSHIP), programming specifications The XP development team often integrates different modules. In order to improve software quality, in addition to test-driven development and pair programming, XP requires everyone's code to comply with programming specifications, anyone can modify the code written by others, and everyone should actively check other people write code.    frequently integrates   (integration ) in many projects, developers tend to integrate modules very late. In these projects, developers often find many problems in the integration process, but it is not certain whose programs are out of the question, and only when the integration is complete, the developer begins to use the entire system slightly and then delivers the acceptance to the customer immediately. For customers, even if these systems can pass the final acceptance test, because the use of time is short, the customer door in the heart is not much grasp. To address these issues, XP proposes that throughout the project process, you should frequently, as much as possible, integrate the user story that have been developed (each time a new user story is consolidated). Each integration should run the corresponding unit test and acceptance test to ensure that the customer and development requirements are met. After integration, a new application system is released. In this way, a new system is released almost every two days during the development of the project, and sometimes several versions are released in a single day. Through thisProcess, the customer is well aware of the functionality and development progress that has been completed and communicates effectively and in a timely manner with the developer to ensure that the project is successfully completed.    Collective Ownership Code (collective code ownership) in many project development processes, developers only maintain their own code, and many people do not like other people to modify their own code. As a result, even though there may be a relatively detailed development document, a programmer is less and less willing to read the code of other programmers, and because it is not clear what other people's programs actually do, a programmer is generally afraid to arbitrarily change other people's code. At the same time, because they maintain their own code, may be due to time constraints or technical limitations, some problems have not been found or better resolved. In this regard, XP advocates common ownership of code, and everyone has the right and obligation to read other code, find and correct errors, restructure and optimize the code. In this way, the code is not only written by one or two of people, but by the entire project development team, the error will be reduced a lot, reusability will be improved as much as possible, code quality is very good. To prevent a system crash from modifying other people's code, everyone should run the test program after the modification. (From this point, we can see again how the various practices and rules of XP are organically combined.)    Programming Specification Everyone in the XP development team follows a unified programming standard, so all the code seems to be written by a single person. Because there is a unified programming specification, each programmer is easier to read other people write code, this is to achieve collective code ownership one of the important prerequisites. 5 metaphor (System analogy), do not work overtime XP process by using some image metaphor to let everyone have a common, concise understanding of the system. XP says overtime is not normal because it indicates a problem with estimating and scheduling the project's progress.     metaphor (System analogy) to help everyone understand the needs of the customer and the system features to be developed, the XP development team uses many figurative metaphors to describe how the system or functional modules work. For example, for a search engine, its metaphor may be "a large group of spiders, searching the web for things to catch, and then bringing things back to the nest." "   does not work overtime means that the original plan is inaccurate, or that the program is far from clear about when it will be able to complete what work." Moreover, development managers and customers are also unable to accurately grasp the development speed, and developers are therefore very tired. XP believes that if there are a lot of overtime nowAs an example, development managers (such as coach) should work with customers to determine the cause of overtime and adjust project plans, schedules, and resources in a timely manner. Introduction to some basic concepts in ============================================================ XP user  Story: Developers ask customers to write all the requirements in a separate story, and each takes only a few days to complete. During the development process, the customer can always propose new user story or change the previous user story. Story estimates and development Speed: the development team estimates each user story and calculates the development speed iteratively based on the actual situation in each development cycle (iteration). This allows developers and customers to know how many user story to develop each week. Release plan and Release scope: Developers will continue to release new versions throughout the development process. Together, the developer and the customer determine the user story that each publication contains. Iteration (development cycle) and Iteration plan: In a release process, the developer asks the customer to choose the most valuable user story as the next two weeks of development content. The seed: The first development cycle (iteration) is completed and submitted to the customer's system. Although this is not the final product, it has implemented several of the most important story that the developer will incrementally add to the new module. Continuous integration (Integration): The development of the user story of the modules assembled together, step-by-step approach to and eventually complete the final product. Acceptance testing (functional testing): For each user story, the customer will define some test cases, and the developer will automate the process of running these test cases. Unit test (unit test): Before beginning to write a program, programmers for most classes of methods, first write the appropriate test procedures. refactoring  (Reorganization and optimization) &NBSP: Remove the redundant parts of the code and increase the reusability and scalability of the code.   A success factor for XP is to focus on customer feedback-The purpose of development is to meet customer needs. The XP approach enables developers to confidently face changes in customer needs. XP emphasizes teamwork, and managers, customers, and developers are all part of the development team。 The team strives to develop high-quality software in a simple but effective way, through full communication and cooperation with each other. XP is designed to be simple and efficient, programmers get customer feedback through tests, and change the code and design as they go, and they always try to deliver the software to their customers as early as possible. XP programmers have the courage to face demands and technical changes. XP is like a lot of small pieces of jigsaw puzzle, alone to see each small pieces have no meaning, but when assembled, a beautiful picture will appear in front of you.