On the application of XP in China from a project

The project at present in the domestic research and application of XP, all kinds of books on XP competing for publication, for XP as the representative of the "Agile Software Engineering" approach is also available on the network. This situation occurs because the domestic users in the implementation of the software project encountered a lot of problems, such as the project delivery time delay, user needs change frequently, our software engineers are eager to find a solution to the problem of the "silver bullet." For extreme programming methodologies that are highly dynamic and respond to demand changes through very short iterations, it is true that the problem can be solved to some extent. However, for domestic software development projects, XP is not a "silver bullet", some of its best practices are not suitable for domestic situations. This article unifies a concrete software development project, discusses the XP in the domestic application situation.

Introduction to XP

Traditional software development methods

In recent decades, CEOs of many companies have been under pressure to increase profitability, so they use a variety of methods, such as layoffs, outsourcing, BPR, ERP, CRM, and so on. All of these, making most of the world's top 500 companies in the late the 1990s has been maintained by two-digit profit growth. But there are many indications that there is little to be done to cut spending in traditional business models, and that there is therefore a need for radical reform. This is especially true in the area of software development.

Since the 60 's, the concept of software engineering has formed and developed, and many models and methods have been developed, such as waterfall model, rapid prototyping, increment model and helix model, etc. [1]. After the 90 's, Carnegie Mellon Software Institute launched the CMM, but also for the software development process management, put forward the exact measurement index. However, recent research has shown that 50% of projects will be delayed delivery, more than 30% of the project will exceed the budget, software development in the field of projects than the software project just when compared to a small improvement. Detailed data [4] (data from the US GSM Research Institute, Michael Mah) are shown in the following table:

The traditional software development process, which is represented by RUP and emphasizes the controllability of the project, is a use-case driven iterative incremental development process based on UML and component architecture. RUP defines the 4 phases of inception, refinement, implementation, and deployment, respectively, corresponding to the partitioning of key milestones. RUP's requirements for roles, processes, artifacts, and activities are flexible and configurable, so it is widely applicable to various types of projects. However, the RUP's various process monuments provide the deliverables, especially for changes in requirements and documentation, which emphasize timely updates and synchronization. These all determine that RUP is a heavyweight software development approach that is more suitable for large and medium-sized projects and product development.

XP and its core values

Recently, there have been a lot of lightweight software development methods, such as crystal model, adaptive model and extreme programming. They all emphasize that software development is the process of cooperation between people, so the successful software development process should make full use of people's advantages, and weaken human shortcomings, highlighting the role of people in the software development process [2].

Kent Beck in the opening of XP, "Extreme programming Explained-embrace Change" in the introduction of extreme programming this innovative software process methodology. Extreme programming is a highly dynamic process that uses a very short iterative cycle to respond to changes in demand. In extreme programming, there are four basic activities: coding, testing, listening and feedback, and the state transitions of XP projects are shown in the following illustration [3][4]:

Kent Beck points out that XP has four core values that we should pay attention to [3][4]:

Communication: Problems found in projects are often caused by poor communication between developers and designers, designers, and customers, so it is not possible to communicate in an XP project.

Simple: XP thinks it's better to keep the code as simple as possible, as long as it works. Kent Beck points out that rather than implementing a complex system, it is better to design a simple system that meets the needs of the moment, because the situation you are considering may never happen.

Feedback: Get the user's feedback as soon as possible, and the more detailed the better, so that developers can ensure that their results meet the needs of users.

Courage: This is the most important core value. Because XP emphasizes to "embrace change", so for the user's feedback, the courage to modify their own code, discard bad code.

Here are the four core values that we're going to talk about in the best practices of XP. In fact, there are not many new ideas in XP, and some of its best practices have long been in use.

The application environment of XP

From the XP project status diagram and its core values we can see that XP weakens the design for future requirements and focuses on the current simplification. Its practice, there is a very critical assumption is that developers only focus on immediate needs and rely on refactoring to adapt to the changes in requirements of the risk and cost is less than the change in requirements to make the full design of the cost of failure, on the contrary, the implementation of XP is unwise [5].

As a result, XP is suitable for projects with small scale, tight schedule, big changes in demand and strict quality requirements. It wants the highest efficiency and quality to solve the user's current problems, with the greatest flexibility and the smallest cost to meet the needs of the user's future, XP in the balance between short-term and long-term benefits made a clever choice.

As we can see, XP is not a "silver bullet" to solve the problem, it also has an unsuitable situation. Beck has suggested that XP should not be used in the following situations:

Medium and large projects (more than 10 project teams);

Refactoring can lead to a lot of overhead applications;

A system that requires a long compilation or test cycle;

Not easy to test the application;

Projects distributed by team members in different places;

Organizations and teams that cannot receive XP culture;

Project Overview and background

Our company is Asia's leading E-commerce solution provider, in the Java EE Architecture Project implementation has a wealth of experience, combined with RUP to form a set of their own E-commerce project implementation methodology, and in a number of projects successfully implemented. At the same time, due to the specific project timing and cost constraints, there are also many problems, mainly the following two points:

After the project was delivered, the user made a lot of changes, some even involve changes to the system architecture: the main reason for this is that many projects, although using an incremental iterative development cycle, are released before deployment, and users only see the real system after the project is deployed, so many interfaces, Process and other aspects of the problem;

The modification cycle for a user committing a bug is too long: developers in the development of time, the importance of unit testing is not enough, the module development after the completion of the test staff to carry out the test, and the tester due to the time of the relationship, can not find all the problems; After the user submits the bug, the developer is nearing the end of the project, For the modification of the code to produce inertia, but also did not form an effective regression test method, therefore, the modified cycle is relatively long.

As for the core value of XP, we can see that if we can strengthen communication with users, increase the intensity of test implementation in the project, and enhance the courage of the developers, we can solve the above problems to some extent.

From the beginning of 2001, the company's internal expansion of the agile methods such as XP research, hope to be able to learn from some practices to improve the project methodology.

In May 2002, we decided to test the effect by enabling some of the best practices for XP in a new project in the company. The project is a well-known international mobile phone manufacturers partners to provide mobile phone accessories ordering, application, recycling and other services, the project situation as shown in the following table:

As you can see from the table above, the project was a small project, and the team members had a certain understanding of XP before the project started, on the other hand, the customer requested a project cycle that was more than we expected, so we decided to use the project for XP pilot practice.

XP best practices and applications in projects

During the execution of the project, we are basically using the RUP software process, without the rigid application of XP, for example: in the requirements analysis phase, we are using use cases to describe the requirements, rather than the CRC card required by XP; In the system analysis and design phase, the first system architecture design , rather than simply applying XP's "simple design" practices.

Let's discuss XP's 12 best practices in conjunction with the specifics of the project.

Onsite customers (on-site customer)

XP: Requires at least one actual customer representative to be responsible for identifying requirements, answering team questions, and writing functional acceptance tests on the site throughout the project development cycle.

Comments: Site users can solve the problem of poor communication between project team and customers to some extent, but for domestic users, the current stage can not guarantee a certain technical level of customer resident development site. There are two ways to solve the problem: one is to use the method of on-site development in the customer, and the other is to use effective communication methods.

Project: First of all, we introduce the project development methodology to the customer before the project contract is signed, so that the customer is clear about the stage of the project development, the results to be released at each stage and the support required by the customer, and secondly, the project manager reports the progress of the project to the customer weekly and provides the current release position. and prompts the customer system corresponding feedback and the support.

Code specification (standards)

? XP: Emphasize the need to communicate by specifying strict code specifications to minimize unnecessary documentation.

? Comments: XP for the practice of code norms, has a dual meaning: first, the hope that through the establishment of a unified code to enhance communication between developers, while the code for the search provides a certain standard; the second is to reduce the documentation in the project development process, XP believes that the code is the best document.

For most of the current domestic project team, the establishment of effective code specifications, strengthen the unity of the code within the team, is taken for granted; however, it is undesirable to think of code as a substitute for a document, because the readability of the code is a certain gap from the specification document.

At the same time, without a unified code specification, it is impossible to talk about the entire code.

Project: At the beginning of the project implementation, the technical manager of the project establishes the code specification and takes it as the standard for code review.

40-hour work per week (40-hour Week)

XP: Require project team members to work less than 40 hours a week, overtime should not be more than two consecutive weeks, otherwise it will affect productivity.

Comment: This practice fully embodies the "people-oriented" principle of XP. However, if the real implementation, the project schedule and the workload of the reasonable arrangement of requirements are relatively high.

Project: Because the project has a relatively good duration, we are fortunate that we have not violated the practice.

Plan game (Planning Game)

XP: Requires a combination of project progress and technical information to determine the system scope to be developed and published in the next phase.

Commentary: When the project plan is established, it needs to be adjusted according to the progress of the project, and the invariable plan does not exist. As a result, project teams need to control risk and anticipate change to develop effective and workable project plans.

Project: Before the system implementation, we first in accordance with the needs of the priority to do the iteration cycle of the division, the high risk of the needs of priority implementation; At the same time, the project team attends a 15-minute project meeting every morning to determine what each member will do for the day and the current iteration cycle.

Systems metaphor (System metaphor)

XP: Metaphor is used to describe how the system works, and how new features are added to the system. It usually contains a number of classes and design patterns that can be referenced and compared. XP does not require a detailed architectural design in advance.

Comment: XP does not require detailed architectural design at the beginning of the system implementation, but it continuously refines the architecture in the iterative cycle. The analysis of a small system or architectural design will delay the overall project plan, it's OK to step through the system architecture, but for large systems or systems that want to adopt a new architecture, you need to have a trusted system architecture design at the beginning of the project and validate in the first iteration cycle, It is also progressively refined in subsequent iterations.

Project: In the early stages of design, the development team decided to build a project framework for workflow processes, taking into account the struts framework and the project situation. First, the team decided to implement the workflow of the component application in the first iteration cycle, validating the Basic program framework in the actual project development, and then refining the framework in other iterations.

Simple design

XP: Think of code design should be as simple as possible, as long as the requirements of the current function, not much nor many.

Review: The traditional software development process, for the design is Top-down, emphasizing design first, before the code to write, to have a perfect design model. The premise is that the demand does not change, or it rarely changes, and XP believes that the requirements are constantly changing, so the design can not be done overnight, but should be an ongoing process.

Kent Beck thinks that for XP, simple design should meet the following principles:

1. Successful implementation of all tests;

2. Does not contain duplicate code;

3. Clearly describe the coding to all the developers and their internal relationships;

4. Include the fewest classes and methods possible.

For most of the domestic software development organizations, should first determine a flexible system architecture, and then in each iteration cycle design phase can be used XP simple design principles, will be designed to the end.

Project: In the iterative cycle after the project's system architecture has been validated, we always adhere to the principle of simple design and validate it in accordance with the four principles of Kent Beck. For the new iteration cycle, there is a need to modify the existing design and code, first of the original system "code refactoring", and then add new features.

Test driver (Test-driven)

XP: Emphasize "test first". Before coding begins, write the test first and then code until all the tests pass.

Commentary: Rup and XP are very important for testing, but they are different for testing where the first occurrence of the entire project development cycle occurs. XP is a test-driven software development process that believes that testing leads developers to have enough confidence in their own code, as well as the courage to refactor code. Testing should be done with a certain degree of automation while clearly giving the results of a test success or failure. In this context, the Xunit test framework does a lot of work, so many of the teams that implement XP use them for testing.

Project: We have done some research work on junit in the early stage of the project, in the project coding, using the test framework provided by JBUILDER6 to write the test class. However, not all methods and use cases are written, but only for key method classes, important business logic processing classes, and so on.

Code refactoring (Refactoring)

XP: Emphasize the role of code refactoring, that developers should often refactor, there are usually two key points should be refactoring: for a feature implementation and implementation.

Commentary: Code refactoring is the ability to readjust and optimize the internal structure of the system without changing the behavior of the system to reduce complexity, eliminate redundancy, increase flexibility, and improve performance. Refactoring is not a behavior that is specific to XP and can and should occur in any development process.

In the use of code refactoring should be careful not to rely too much on refactoring, or even despise the design, otherwise, for large and medium-sized systems, the design will be postponed or simply not design, will cause a disaster.

Project: We deploy the Jrefactory tool to the JBuilder in the project to refactor the code, and the refactoring time is before and after each iteration cycle. The role of code refactoring in projects is to improve both design and not replace design.

Pair programming (Pair programming)

XP: It is more efficient to use pair programming in a project than to program alone. Pair programming is where two developers work together on the same computer to write code that solves the same problem, usually one person is responsible for coding, and the other is responsible for ensuring that the code is correct and readable.

Commentary: In fact, pair programming is an informal peer review (Peer Review). It requires that the two developers of pair programming should match each other in character and skill, which is not quite suitable for promotion at home. Pair programming is just a way to strengthen the communication and review of developers, not the only way. Specific ways can be combined with the situation of the project.

Project: We do not use in the project of the practice of programming, but in the implementation of the project at all stages, strengthening the audit and peer review of the strength. Demand acquisition, design and analysis are involved in many people, after the results submitted, cross to check, and in the coding phase, the developer should be in the same time after each iteration cycle review.

XP: Each member of the development team has the right to change the code, and all the people are responsible for the entire code.

Comments: Code ownership does not imply that developers can push each other's responsibilities, but that all people are responsible. If a developer's code is wrong, another developer can fix the bug.

At present, the domestic software development organizations can implement the practice to some extent, but at the same time need to be aware of strict code control management.

Project: In the early stages of project development, we first gave the development team a "code ownership" education, and asked the developers not only to understand the architecture of the system, their own code, but also to understand the work of other developers and the code. This practice and peer review have a certain complementary role, so as to ensure that personnel changes will not have a great impact on the progress of the project.

In the project implementation, one developer, due to participate in the training, the absence of the project execution week, due to the implementation of "Code ownership" practice, other developers successfully share the member's testing and development tasks, so as to ensure the project on time delivery.

Continuous integration (continuous integration)

XP: It is advocated to integrate the system multiple times during the day, and as the requirements change, the regression testing is ongoing. This allows the team to maintain a high development speed while avoiding a system-integrated nightmare.

Commentary: Continuous integration is not the best practice of XP proprietary, and the famous Microsoft Company has a successful practice of daily integration. However, it should be noted that continuous integration also requires the effective support of a good software configuration change management system.

Project: Use VSS as a software configuration management system, adhere to a daily system integration, the completed functions are effectively combined to test.

Small publication (Small release)

XP: The emphasis is on incrementally releasing new versions in a very short period of time, making it easy to estimate the progress of each iteration cycle, to control workloads and risks, and to process user feedback in a timely manner.

Comments: Small releases highlight the advantages of the agile approach. RUP emphasizes iterative development and does not provide much regulation for the release of the system. When users submit requirements, they only see the real system when they deploy, which is not conducive to rapid user feedback.

If you can guarantee best practices such as test first, code refactoring, and continuous integration, it is not a difficult task to implement a small release, which can be considered in a qualified organization.

Project: The project is configured with a test and publishing server at the preparatory stage, during the implementation of the project, an average of two weeks (after the end of an iterative cycle) for a small release, the user within two working days after the release of the project team to submit "User Acceptance test Report", the project manager to evaluate the test report, Submit a valid bug to the rational clear case and assign it to the appropriate developer. The project team should fix all user-submitted issues before the end of the next iteration cycle.

The above is the application of XP best practices in the project, let's review the detailed statistics for this project:



In which, a "User requirements change" was submitted during the execution of the project, and the impact of the change on the project cycle was 6 working days.

After the project was implemented, only 2 bugs were submitted in the user's acceptance test and were resolved on the day of submission. At present, the project runs smoothly, and has been praised by users. Therefore, we believe that the implementation of XP in this project effectively guarantees the quality of the project and the project cycle.

Summarize

Both RUP and XP are software development processes that are developed in the process of summarizing many project practices, but they differ in the way they handle requirements changes. In fact, they still have a lot of similarities, for example, they are based on object-oriented methods, the importance of code, document minimization and design simplification, the adoption of dynamic adaptation of the evolution of the iterative cycle and so on.

At present, the ideal situation for the implementation of XP in China should be: to maintain the existing development process and life cycle model of the organization, according to the application type, project characteristics and organizational culture, draw lessons from, take individual project effective XP practices, the RUP will be tailored to form its own software development process.

In the course of implementation of the project, we feel that XP has a higher requirement for the performer because it requires the development team to have skilled code design skills and rigorous testing and assurance techniques, to understand object-oriented and schema, to master refactoring and OO testing techniques, to be accustomed to test-first development methods, and so on.

Therefore, for the current domestic software development organizations, should first strengthen the software development process and system Architecture Design Master, then, is to use XP and other agile methods to improve the software development process.