XP (extreme programming) of large projects
AMR ELSSAMADISY, Simaetin Translation (Reprinted from UMLCHINA) September 15, 2003
Our time we use the XP method in large projects such as Thoughtworks for more than 15 months. This project begins three years ago, then it has a large number of demand documents and several independent features. From January 2000, we decided to apply XP, although we already know that XP did not apply to large projects. At that time, we need to submit a functional demonstration to the customer, and we must win their confidence by submitting a working unit, not just a prototype (we have more than 25 developers and approximately 15 analysts in the team). But we are not ready, and all groups use their own code framework, and a complete application is not talking about. Shortly, the customer wants to see something, but we have not really functional. It should be said that the first iteration period developed is successful: we submit a real application subset. The primary reason for success is that we let developers from Asset, Ar and Gui engaged in different working developers. Of course, there are also "growing troubles": some personal conflicts between analysts and developers, but we successfully span these obstacles. At that time, everything was very beautiful: We successfully submit a functional demonstration with a speedy speed, but with the lapse of the project, some things are not as good as we wish. This is what this article wants to tell: After we really harvest after the "honeymoon" period, how we manage a 50-person project development in a year and a half, complete the phase of the phased submission (although sometimes is not successful) About the pain of our experience, our follow-up work, our ultimately learned and as an improvement to use the experience in the next project.
First, we give us the situation: 15 months ago, how we applied XP, then show our current XP application. That is, the reason why our changes will be discussed below. This is a natural choice process, which removes many bad ideas, or transforming them into a more effective way, making it more suitable for large projects. Finally, we will summarize and give cautious proposals for using XP in large projects.
Elements of XP in large projects
Ok, let's enter the topic. The team we developed and analyzed was composed of approximately 35 developers, 15 analysts and 10 QA. Developers rely on analytics as a customer. Despite the actual customers, analysts still have to work together to make customer decisions. The following table demonstrates the XP basic elements discussed in [1] and briefly describes how these aspects apply to various stages of the project. We use this table to analyze the practice of our team nature, and how the XP on the book is applied to a large project of more than 50 people.
The simplicity test of the submission of cycle metaphorism is scheduled to refactor the 1/2000 large span iterative plan. All members of the development and analysis group discuss new story cards and estimates all day. Most developers check into the new feature of Sign UP. There is no change in the existing code benchmark for 1 month. Existing code is still complicated, but the new code is as simple as possible. This stage includes abandoning the old code and rewriting those functional code that "may be used in the future". Unit test begins in some new code. Promote a large test baseline. QA do all function tests and have authorized story cards. For old code, reconstruct it if necessary. 7/2000 Basic is 1/2000, but it does feel very inefficient. Most participants have not been well involved. Drag is discussed, 50 people are unbearable. There is no way to continue design with a simple principle as possible for 1 month. Complete reconstruction of existing design. Completion code conference is intended to discuss new design in all ranges so that the entire team will understand the development trend of code and design. Better unit tests override a larger range, although not completely covered. Code function test help override the test range. Most developers have the development of new features, rarely do reconstruction. The code benchmark has become bad when it submits cards at the end of the iterative period. 1/2001 I hope to make a plan during each iteration as soon as possible - our way is to prepare more in the group before formal meeting. There are no major design in 2 weeks. Based on existing design: reservation standards, the code will gradually stop because new design and reconstruction have not been completed. Attempting to remove the code function test, if the screen scraper, if it fails, it will return to the code function test. Add new unit test but still do not overwrite. The QA group starts with the interface test using the automatic function test. Reconstruction begins more frequent, because some code began to become messy. The reason for the need to clean up is mainly to achieve simple and iterative periods to grow in the case where there is no important reconstruction. 6/2001 Some meetings of discussion cards or related card groups include participants including those who are interested or experienced and analysts responsible for these cards. Most people in 2 weeks and the entire QA group ready to submit 1.0 version to customers. The reference separation of the code is to join the new features that have not been tested. There are more dependencies for unit testing. Although there is still an omission, the test range has been basically stable. The QA group no longer tests new features because the focus is the submission of version 1.0. It is rarely reconstructed on the release version, and on the continued version of the company, developers will be reconstructed in question, especially after the year ago, after the year, after a greater and more painful reconstruction.
Confiscation of all continuous integration of the program collective 40 hours week customer code specification 1/2000 Due to our decision using XP, the entire team read [1]. Everyone did an attempt, most people were attracted. Since the initial phase of the group is functional, we are not aware of Collective Ownership, and there is no realization of code protection. Starting from the first iteration date, for online integration, see [2] This is a concept working time: because we hope that the customer is present. So we will spend another time to meet the deadline. Transaction analysts are at the venue, and they are 15 people. The real customer is not there, and the analysts communicate with them. Basically, Java's general grammar. 7/2000 The program is still prevailing: developers make new functions to program, but the incomplete and maintenance work is made by a single person. There are also some developers to stop reading the programming. When the developer is increasingly touching the different parts of the system, the owner of the code gradually appears. Members are well communicated with a hoping, code mutual review and a short standpoint (STAND UP Meeting). Code function test is added to the construction process. In order to pass the story card, the last working time in each iteration period reaches 50 to 60 hours. The code mutually discussed with the developers a chance to discuss the implementation of different subsystems. We can accept informal ways of certain subsystem code. 1/2001 The program is less programming, because this phase of the coding is more direct, and some people are reconstructed. Because of the low efficiency, standing meetings are discarded, but all the code has been more clear. Developers began to pay a full-time responsibility of a part of the system. Stable _ 同. In the same period of 2 weeks, the developer's working hours were closer to 40 hours ... The same codes were gradually reduced, and the design and coding specifications tended to be saturated. 6/2001 Take the rules: All new features should be applied to programming, and the error and maintenance are completed by one. With the continuation of professional division of labor, different development groups have knowledge of different partial code, so we will make them more active in the design of the corresponding modules, but the code is still collective. Stabilize the same. The same is the same as the above
First we talk about the experience of programming. In most cases, we have two developers in a certain iterative period to work for a story card (or several iterative correlation cards). Developers need to invest more in large projects, because the warm-up time in the new field is not ignored. The good communication and periodic planning meeting between developers make everyone have the overall concept of doing. This makes the developer A. developers' in the classic textbooks become possible to solve problems with the problem.
The relationship between the program is of course very good, but it is not any time to apply. The most common situation is that the developers are not willing to finish when changing the error and maintenance, and in this case, many eyes are staring at the debug code. It is really nothing beneficial. Another is the repetition of the iterative period. In this case, the problem has been determined, and it is not necessary to complete it. Also, developers have different individuals: Some people need intermittent pairing, and some people make more excellent, and the programming will hinder their ability to play and ultimately become their burden.
Unit test and integrated construction
Unit testing and integrated constructs are absolutely necessary, which means that if we don't test, we can't submit any code. When the application becomes bigger and bigger, there is no test we can't add any new features or reconstruct. We now have integrated constructors and tests in the new code. With regard to these construction and test details, the responsible person will be in time on the internal web page, so that each developer can know the current constructor, transaction analysts and QA can get the recently constructed information to test new features.
All and information sharing in the group
For such a large project, in order to prevent the entire system from being divided into an isolated part, the publication of the information and the distribution of information and the code wheel of different parts are very important. Communication is required (but we can't force a silence to open), we tried to give everyone a chance to make everyone a chance to make the silent people to speak their requirements. And eventually we canceled such a meeting, because most developers believe that this meeting puts everything is just a waste of time. This is also one of the advantages of this team ?? We can always work like a community, such as cooperating with the program. Start, we use a method of rotation, that is, everyone makes everything, which makes us engage in understanding things when they are later arrival deadline. But for a complicated code, do this, time input is very huge. It is best to use a compromised approach: that is, when the project time is tight, only works familiar with each person, and at other times, if you don't have a familiar work, you can do it at the same time. Do things. Our present principle is that developers continue to do some related cards in several iterative cycles while gradually stepping to other parts of the system. The practice of checking into several different cards in the same iteration period is no longer used. The code will make it closer. Is it because our project is big? Still because many people doing code are newers (refer to new hands in this function, not newers programming)? The answer may be both. But sometimes we don't touch the code, it is difficult to start the rest of the system, so the regular cleaning code is required. This will lead to our next topic: Reconstruction. Reconstruct
In the large-scale project of XP, the reconstruction is absolutely necessary to eliminate inconsistencies of the code. Even those familiar with those in the application of the project, will also face the huge work of reconstruction. For project managers, you must recognize that the reconstruction needs to be separately allocated. We did this, we left time to refactor the main part of the code.
Sequenceful cycle
The iteration period and its period is required, but the length has always been a problem. In the past, we used long-term cycles (such as one month), and every month will be very nervous and accompanied by some adverse code, and inevitably occur in an estimate. We have to accept some unsatisfactory cards (this is very difficult for developers, and difficult to meet the established period). to sum up
Here, the experience and lessons of our 50 people in this 50-year project are listed below:
1) Perform iterative schedule at the beginning of each iteration period. Daily customers and developers discuss recent story cards and assess them, resolved and demonstrate these evaluations and discovery after each discussion, and then let developers check into. This allows the entire project group to know the current situation of the project without allowing everyone to be involved in the marathon. 2) Make the submission period as short as possible: we are two weeks, but you can make the submitted cycle across multiple iterative cycles when necessary. Allows the card in multiple iterative cycles, but the progress of progress is performed in units of each cycle.
3) Perform as many unit tests as possible, this is self-evident. There should be a software package that automatically tests to ensure the coverage of the test. But the QA group is irreplaceable (regardless of how many test procedures written), because we always have a prejudice for the system.
4) Simple design can help us provide customers with workable versions continuously. Frequent design meetings are useful for joining a large number of new features, while lunch is a good time to convene the entire project group. This avoids an incompatible solution while different parts of the system.
5) Reconstruction is the only way to make simple design. Design reconstruction is equally important to the reconstruction of the code. Although it is often attractive to use the solution to the patch, it is often attractive, but it means that it will make greater reconstruction in the future.
6) When adding new functions, it is necessary to unswervingly implement the programming, and stop when changing the error and repeatability, because the problem is already solved when it is. 7) Collective all and communication classes are inseparable. The team must have an effective way of communication. Perhaps not only an informal discussion, sometimes the 10 to 15 minutes of the release of the regular 10 to 15 minutes is a good way.
8) In large projects, some people have to play a customer's role and produce enough work for a large number of developers. This is closely related to the domain knowledge.
9) The coding standard is very informal, which will not harm your progress. More important is a communication through a presentation. The code is not all documents, and developers need to see the whole picture, this is the code that cannot be provided.
There are also some rules we have not implemented:
1) The two-week standing meeting is inefficient. You can choose once a month to replace it.
2) Iterative Planning Conference is not necessary to let all personnel participate. A better way is to discuss with a smaller group, and discuss the cards 30 to 45 minutes before get off work every day.
3) A month's iteration period is too long, which is not conducive to producing high quality code. 2 Weely iterative cycles is more easily tracked and the estimate is more accurate.
4) The last bit is not suitable in the amount of big code, especially when refiting the large-scale system. At this time, a card will affect multiple iterations.
5) Metaphor (metaphor) is not suitable for large systems.
6) 40 hours a week, we can't make a problem, 40 hours is the least, the timeout work does not give us an adverse impact. To reiterate that we are not 100% implementation of the programming.
This is XP, or our XP version, working in our group. We have experienced the process of submitting large complex applications on time, but also provides valuable experience in this type of project for each developer.
