From a project to XP in China Application Qu Junsheng (from IBM DW China) May 03, 2003 At present, China's research and application of XP, all kinds of books on XP are discounted, representing XP represented The debate of "agile software engineering" method is also visible everywhere. This is the case, because the domestic users have encountered many problems during the implementation of the software project, such as the delivery time of the project, frequent user demand changes, our software engineer is urgent, I can find solve problems. " Silver bomb. For high dynamics, through very short iterative cycles to deal with limit programming methodology, it is indeed possible to solve problems to some extent. However, for domestic software development projects, XP is not "silver bomb", some of its best practices are not suitable for domestic situations. This article combines a specific software development project to discuss the application of XP in China. Introduction to XP Traditional Software Development Method In the last decades, many companies' CEOs face the pressure of increased profitability, so they use various methods such as layoffs, business outsourcing, BPR, ERP, CRM, and more. All of the above have enabled most of the world's 500 companies in the late 1990s, have been the growth of the two-digit profit growth. But there are many signs that there is not much place for cut spending in traditional enterprise business models, so thorough reforms are required. This is the case in the field of software development. Since the 1960s, software engineering ideas have gradually formed, and many software development models and methods, such as waterfall models, rapid prototypes, incremental models, and spiral models, etc. [1]. After the 1990s, the CMM launched by Carnegie Melon Software College is the process management of software development, and the exact measurement indicators are proposed. However, recent research shows that there are 50% of the projects will delay delivery, more than 30% of the projects will exceed the budget, the projects in the software development are just a small improvement than when the software engineering has just raised. Detailed data [4] (Data from the US GSM research institution, Michael MAH) as shown in the following table: Traditional software development process, represented by RUP, emphasizing the controllability of the project, is a use case-driven UML and component type Architecture iterative incremental development process. RUP defines the initial, refinement, implementation, and deployment of 4 phases, respectively corresponds to the division of key milestones. RUP is flexible and configurable for roles, processes, artifacts, and activities, so it is widely used for various types of items. However, in various flow stations in RUP, there are specified results to deliver, especially for changes in demand, which emphasizes timely updates and synchronization. These are all determined that RUP is a heavyweight software development method, which is more suitable for large and medium-sized projects and product development. The XP and its core value have recently, many lightweight software development methods, such as crystal models, adaptation models, and limit programming. They all emphasize that software development is the process of cooperation with people. Therefore, the successful software development process should make full use of people's advantages, and weaken the disadvantages, highlight the role of people in software development [2]. Kent Beck's opening of XP "Extreme Programming Explained - EMBRACE CHANGE" is proposed in the ultimate programming of this innovative software process methodology. Extreme programming is a highly dynamic process that responds to demand by very short iterative cycles.
In extreme programming, four basic activities: coding, testing, listening, and feedback, XP project status change as shown below [3] [4]: Kent Beck points out, XP has four core value we should pay attention to [3] [4]: · Communication: The problems found in the project are often caused by the communication between developers and designers, designers and customers, so there is no communication in the XP project. · Simple: XP thinks that you should try to keep your code, as long as it works. Kent Beck pointed out that it is better to design a complex system, it is better to design a simple system that meets the current needs, because the situation you think may never happen. Feedback: Get the user's feedback as soon as possible, the more detail, so that the developer ensures that their results meet the needs of users. · Courage: This is the most important core value. Because XP emphasizes "hug changes", so for users' feedback, we must be modified to our code, throw away bad code. Best of the best practices we will talk about by our we will refer to the above four core value. In fact, there is not much new view in XP, some of its best practices are also in use. XP Applicable Environment From the XP project status diagram and its core value we can see that XP Weakly designs for future demand, very focused on current simplification. Its practice, there is a very critical hypothesis that the developers only pay attention to the risk and overhead of the need to rely on the demand to adapt the risk and overhead of the demand, which makes the price change make prior design failure; contrary, implement XP is Unexplus [5]. Therefore, XP is suitable for projects that are small, tight, demand, and strict quality requirements. It hopes to solve the user's current problem with the highest efficiency and quality, to meet the future needs of the user with the biggest flexibility and the minimum, and XP has made a clever choice between the balance between short-term and long-term interests. We can see that XP is not a "silver bomb" to solve the problem, and it is not suitable. BECK has been suggested that it is not advisable to use XP: · Middle-scale projects in the following situations (the project team more than 10 people); · Reconstructing will result in a large number of overhead applications; The application of the test; · Team staff distributed projects; · Cannot receive organizations and teams of XP culture; project profiles and backgrounds Our company is an Asian leading e-commerce solution provider, rich experience in the J2EE architecture project implementation Combined with RUP forms its own e-commerce project implementation methodology, and successfully implemented in multiple projects.
At the same time, many problems have also occurred due to the limitations of specific project time and cost, mainly below: After the delivery, users have proposed a lot of modified opinions, and some even involve a modification of the system architecture: the main reason for this situation is Although many projects use incremental iterative development cycles, they only release the version before deployment. Users only see the real system after the project deployment, so many interfaces, processes, etc. will be found; for users to submit bugs The modified cycle is too long: the developer is in the development of the unit test, and the module is submitted to the test personnel after the module development is completed, and the test personnel do not find all the problems; After the user submits BUG, the developer has generated inert due to the completion of the project, and does not form a valid regression test method. Therefore, the modified cycle is relatively long. For the core value of XP, it can be seen that if we can strengthen communication with users, increase the intensity of test implementation in the project, improve the courage of developers, you can solve the above problems to some extent. Since 2001, the company's internal development of XP and other agile methods, hoping to learn from some practices to improve project methodology. In May 2002, we decided to check some of the best practices in XP in a new project of the company to test their effects. The project is a partner of an internationally renowned mobile phone manufacturer, providing mobile phone accessories or other services, and the project is as shown in the following table: It can be seen from the above table, the project is a small project, and the project team Members have certain understandings for XP before the start of the project, on the other hand, the project cycle required by the customer has certain rooms than the estimated time we expect, so we decided to use this project to perform XP experimental practice. The best practice of XP and the application in the project in the project implementation process, we basically use the RUP software process, without the set of XP, for example: in the demand analysis phase, we use Use case to Demand is described, not the CRC card specified by XP; in system analysis and design phase, the system architecture design is first performed, not simple set of "simple design" practices. Let's discuss 12 best practices in XP in conjunction with the specific circumstances of the project. On-Site Customer · XP: Requires at least one actual customer representative to determine the demand, answer team issues and write function acceptance tests throughout the project development cycle. · Review: On-site users can solve problems with the incomplete communication between project teams and customers to some extent, but for domestic users, there is currently no guarantee that customers with certain technical levels in the development site. There are two ways to solve the problem: First, it can be used in the customer's on-site development; the other is to use effective communication. · Project: First, before the signing of the project contract, we introduce the customer to the customer, so that the customer knows the stage of the project, the results of the project to be released, and the support required by customers; secondly, the project manager weekly Report the progress of the project to the customer, provide the current release of the version and prompt the customer system corresponding feedback and support. Code Standards · XP: Emphasize communication through a specified strict code specification, minimizing unnecessary documentation.
· Commentary: XP has a dual meaning of code specification: one is to strengthen communication between developers through the establishment of a unified code specification, and provide a certain standard for code-seeking; second, hope to reduce project development Document in the process, XP thinks that the code is the best document. For most project teams currently in China, establish a valid code specification, strengthen the unity of team within the team, it is for granted; however, it is not advisable to replace the document, because the code readability and specification The document is compared to a certain gap. At the same time, if there is no unified code specification, all the code is not talking about it. · Project: In the early stage of the project, the code specification is established by the technical manager of the project and the standard for code review. 40-hour work system (40-hour week), XP: The project team will not work more than 40 hours a week, and the overtime will not have more than two weeks, otherwise it will affect productivity. · Comment: This practice fully reflects the "people-oriented" principle of XP. However, if you want to real implementation, the requirements for project progress and reasonable amount of workload are relatively high. · Project: Because the project is relatively abundant, it is very fortunate that we have not violated the practice. Planning Game XP: Requires Combination of Project Progress and Technology, Determines the system range to develop and publish in the next stage. · Commentary: After the project is planned, it needs to be adjusted according to the progress of the project, and a constant plan is not existed. Therefore, the project team needs to control risks, foresee changes, thereby developing effective, feasible project plans. · Project: Before the system implementation, we first make the iterative cycle division according to the priority of the needs, and give the demand for high risk first; at the same time, the project team participates in a 15-minute project meeting every morning, determines the day and the current iterative cycle. The task of each member to be completed. System metaphor · XP: How to operate in how the system is operated by metaphor, and new features are added to the system. It usually contains some classes and design patterns that can refer to and compare. XP does not require a detailed architecture design in advance. · Review: XP does not require a detailed architectural design in the initial stage of system implementation, but constantly refine the architecture in iterative cycles. For small systems or architectural analysis, the step-by-step refinement system architecture is possible; however, for large systems or systems that need to adopt a new architecture, they need to believe in the initial period of the project. The system architecture is designed and verified in the first iterative period while gradually refining in the subsequent iterative cycle. · Project: The development team built a project framework for workflow processing in the initial stage of design, decided to refer to the Struts framework, combined with the project. First, the team decided to implement the workflow application application application in the first iterative cycle, verify the basic program framework in the actual project development; then, in other iterative cycles, the frame is gradually refined. Simple Design · XP: Think of the design of the code as simple as possible, as long as the current function is met, there are not many. · Commentary: Traditional software development process, for design is from top, emphasizing design first, there is a perfect design model before the code starts writing.
Its premise is that the demand does not change, or few changes; and XP believes that the demand will change frequently, so the design cannot be a process, but should be a continuous process. Kent Beck believes that for XP, simple design should meet the following principles: 1. Successfully implement all tests; 2. Do not include duplicate code; 3. Clearly describe coding to all developers; 4 To include the least possible class and methods. For most software development organizations in China, a flexible system architecture should be first determined, and then the simple design principle of XP can be used in the design phase of each iterative period. · Project: In the project system architecture, we have always adhered to the principle of simple design and conduct effective verification in accordance with the four principles of Kent Beck. For the new iterative cycle, you need to modify the condition of both design and code, first "Code Reconstruction" in the original system, and then add new functions. Test-Driven · XP: emphasizes "test first". Before the encoding begins, the test is written, and then the encoding is performed until all the tests are passed. · Commentary: RUP and XP are very valued for testing, but both are different from the first position in the entire project development cycle. XP is a test-driven software development process. It is believed that the test first makes developers have enough confidence in their own code, and also have courage to reconstruct. Test should achieve a certain automation, and can clearly give the results of success or failure. In this regard, the XUnit test framework has done a lot of work, so many teams implement XP are tested by them. · Project: We have a certain study of JUnit in the initial stage of the project, in the project code, using the test framework of JBuilder6 provided by the test class. However, it is not written for all methods and the use case, but only for critical method classes, important business logic processing classes. Refactoring · XP: Emphasize code reconstruction in it, believes that developers should reconstruct, usually two key points should be reconstructed: for a functional implementation and implementation. · Review: Code Reconstruction refers to re-adjusting, optimizing the internal structure of the system without changing system behavior to reduce complexity, eliminate redundancy, increase flexibility, and improve performance. Reconstruction is not unique to XP, which may occur during any development process. Be careful when using code reconstruction, do not excessively dependent reconstruction, even despise design, otherwise, for large and medium-sized systems, it will delay or simply do not design, it will cause a disaster. · Project: We deploy the JREFActory tool to the JBuilder in the project to reconstruct the code, and the reconstruction time is before and after each iterative cycle. The role of code reconstruction in the project is to improve both design, not instead of design. Pair Programming · XP: It is considered to be more effective than programming in the project than alone. The pair programming is a code that co-writes the same problem on the same computer on the same computer, usually a person is responsible for writing the code, and the other is responsible for ensuring the correctness and readability of the code. · Commentary: In fact, paired programming is an informal conventional review. It requires two developers of programmed developers to match each other in personality and skills, and is still not very suitable promotion in China.
The pair programming is only a way to strengthen the communication and review of the developer, not the only way. Specific ways can be carried out in conjunction with the project. · Project: We did not use pair of programming practices in the project, but in all stages of project implementation, we have strengthened the intensity of the exam and the intensive review. Demand acquisition, design and analysis have multiplayer, after the results are submitted, cross-performing; and during the coding phase, between the developers should be reviewed simultaneously after each iterative cycle. · XP: Every member of the development team has the right to change the code, and all people are responsible for all code. · Comment: All of the whole code that does not mean that developers can commit responsibility, but emphasize all people to be responsible. If a developer's code is wrong, another developer can also fix bug. At present, domestic software development organizations can implement this practice to some extent, but it is necessary to pay attention to strict code control management. · Project: In the early days of the project development, we first talked to the development team "code all" "education, while requiring developers to not only understand the architecture of the system, but also to understand the work of other developers and code. This practice has a certain complementary role with the same level review, so that the changes in personnel will not have a big impact on the progress of the project. In the project execution, there is a developer to perform a week of participating in the training. Due to the practice of "all ownership of the code", other developers have successfully shared the test and development task of the member to ensure that the project is as scheduled. deliver. Continuous Integration · XP: Advocates that the integrated system in one day is multiple times, and as the demand changes, the regression test should be continuously tested. Because, this can keep the team a high development speed while avoiding a system integrated nightmare. · Commentary: Continuous integration is not the best practice of XP, and the famous Microsoft has a successful practice of Daily Build. However, it should be noted that continuous integration also requires a good software configuration change management system effective support. · Project: Using VSS as a software configuration management system, adhere to system integration every day, and effectively combine the completed function, test. Small Release · XP: Emphasized in a very short cycle to increment a new version, so it can easily estimate the progress of each iterative cycle, easy to control workload and risk; at the same time, it can also be handled in time User feedback. · Comment: Small release highlights the advantages of agile methods. RUP emphasizes iterative development, and there is no excessive rule for the publishing of the system. After the user is submitted, the real system can only be seen when deploying, so it is not conducive to quickly obtaining feedback from users. If you can guarantee the best practices such as test priority, code reconstruction, continuous integration, and implement small publishing is not a difficult thing, and you can use it in conditioned organizations. · Project: The project has configured a test and publishing server in the preparation stage. In the process of project implementation, a small release is performed every two weeks (after an iterative cycle); the user is within two working days after the release The project team submits the "User Receive Test Report", and the project manager evaluates the test report to submit a valid bug to the Rational Clear Case and assigned to the corresponding developer. The project team should fix the issues submitted by all users before the next iterative cycle.
