12 best practices of agile development method XP

2020-12-10 21:04:18
Original 2941
Summary : Extreme Programming (XP) is a lightweight, efficient, low-risk, flexible, predictable and scientific software development method. Its characteristics are included in 12 best practices.

12 best practices of agile development method XP

1. Planning game

(1) Make plans quickly and improve with the change of details;

(2) Detailed explanation: it is required to determine the system scope to be developed and released in the next stage in combination with the project progress and technical conditions. The plan should be updated when it fails to keep up with the actual changes.

2. Small release
(1) The design of the system should be able to be delivered as early as possible;

(2) Detailed explanation: it emphasizes that the new version should be released incrementally in a very short period of time, so that the progress of each iteration cycle can be estimated easily, and the workload and risk can be controlled easily; at the same time, the feedback from users can also be handled in time.

3. System Metaphor

(1) Find a suitable metaphor to convey information;

(2) Detailed explanation: describe how the system works and how new functions are added to the system through metaphors. It usually contains some classes and design patterns that can be referenced and compared.

4. Simple design
(1) Only deal with the current requirements to keep the design simple;
(2) At any time, the system should be designed as simple as possible. Unnecessary complexity is removed as soon as it is discovered.
5. Test-driven
(1) First write the test code and then write the program;
(2) Explanation: programmers write unit tests constantly, and development can continue only when these tests can be run correctly.
6. Refactoring
(1) Re-examine requirements and design and re clearly describe them to meet new and existing requirements;
(2) Code refactoring is to readjust and optimize the internal structure of the system to reduce complexity, eliminate redundancy, increase flexibility, and improve performance without changing system behavior.
7. Pair programming
(1) Two programmers write code to solve the same problem on the same computer.
(2) Explain: usually one person is responsible for writing the code, while the other is responsible for ensuring the correctness and readability of the code.
8. Collective ownership
(1) Anyone can change any code anywhere in the system at any time.
(2) Explanation: each member has the right to change the code, and everyone is responsible for all the code.
9. Continuous integration
(1) Can be run by the day or even by the hour for customers to run the version;
(2) It is advocated to integrate the system several times in a day, and with the change of requirements, the regression test should be carried out continuously, which avoids the nightmare of system integration once.
10. 40 hour week
(1) Project team members are required to work no more than 40 hours a week, and overtime should not exceed two consecutive weeks, otherwise, productivity will be affected.
11. On-site customer
(1) Add a real, functional user to the team who will answer questions full-time.
(2) Explain: at least one actual customer representative is required to be on-site throughout the project development cycle to determine requirements, answer team questions, and write functional acceptance tests.
12. Code standards
(1) Emphasize communication by specifying strict code specifications to minimize unnecessary documentation.

Write a Comment
Comment will be posted after it is reviewed.