1. The Planning Game

(1) Create plans quickly and refine them as details change.

(2) Explanation: Determine the scope of the system to be developed and released in the next stage, taking into account project progress and technical conditions. The plan must be updated continuously to reflect actual changes.

2. Small Releases

(1) The system should be designed to be delivered as early and frequently as possible.

(2) Explanation: This emphasizes releasing new versions incrementally in very short cycles. This makes it easier to estimate the progress of each iteration and control workloads and risks, while allowing the team to handle user feedback in a timely manner.

3. System Metaphor

(1) Find a suitable metaphor to convey complex information simply.

(2) Explanation: Describe how the system works and how new functions are added through shared metaphors. It usually involves classes and design patterns that team members can easily reference and compare.

4. Simple Design

(1) Address only the current requirements to keep the design as simple as possible.

(2) Explanation: At all times, the system should be designed as simply as possible. Unnecessary complexity must be removed as soon as it is discovered.

5. Test-Driven Development (TDD)

(1) Write the test code first, then write the production code.

(2) Explanation: Programmers continuously write unit tests, and development can only proceed when these tests run successfully.

6. Refactoring

(1) Re-examine the code and design, clarifying them to meet both new and existing requirements.

(2) Explanation: Code refactoring involves adjusting and optimizing the internal structure of the system to reduce complexity, eliminate redundancy, increase flexibility, and improve performance—all without changing the external behavior of the system.

7. Pair Programming

(1) Two programmers work together at the same computer to write code and solve the same problem.

(2) Explanation: Typically, one person (the driver) is responsible for writing the code, while the other (the navigator) reviews it in real-time to ensure correctness, readability, and strategic alignment.

8. Collective Code Ownership

(1) Anyone can change any code anywhere in the system at any time.

(2) Explanation: Every team member has the right to modify the code, and the entire team shares responsibility for the entire codebase.

9. Continuous Integration (CI)

(1) Build and run the system daily—or even hourly—to ensure a working version is always available.

(2) Explanation: The team integrates the system multiple times a day. As requirements change, automated regression tests are run continuously, completely avoiding the nightmare of late-stage "big bang" integration.

10. 40-Hour Work Week (Sustainable Pace)

(1) Explanation: Project team members should work no more than 40 hours a week. Overtime should not exceed two consecutive weeks; otherwise, productivity and quality will inevitably suffer.

11. On-Site Customer

(1) Include a real, active user on the team to answer questions full-time.

(2) Explanation: At least one actual customer representative must be on-site throughout the project's development cycle to clarify requirements, answer the team's questions, and write functional acceptance tests.

12. Coding Standards

(1) Explanation: Emphasize seamless communication by establishing and adhering to strict coding standards, which minimizes the need for excessive and unnecessary documentation.