[Post] the path to a balance between RUP and XP

A balance between RUP and XP

Author: Spiderman (Shenzhen)
From: http://blog.csdn.net/testwin
Email: testwin@sohu.com

People have experience and fear, and they will form a methodology to avoid such things. People studying heavy methodologies may have a long history of organizing thousands of development teams for development, such as the development of large-scale telecommunications systems and the development of military and aerospace systems ...... this type of project strictly emphasizes the process implementation specifications, and focuses on document specifications, reviews, and process measurements. XP creators may have been working on projects in small teams. There are only 3 or 5 members in the project team. The project will always be cancel because it does not meet the user value, and the Development Company will suffer losses, therefore, it focuses on communication and feedback with users, and emphasizes fast and flexible.


The background, characteristics, and applicable fields of each software method vary. So is it unreasonable for software projects to use the same software development method to develop projects of different types, sizes, and complexity.

Not long ago, I happened to have some exchanges with a Senior Software Engineering Consulting consultant in China. He is keen on Process Improvement of the RUP and advocates proper tailoring for different types of projects, in fact, this is also a flexible way to adapt and change as needed. I understand and agree with this, but I have always maintained a relatively cautious attitude towards RUP.
First of all, I think it is too idealistic and theoretical.
It is a framework of process components, methods, and technologies. You can apply it to any specific software project, and you can define
. For various types of software projects, RUP does not provide its own specific reduction and implementation strategies, and there is always a sense of no evidence to follow. You can either say that it can solve any problem or that it is nothing. Secondly, in essence, RUP is a software method that emphasizes design and specification. From this perspective, there is no big difference from the traditional waterfall model, and its flexibility is relatively weak compared with agile methods. In some small software projects, especially unpredictable software project development, there are various urgent needs and time pressures. It is difficult to use the RUP. However, on the other hand, RUP emphasizes the collection, sorting and processing of knowledge, and emphasizes a good architecture in software development. Therefore, it is conducive to the accumulation and sharing of knowledge.
Compared with RUP
Agile methods such as XP are more flexible and advocate early and continuous delivery of valuable software to meet user needs. Replaces detailed documents with communication, emphasizing the initiative, self-discipline, self-organization, and spontaneous management of the team. XP also uses Code As the core method, there are many unknown things here, and knowledge only exists in two places: the developer's mind and the final code. For project managers, they will think that agile development methods weaken the concept of knowledge management. In fact, agile development focuses on the accumulation and accumulation of the most valuable knowledge.
How to flexibly cope with various project risks, how to maximize the user value, how to effectively control the project development process, and how to manage the knowledge in the project process, every software project manager needs to think deeply. The advocates of the RUP have always stressed the tailoring of the RUP. In fact, I think that it is not only about the tailoring of its own, but also about the integration of IT. Appropriate practices for agile development are integrated while the rational development framework is tailored. Do not think that RUP and XP are in conflict. Otherwise, they have different principles and different application fields. In
Integrating XP
Only when the technology is used can the correct amount of data be obtained, which not only satisfies the needs of all members of the project, but also solves all major project risks. For a small project team working in a highly trusted environment, where users are part of the team
XP is fully competent. You need to do some other work for scenarios where the team is becoming increasingly dispersed, the Code volume is getting bigger, or the architecture is not well defined. Only XP
It is not enough. RUP is a framework that allows you to expand xp with a more robust set of technologies, as necessary, starting from the RUP.

The best practices of RUP include:
1. iterative development

2. management requirements
3. Use a component-based architecture
4. Visual Modeling
5. Continuous Quality verification
6. Control Changes

12
XP practices include:
Planned Development: determine the functions of the next version by combining the priority "story" and technical estimation.
Minor version: software is often released to customers in small incremental versions.

Metaphor: metaphor is a simple, shared "story" or description that describes how the system works.

Simple Design: The design is simple by keeping the code simple. Constantly search for complex points in the Code and immediately remove them

Test-driven development: You can write test content to test the story.ProgramCompile the test content to find any problems in the code. Write the test content before writing the code.

Refactoring: This is a simplified technique used to remove duplicate content and complexity from the code.

Pair Programming: two members of the team use the same computer to develop all the code. One person writes code or drives, and the other person reviews the correctness and comprehensibility of the code at the same time

Collective code ownership: Anyone owns all the code. This means that everyone can change any code at any time.

Continuous integration: Creates and integrates the system multiple times a day, as long as any implementation task is completed
40 hours per week: programmers cannot guarantee the maximum efficiency during fatigue. It is absolutely not allowed to work overtime for two consecutive weeks.

On-site customer: a real customer works in the development environment full-time to help define the system, write test content, and answer questions.
Encoding standards: programmers use consistent encoding standards

The integration of RUP and XP is complementary to each other's characteristics and a balance between software development methods. Thinking about the balance between software and technology can be said to be the beginning of technological maturity.
Finally, I would like to add my personal experience. During software project development, the characteristics of different software projects should be identified and analyzed, and appropriate development practices should be adopted to adapt to the software development process to ensure effective support for software development, in order to create "good enough" software. And this is enough
Balance progress, cost, and quality to meet customer needs.

This article is now in the testing age. Click here to participate in the wonderful discussion:
Http://www.testage.net/bbs/dispbbs.asp? Boardid = 30 & id = 5890 & star = 1 #29302