What Is Programming Productivity?

Extreme Programming (XP for short) was proposed by KentBeck in 1996. It is a software engineering methodology and one of the most productive methodologies in agile software development. As with other agile methodologies, the fundamental difference between Extreme Programming and traditional methodologies is that it places more emphasis on adaptability and difficulties. In March 1996, Kent finally introduced a new software development concept, XP, into a project for DaimlerChrysler. Suitable for small team development.

Extreme Programming is a lightweight and smart software development method; it is also a very rigorous and thorough method. Its foundation and values are communication, simplicity, feedback, and courage; that is, any software project can be improved from four aspects: strengthen communication; start from simple; seek feedback; be courageous and realistic.

XP is a near-spiral development method, which breaks down the complex development process into relatively simple small cycles; through active communication, feedback and other series of methods, developers and customers can be very clear about the development progress , Changes, unresolved issues, and potential difficulties, and adjust the development process in a timely manner based on the actual situation.

The main goal of Extreme Programming is to reduce the cost of changing requirements. In traditional system development methods,

The basic characteristics of the Extreme Programming method are:

• Incremental and iterative development-once small

  There are four core values in Extreme Programming that we must pay attention to in development:

  Communication (Communication), simplicity (Simplicity), feedback (Feedback), courage (Courage), in addition to the fifth value: Respect (Respect).

  XP uses "communication, simplicity, feedback, courage and respect" to reduce development pressure and burden; whether it is terminology, monograph narrative content and methods, process requirements, you can feel relaxed and happy attitude and atmosphere. This is a means to help understand and more easily inspire people's potential. XP uses its own practice to successfully break the traditional concept of software engineering "must weigh" in order to succeed.

  The XP spirit can inspire us how to learn and treat fast-changing, diverse development technologies. The key to successfully learning XP is to treat XP with an attitude of "communication, simplicity, feedback, courage and respect"; to experience XP's practical ideas easily and happily; after earnest practice, determine XP through analysis of real feedback. Value to yourself; have the courage to accept it, or improve it.

  Based on agile core ideas and value goals, XP requires project teams to follow 13 core practices

  XP's planning process addresses two issues in software development: predicting how much work can be completed before the delivery date; and what to do now and next. Continually answering these two questions is directly serving how to implement and adjust the development process. Compared to this, I hope that at the beginning, you will precisely define what the entire development process will do and how much time each will take, then you will get twice the result with half the effort. In response to these two issues, XP has two main corresponding processes:

  Software Release Planning (ReleasePlanning). Customers articulate requirements, and developers estimate development costs and risks. The client develops a rough project plan based on development costs, risks, and the importance of each requirement. The initial project plan is not necessary (and impossible) to be very accurate, because the development costs, risks, and importance of each requirement are not static. Moreover, the plan will be continuously adjusted to be precise during the implementation process.

  Cycle Development Planning (IterationPlanning). During the development process, there should be many stages of planning (such as one every three weeks). Developers may reorganize and optimize the system (code and design) internally in a certain cycle, add new features in a certain cycle, or do both tasks in one cycle. However, after each development cycle, users should be able to get a system that has already implemented some functions. Moreover, each time a cycle passes, the customer will come up with a request to determine the next cycle to complete. In each development cycle, the developer breaks down the requirements into small tasks and estimates the development costs and risks of each task. These estimates are based on actual development experience. The project has been done a lot, and the estimates are naturally more accurate and accurate. In the same project, each time a development cycle passes, the next estimation will have more experience, reference and basis, so more precise. These simple steps provide customers with rich and sufficient information to enable them to flexibly and effectively regulate the development process. Every two or three weeks, customers can always see the requirements that developers have completed. In XP, there are no vague terms "it's almost complete" and "90% complete", either it's complete or it's not complete. This approach seems to have advantages and disadvantages: the advantage is that the customer can immediately know what has been completed, whether the work is suitable, what is to be done or improved next, and so on; the disadvantage is that the customer sees the work, and may Will be very dissatisfied or even terminate the contract. In fact, XP's approach is to find and solve problems early, instead of waiting for a few months before the user finally sees the developed system, and then tell you that this is not working, that is changing, and it is increasing. Which content and so on.

  The customer defines some acceptance tests for each requirement. By running acceptance tests, developers and customers can know whether the software developed meets the requirements. XP developers consider these acceptance tests as important as unit tests. In order not to waste valuable time, it is best to automate these testing processes.

  Frequent small-scale software releases (SmallReleases)

  Every cycle (Iteration) development needs are what users need most. In XP, users should be able to easily evaluate the system released at the completion of each cycle, or they can already be put into practical use. In this way, software development is no longer invisible to customers, but it is real. XP requires frequent software releases. If possible, a new version should be released every day; and after any changes, integrations, or new requirements are completed, a new version should be released immediately. The consistency and reliability of these versions is ensured by acceptance testing and test-driven development.

  This is what confuses beginners most in XP. XP requires the simplest way to achieve every small requirement, provided that the software developed according to these simple designs must pass the test. As long as these designs can meet the current needs of the system and customers, it does not need any superfluous designs, and all these designs will be continuously reorganized and optimized in the subsequent development process.

  In XP, there is no one-time overall design for all requirements in the traditional development model. In XP, the design process almost always runs through the entire project development: from making a project plan, to making a plan for each development cycle (Iteration), to simple design for each requirement module, to design review, Intermittent design reorganization and optimization. The entire design process is a spiral, continuous progress and development process. From this perspective, XP is the ultimate design.

  PairProgramming

  In XP, all code is written by two programmers on the same machine-this is the most controversial and most difficult to implement in XP. This ensures that all code, design, and unit tests have been reviewed by at least one other person, and the quality of the code, design, and tests has improved. It may seem like a waste of human resources, but various studies have shown the opposite. This way of working has greatly improved the intensity and efficiency of work.

  Many programmers were forced to try this at the beginning (XP also needs administrative order support). It's always unaccustomed at the beginning, and two people will not be more efficient than one. The effect of this approach is often not significant until several weeks or a month or two. According to statistics, 90% of all programmers who have just started PairProgramming think that this way of working is more efficient after two months.

  In project development, everyone will constantly change the partner of cooperative programming. Therefore, PairProgramming not only improves the quality of the software, but also enhances the exchange and update of knowledge between each other, and enhances the communication and understanding between each other. This benefits not only individuals but also the entire project, development team and company. From this point of view, PairProgramming applies not only to XP, but also to all other software development methods.

  Feedback is one of the four basic values of XP-in software development, only sufficient testing can get sufficient feedback. The tests proposed in XP can be seen in other software development methods, such as functional testing, unit testing, system testing, and load testing. What is different is that XP combines testing with its unique spiral incremental type. During the development process, testing continues to accumulate as the project progresses. In addition, because it is emphasized that the entire development team has the code, the tests are also maintained by everyone. That is, anyone should run all tests before putting a program (CheckIn) in the code base; if anyone finds a bug, they should immediately add a test for the bug, rather than waiting for the person who wrote the program To complete; anyone taking over other people's tasks, or modifying other people's code and design, if all tests can pass after the change, it proves that his work has not destroyed the original system. In this way, testing can really help get feedback; and, by continuously writing and accumulating, testing should basically cover all customer and development needs, so developers and customers can get as much feedback as possible.

  Everyone on the XP development team follows a unified programming standard, so all code looks like it was written by one person. Because of the unified programming specifications, each programmer can more easily understand the code written by others, which is one of the important prerequisites for implementing CollectiveCodeOwnership.

  40-hour Week (without overtime)

  The XP process allows all people to have a common and concise understanding of the system by using some metaphors. XP believes that overtime is abnormal because it indicates a problem with the estimation and scheduling of the project.

  Metaphor (system metaphor)

  In order to help everyone understand the customer needs to be completed and the system functions to be developed, the XP development team uses many metaphors to describe how the system or function module works. For example, for a search engine, its Metaphor might be "a swarm of spiders, looking around for something to catch, and then bringing it back to its nest."

  A lot of overtime means that the original plan was inaccurate, or the programmer didn't know exactly when he could get the job done. What's more, development managers and customers can't accurately grasp the development speed; developers are also very tired. XP believes that if there is a large amount of overtime, 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

  UserStory: The developer asks the customer to write all the requirements into individual small stories, each of which takes only a few days to complete. During the development process, customers can propose new UserStory at any time, or change the previous UserStory.

  StoryEstimates and development speed: The development team estimates each UserStory and repeatedly calculates the development speed based on the actual situation in each development cycle (Iteration). This way, developers and customers know exactly how much UserStory can be developed each week.

  ReleasePlan and ReleaseScope: Throughout the development process, developers will continue to release new versions. Developers and customers work together to determine the UserStory included in each release.

  Iteration (development cycle, or iteration) and IterationPlan: During a Release process, the developer asks the customer to select the most valuable UserStory as the development content for the next week or two.

  TheSeed: The system submitted to the client after the first iteration is completed. Although this is not the final product, it has achieved several stories that customers consider to be the most important, and developers will gradually add new modules to it.

  ContinuousIntegration (integration): Assemble the developed UserStory modules one by one, step by step closer to the final product.

  Acceptance test (functional test): For each UserStory, the customer will define some test cases, and the developer will automate the process of running these test cases.

  UnitTest (Unit Test): Before starting to write a program, the programmer writes the corresponding test program for the methods of most classes.

  Refactoring (refactoring): remove redundant parts of the code, increase the reusability and scalability of the code.

  The XP method is generated because of difficult changes in management requirements. From the beginning, your customers did not fully know what the system they wanted, and the functions of the system you may face have changed several times a month. In most

  1.Complete team

  All participants in the XP project (developers, customers, testers, etc.) work together in an open space, and they are members of the same team. Large, prominent charts and other things hung on the walls of this place randomly show their progress.

  2.Plan the game

  The plan is continuous and gradual. Every two weeks, developers estimate the cost of candidate features for the next two weeks, and customers choose features to implement based on cost and business value.

  3.Customer test

  As part of selecting each desired feature, customers can define an automated acceptance test based on a scripting language to show that the feature works.

  4.Simple design

  The team keeps the design just right with the current system capabilities. It passes all tests, contains no repetitions, expresses everything the writer wants to express, and contains as little code as possible.

  5.Pair programming

  All production software is built by two programmers sitting side by side on the same machine.

  Test-driven development

  Writing unit tests is a verification act, but it is also a design act. Again, it's more a documenting behavior. Writing unit tests avoids a significant number of feedback loops, especially in the area of functional verification. Programmers work in very short loops. They add a failed test and then pass it.

  7.Improved design

  Use refactoring methods to improve the corrupted code at any time, keeping the code as clean and expressive as possible.

  8. Continuous integration

  The team always makes the system completely integrated. After one person checks in, everyone else is responsible for code integration.

  9. Collective code ownership

  Any pair of programmers can improve any code at any time. No programmer is solely responsible for any particular module or technology, and everyone can participate in any other aspect of development.

  Coding standards

  All the code in the system looks as if it were written by a single person.

  11.Metaphor

  A global view that links the entire system together; it's the future image of the system, and it's the location and appearance of all individual modules that are clearly intuitive. If the appearance of the module does not match the whole metaphor, then you know that the module is wrong.

  12.Sustainable speed

  Teams can only hope to win if they last. They work hard at a rate that they can sustain for a long time, they save energy, they see the project as

  One of the success factors of XP is to value customer feedback-the purpose of development is to meet customer needs. The XP approach enables developers to always confidently respond to changes in customer needs. XP emphasizes teamwork, and managers, customers, and developers are part of the development team. Through full communication and cooperation with each other, the team strives to develop high-quality software using XP as a simple but effective way. XP's design is simple and efficient; programmers get customer feedback through testing and modify code and designs based on changes, and they always strive to deliver software to customers as early as possible. XP programmers have the courage to face changes in requirements and technology.

  XP is like an intellectual jigsaw made up of many small pieces. It doesn't make sense to look at each piece individually, but once assembled, a beautiful picture will appear in front of you.