XP Terms – Extreme Programming trong PMI-ACP

Extreme Programming (XP) – phương pháp Agile đậm chất kỹ thuật cho dự án phần mềm, tập trung vào feedback nhanh và thực hành lập trình tốt.
Ngôn ngữ • Language
- VI
- EN
XP Terms – Extreme Programming “dịch” sang ngôn ngữ đời sống
💡 Bài này dành cho ai?
- Bạn xuất thân từ project management / business và thấy XP toàn thuật ngữ kỹ thuật.
- Bạn là developer nhưng muốn hiểu XP dưới góc độ PMI-ACP chứ không chỉ là “coding style”.
- Bạn muốn phân biệt XP với Scrum: giống nhau ở đâu, khác nhau ở đâu, đi thi bị gài kiểu gì.
TL;DR – Extreme Programming (XP) trong 1 phút
- Extreme Programming (XP) = một phương pháp Agile tập trung vào phát triển phần mềm với các thực hành kỹ thuật cụ thể.
- XP có:
- Core values: Communication, Feedback, Simplicity, Respect, Courage (bạn có thể thấy thứ tự khác nhau tuỳ tài liệu, nhưng “đúng bộ 5” là quan trọng nhất).
- Roles: Customer (On-site Customer), Programmer, Tester, XP Coach.
- Practices nổi bật: Small Releases, Simple Design, Pair Programming, Test-Driven Development (TDD), Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Sustainable Pace, Customer/Acceptance Tests.
- So với Scrum:
- Scrum thiên về quản lý công việc & feedback ở cấp đội/sản phẩm.
- XP thiên về cách code & cách tổ chức kỹ thuật để giữ chất lượng cao.
- Trong PMI-ACP, XP thường xuất hiện ở:
- Câu hỏi về engineering practices, technical excellence, team collaboration trong phát triển phần mềm.
Gợi ý cách học:
- Đọc mục 1 để hiểu XP dùng khi nào, khác gì Scrum – đặc biệt chú ý phần Scrum + XP combo.
- Nắm vững 5 XP values và các role tương đương Scrum.
- Học thuộc “mặt chữ” các XP practices (pair programming, TDD, CI...) cho phần mini-mock & đề thi.
- XP là gì? Dùng lúc nào?
1.1. Định nghĩa ngắn gọn
- Extreme Programming (XP) là một phương pháp Agile, ban đầu thiết kế cho phát triển phần mềm.
- Mục tiêu chính:
- Nâng chất lượng phần mềm thông qua thực hành kỹ thuật tốt.
- Đáp ứng thay đổi yêu cầu bằng feedback nhanh & liên tục giữa team và khách hàng.
Ví dụ dễ hình dung:
- Nếu Scrum là cách bạn tổ chức việc và họp (Sprint, Daily Scrum, Review, Retro),
- Thì XP là bộ “thói quen code” và “cách làm kỹ thuật”:
- code chung 2 người (pair programming),
- viết test trước khi code (TDD),
- tích hợp thường xuyên (CI),
- refactor liên tục để code luôn sạch.
1.2. XP vs Scrum – giống và khác
Điểm giống (đều là Agile methods):
- Làm việc theo iterative & incremental.
- Đề cao feedback sớm, khách hàng tham gia thường xuyên, team tự tổ chức.
- Nhấn mạnh giảm lãng phí, tập trung vào giá trị khách hàng.
Điểm khác (để nhớ khi đi thi):
- Scrum:
- Dùng được cho nhiều loại sản phẩm, không chỉ phần mềm (dịch vụ, marketing campaign, thiết kế tòa nhà, v.v.).
- Tập trung vào framework quản lý: roles, events, artifacts.
- XP:
- Gần như chỉ dùng trong phát triển phần mềm (programming đã nằm trong tên).
- Tập trung vào thực hành kỹ thuật & coding practices.
Nếu đề hỏi về pair programming, TDD, continuous integration, refactoring... → gần như chắc đang nói về XP / technical practices, không phải “Scrum thuần”.
1.3. Scrum + XP combo trong thực tế
Trong thực tế, rất nhiều team dùng:
- Scrum để:
- Quản lý công việc: Sprint, Product Backlog, Sprint Review, Retrospective.
- Đảm bảo cadence họp & feedback với business.
- XP để:
- Nâng technical excellence: TDD, CI, refactoring, pair programming, coding standards, acceptance tests.
- Giữ codebase sạch, dễ maintain, ít bug.
Pattern hay gặp trong đề:
- Hỏi: “Scrum team muốn nâng chất lượng kỹ thuật, nên làm gì?”
→ Đáp án thường là: bổ sung XP practices (TDD, CI, refactoring, pair programming…),
chứ không phải thêm họp hay tăng giờ OT.
- XP core values – 5 “tính cách” chính của Extreme Programming
XP có 5 giá trị cốt lõi (core values). Nắm 5 giá trị này sẽ giúp bạn đoán được tinh thần của các practice phía sau.
Lưu ý nhỏ: bạn có thể gặp tài liệu ghi thứ tự khác nhau (hoặc tài liệu cũ chỉ nhắc 4 values). Khi đi thi, ưu tiên nhớ đúng bộ 5 và hiểu ý nghĩa.
2.1. Simplicity – Đơn giản
- Tập trung làm “the simplest thing that could possibly work” – thứ đơn giản nhất có thể chạy được và tạo giá trị cho khách hàng.
- Tránh:
- Over-engineering (thiết kế quá phức tạp).
- Extra features mà không ai dùng → lãng phí.
Ví dụ đời thường:
- Làm app nội bộ chỉ cần báo cáo ngày/tuần/tháng:
- Nếu bạn thêm 10 kiểu chart, 7 dashboard nhưng team chỉ dùng 1 kiểu → phần lớn là lãng phí.
- XP khuyến khích:
- Bắt đầu với “phiên bản đủ dùng”, sau đó refactor & mở rộng khi thật sự có nhu cầu.
2.2. Communication – Giao tiếp
- Team cần nói chuyện thường xuyên, rõ ràng, không “mạnh ai nấy làm”.
- XP khuyến khích:
- Daily communication (thường là daily standup tương tự Scrum).
- Pair programming → 2 người cùng nhìn vào một vấn đề, trao đổi liên tục.
Ví dụ:
- Thay vì mỗi dev ôm một module, XP thích:
- 2 người cùng ngồi 1 máy, bàn cùng một đoạn code, cùng hiểu chung hệ thống.
2.3. Feedback – Phản hồi sớm
-
Lấy feedback từ:
- Khách hàng (Customer / On-site Customer).
- Tests (unit test, customer/acceptance test).
- Pair programming / reviews.
-
Mục tiêu:
- “Fail fast, learn fast” – nếu sai thì biết sớm để sửa rẻ & nhẹ.
Ví dụ:
- Thay vì đợi xong nguyên hệ thống rồi mới test,
- XP viết test sớm, chạy test liên tục mỗi lần build → sai là thấy ngay.
2.4. Courage – Can đảm
- Can đảm nhìn thẳng vào vấn đề, sẵn sàng thay đổi thiết kế khi biết mình đang sai.
- Can đảm:
- Refactor code cũ khi nó cồng kềnh.
- Viết test cho phần code “dơ” trước khi đụng tay.
- Thừa nhận “mình chưa hiểu chỗ này” với team.
Hình ảnh dễ nhớ:
- Công khai code cho cả team xem (collective code ownership) → cần nhiều courage:
- code không còn “giấu trong góc”.
- ai cũng có thể chỉnh sửa, comment, improve.
2.5. Respect – Tôn trọng
- Tôn trọng cách làm việc khác nhau của từng người.
- Cùng chia sẻ trách nhiệm về thành công/thất bại của dự án.
- Mọi người trong team đều quan trọng:
- Customer, Programmer, Tester, Coach…
Trong nhiều tài liệu quản lý truyền thống, người ta hay nói “accountability không thể chia sẻ”.
Trong XP, ta muốn ai cũng cảm thấy mình có trách nhiệm – vì cả team là một đơn vị (unit).
- XP roles – map sang Scrum roles cho dễ nhớ
XP có một số vai trò chính. Để dễ học PMI-ACP, ta đặt cạnh Scrum để so sánh.
3.1. XP Coach
- Vai trò:
- Hướng dẫn team áp dụng XP values & practices.
- Làm servant leader: hỗ trợ, gỡ vướng, facilitate hơn là ra lệnh.
- Giữ cho team “đúng XP”: pair programming, TDD, CI, refactoring…
So sánh với Scrum:
- XP Coach ≈ Scrum Master (coach/servant leader):
- Cùng là người đỡ đầu cho Agile mindset, giúp team tự tổ chức, bảo vệ team khỏi “nhiễu bên ngoài”.
3.2. Customer / On-site Customer
- Trong XP thường gọi là Customer hay On-site Customer:
- Người đại diện cho business, mang yêu cầu & ưu tiên (priorities).
- Làm việc sát với team, lý tưởng là ngồi cùng chỗ hoặc luôn sẵn sàng để trao đổi.
- Tham gia viết user stories và customer/acceptance tests.
So sánh với Scrum:
- Customer / On-site Customer ≈ Product Owner:
- Cùng là người định hướng sản phẩm và ưu tiên.
3.3. Programmers (Developers)
- Là những người viết code, implement user stories.
- Trong XP, programmer:
- Thường làm việc theo pair programming.
- Viết unit tests (thường là TDD: test trước, code sau).
- Cùng chịu trách nhiệm về collective code ownership.
So sánh với Scrum:
- Programmers ≈ Developers trong Scrum Team.
3.4. Testers
- Giúp:
- Khách hàng định nghĩa acceptance tests cho user stories.
- Thiết kế & chạy test để đảm bảo chất lượng.
- Trong nhiều team, programmer & tester có thể trùng người, nhưng XP vẫn nhấn mạnh rõ vai trò test.
So sánh:
- Testers trong XP tương đương với những người làm testing / QA trong Scrum Team.
- XP practices – các thuật ngữ hay gặp trong đề thi
PMI-ACP thường kiểm tra nhận diện khái niệm (recognition) các thực hành điển hình của XP.
4.1. Một số practices cốt lõi
-
User Stories
- Cách ghi yêu cầu ngắn gọn từ góc nhìn người dùng.
- Thường theo format: As a [user], I want [something] so that [benefit].
-
Small Releases
- Release thường xuyên những phiên bản nhỏ nhưng usable.
- Mục tiêu: đưa phần mềm vào tay người dùng sớm, lấy feedback th ật.
-
Simple Design
- Thiết kế “vừa đủ xài” cho nhu cầu hiện tại, tránh phức tạp hóa.
- Kết hợp với refactoring để cải thiện thiết kế dần dần.
-
Pair Programming
- Hai lập trình viên ngồi chung một máy:
- Một người “driver” gõ code.
- Một người “navigator” suy nghĩ về kiến trúc, edge cases, hướng giải.
- Lợi ích:
- Chất lượng code cao hơn, chia sẻ kiến thức nhanh hơn.
Ví dụ đời thường:
- Giống như 2 người cùng học lái xe:
- 1 người cầm lái, 1 người luôn nói “cẩn thận chỗ này, nhớ bật xi-nhan, coi gương”.
- Hai lập trình viên ngồi chung một máy:
-
Test-Driven Development (TDD)
- Chu trình: Red → Green → Refactor:
- Viết test trước (fail → red).
- Viết vừa đủ code để pass test (green).
- Refactor code cho sạch hơn, vẫn giữ test pass.
- Lợi ích:
- Thiết kế tốt hơn, ít bug hơn, tự tin refactor.
- Chu trình: Red → Green → Refactor:
-
Customer / Acceptance Tests
- Các tiêu chí chấp nhận (acceptance criteria) và bài kiểm thử do Customer/PO cùng team xác định để xác nhận “đúng nhu cầu”.
- Điểm hay bị gài trong đề:
- Test không chỉ của dev (unit test), mà còn là test theo góc nhìn người dùng/khách hàng để feedback sớm.
-
Refactoring
- Thay đổi cấu trúc bên trong của code để nó:
- Sạch hơn, dễ hiểu hơn, dễ sửa hơn.
- Nhưng không thay đổi hành vi bên ngoài.
- Luôn kết hợp với test để đảm bảo không phá chức năng.
- Thay đổi cấu trúc bên trong của code để nó:
-
Continuous Integration (CI)
- Tích hợp code thường xuyên (nhiều lần mỗi ngày) vào mainline.
- Mỗi lần tích hợp:
- Build & chạy test tự động (bao gồm unit test và/hoặc acceptance tests tuỳ pipeline).
- Lợi ích:
- Phát hiện lỗi tích hợp sớm, tránh “đại chiến merge” cuối dự án.
-
Collective Code Ownership
- Bất kỳ lập trình viên nào cũng có thể sửa bất kỳ phần code nào khi cần.
- Không có chuyện “đây là module của A, không ai được đụng vào”.
- Phù hợp với pair programming & CI.
-
Coding Standards
- Cùng thống nhất tiêu chuẩn:
- Style code, naming, layout, comment…
- Mục tiêu:
- Code của ai nhìn cũng giống “cùng một người viết”.
- Cùng thống nhất tiêu chuẩn:
-
Sustainable Pace
- Làm việc với nhịp độ bền vững (nhiều tài liệu hay dùng “40-hour work week” như một cách nói tắt).
- Trọng tâm: không OT triền miên, tránh burnout → giữ chất lượng và tốc độ ổn định dài hạn.
-
Planning Game
- Cách XP tổ chức Release Planning & Iteration Planning.
- Customer ưu tiên business value, programmers ước lượng kỹ thuật → cùng thương lượng scope cho iteration.
-
Whole Team
- Mọi người cần thiết cho việc delivery (customer, dev, test, ops...) đều được xem là một team.
- Giảm kiểu “đội A xong mới quăng qua đội B”.
-
System Metaphor
- Một ẩn dụ dễ hiểu mô tả cách hệ thống hoạt động (ví dụ: “như bưu điện chuyển thư”).
- Giúp team nói chuyện với nhau về architecture bằng ngôn ngữ đơn giản.
Trong đề, các practice như Planning Game, Whole Team, System Metaphor thường chỉ xuất hiện ở mức nhận diện tên hơn là đào sâu chi tiết. Nhưng thấy chữ là nên nhận ra đang nói về XP.
4.2. Cách đề thi hay gài
-
Nhắc đến:
- Pair programming, TDD, CI, refactoring, collective code ownership, sustainable pace, acceptance tests → điểm mặt XP.
-
Nếu câu hỏi so sánh:
- Scrum: nói về Sprint, Product Backlog, Scrum Master, Product Owner…
- XP: nói về Coach, Customer/On-site Customer, Programmer, Tester, và các practices kỹ thuật.
-
Nếu câu hỏi về Scrum team muốn nâng kỹ thuật, phương án đúng thường là:
- Áp dụng các thực hành XP (TDD, CI, refactoring, pair programming, coding standards, acceptance tests…),
- Không phải “tăng giờ OT” hay “bỏ bớt test”.
- Exam patterns & traps – XP trong PMI-ACP
- Câu hỏi bảo: “Để tăng tốc, team bỏ bớt test & bỏ CI, chỉ đợi cuối dự án mới test kỹ” → ngược XP, ngược technical excellence.
- Câu hỏi: “Module A chỉ cho một dev chỉnh sửa để giữ trách nhiệm rõ ràng” → trái với collective code ownership.
- Câu hỏi: “Để tối ưu chi phí, cấm pair programming vì tốn 2 người/1 máy” → trái với spirit của XP (ưu tiên chất lượng & shared knowledge).
- Câu hỏi: “Team làm 60–70 giờ/tuần trong nhiều tháng để theo kịp deadline” → trái với sustainable pace.
Pattern cần nhớ:
- XP:
- Ưu tiên chất lượng kỹ thuật và feedback nhanh.
- Dùng nhiều engineering practices cụ thể (TDD, CI, refactoring, acceptance tests...).
- Scrum:
- Ưu tiên structure quản lý & collaboration ở cấp đội.
- Không chỉ định chi tiết về kỹ thuật như XP.
6. Checklist học & tự soi
- Giải thích được XP khác Scrum chỗ nào (về focus & audience).
- Kể tên và mô tả ngắn gọn 5 XP values.
- Mapping được XP Coach / Customer / Programmer / Tester sang Scrum Master / Product Owner / Developers/QA.
- Nhận diện được các practice XP trong đề: pair programming, TDD, CI, refactoring, collective code ownership, sustainable pace, customer/acceptance tests, Planning Game, Whole Team, System Metaphor…
- Nhìn vào một tình huống làm việc (OT triền miên / cấm pair programming / không test sớm) và chỉ ra nó phù hợp hay ngược XP.
Checklist – XP Terms (VI)
Mini-mock – XP Terms
- XP = Agile kỹ thuật, tập trung vào phát triển phần mềm.
- Nhìn thấy pair programming, TDD, CI, refactoring, customer/acceptance tests, collective code ownership, sustainable pace, Planning Game, Whole Team, System Metaphor → nghĩ ngay đến XP.
- XP Coach ≈ Scrum Master, Customer ≈ Product Owner, Programmers/Testers ≈ Developers/QA.
- XP ưu tiên quality + feedback sớm, không trade-off chất lượng để “cày đêm cho kịp deadline”.
- Scrum dùng được cho nhiều loại sản phẩm; XP chủ yếu dùng cho software development, thường được kết hợp với Scrum để tăng technical excellence.
XP Terms – Extreme Programming in plain language
Who this article is for
You come from a project management / business background and XP sounds overly technical.
You are a developer but want to understand XP from a PMI-ACP perspective, not just as “coding style”.
You want to distinguish XP from Scrum – where they are similar, where they differ, and how exam questions try to trick you.
TL;DR – Extreme Programming (XP) in 1 minute
Extreme Programming (XP) is an Agile method focused on software development, with concrete technical practices.
XP has:
Core values: Communication, Feedback, Simplicity, Respect, Courage (order varies by source; the “set of 5” matters most).
Roles: Customer (On-site Customer), Programmer, Tester, XP Coach.
Key practices: Small Releases, Simple Design, Pair Programming, Test-Driven Development (TDD), Refactoring, Continuous Integration, Collective Code Ownership, Coding Standards, Sustainable Pace, Customer/Acceptance Tests.
Compared to Scrum:
Scrum focuses more on work management & feedback at team/product level.
XP focuses more on how to code & organize technical work to maintain high quality.
In PMI-ACP, XP shows up mainly in questions about:
Engineering practices, technical excellence, and team collaboration in software development.
Suggested path:
- Read section 1 to see when to use XP and how it differs from Scrum – especially the Scrum + XP combo part.
- Learn the 5 XP values and the role mapping vs Scrum.
- Memorize the key XP practices (pair programming, TDD, CI...) for mini-mocks and the real exam.
- What is XP? When do we use it?
1.1. Short definition
- Extreme Programming (XP) is an Agile method originally designed for software development.
- Main goals:
- Improve software quality through good technical practices.
- Respond to changing requirements via fast, continuous feedback between the team and the customer.
Intuition:
- If Scrum is about how you organize the work and meetings (Sprint, Daily Scrum, Review, Retro),
- XP is a set of “coding habits” and “technical ways of working”:
- working in pairs,
- writing tests before code (TDD),
- integrating frequently (CI),
- constantly refactoring to keep the code clean.
1.2. XP vs Scrum – similarities and differences
Similarities (both Agile methods):
- Work is iterative & incremental.
- Strong emphasis on early feedback, customer collaboration, self-organizing teams.
- Focus on reducing waste and maximizing customer value.
Differences (for exam purposes):
- Scrum:
- Can be used for many kinds of products, not just software (services, marketing campaigns, building design, etc.).
- Focuses on a management framework: roles, events, artifacts.
- XP:
- Almost exclusively used for software development (it’s in the name).
- Focuses on technical and coding practices.
If a question talks about pair programming, TDD, continuous integration, refactoring..., it’s almost certainly pointing to XP / technical practices, not pure Scrum.
1.3. Scrum + XP combo in real life
In many real-world teams you’ll see:
- Scrum used to:
- Manage the work: Sprints, Product Backlog, Sprint Review, Retrospective.
- Provide cadence and feedback loops with business stakeholders.
- XP used to:
- Raise technical excellence: TDD, CI, refactoring, pair programming, coding standards, acceptance tests.
- Keep the codebase clean, maintainable, and low in defects.
Typical exam pattern:
- Question: “A Scrum team wants to improve technical quality. What should they do?”
→ Correct answers often talk about adopting XP practices (TDD, CI, refactoring, pair programming, acceptance tests…),
not about adding more meetings or doing heroic overtime.
- XP core values – the 5 “personality traits” of Extreme Programming
XP defines 5 core values. Understanding them helps you grasp the spirit behind the practices.
Quick note: You may see different ordering (or older sources mentioning 4). For PMI-ACP, prioritize knowing the set of 5 and what each means.
2.1. Simplicity
- Focus on “the simplest thing that could possibly work” – the simplest solution that delivers customer value.
- Avoid:
- Over-engineering (making the design too complex).
- Extra features that no one uses → waste.
Everyday example:
- Building an internal app that only needs daily/weekly/monthly reports:
- If you add 10 chart types and 7 dashboards but the team only uses one, most of it is waste.
- XP encourages:
- Starting with a “good enough” version, then refactoring & extending when there is real demand.
2.2. Communication
- The team needs to talk frequently and clearly; no “everybody in their own silo”.
- XP encourages:
- Daily communication (often in a daily standup, similar to Scrum).
- Pair programming → two people constantly discussing the same piece of code.
Example:
- Instead of each dev owning a separate module, XP likes:
- Two people at the same machine, discussing the same code and system.
2.3. Feedback
-
Feedback comes from:
- Customers (Customer / On-site Customer).
- Tests (unit tests + customer/acceptance tests).
- Pair programming / reviews.
-
Goal:
- “Fail fast, learn fast” – if it’s wrong, find out early while it’s still cheap to fix.
Example:
- Rather than coding the whole system and testing at the end,
- XP writes tests early, runs them frequently on every build → issues are visible immediately.
2.4. Courage
- Courage to face problems honestly and change the design when needed.
- Courage to:
- Refactor legacy code when it becomes messy.
- Add tests to “ugly” parts of the code before changing them.
- Admit “I don’t understand this” to your team.
Mental image:
- Making your code visible to everyone (collective code ownership) takes courage:
- code is no longer hidden in your private corner;
- anyone can comment, improve, or fix it.
2.5. Respect
- Respect different working styles and strengths.
- Share responsibility for project success/failure.
- Everyone in the team matters:
- Customer, Programmer, Tester, Coach…
In some traditional management books you may read “accountability cannot be shared”.
In XP, we want everyone to feel responsible, because the team is a single unit.
- XP roles – mapping them to Scrum roles
XP defines several roles. For PMI-ACP, it’s helpful to map them to Scrum.
3.1. XP Coach
- Responsibilities:
- Guides the team in applying XP values and practices.
- Acts as a servant leader: supporting, unblocking, facilitating rather than commanding.
- Keeps the team true to XP: pair programming, TDD, CI, refactoring, etc.
Comparison with Scrum:
- XP Coach ≈ Scrum Master:
- Both champion the Agile mindset, help the team self-organize, and buffer the team from external noise.
3.2. Customer / On-site Customer
- In XP this is often called Customer or On-site Customer:
- Represents the business, brings requirements & priorities.
- Ideally works closely with the team, often co-located.
- Helps write user stories and define customer/acceptance tests.
Comparison with Scrum:
- Customer / On-site Customer ≈ Product Owner:
- Both set product direction and priorities.
3.3. Programmers
- People who write the code and implement user stories.
- In XP, programmers:
- Often work in pair programming.
- Write unit tests (often using TDD: tests first, code second).
- Share collective ownership of the codebase.
Comparison with Scrum:
- Programmers ≈ Developers within the Scrum Team.
3.4. Testers
-
Help:
- Customers define acceptance tests for user stories.
- Design and execute tests to ensure quality.
-
In many teams the same person might both code and test, but XP still emphasizes the testing role clearly.
Comparison:
- Testers in XP are similar to people doing testing/QA within a Scrum Team.
- XP practices – key terms you’ll see in exam questions
PMI-ACP often checks your ability to recognize typical XP practices.
4.1. Core practices
-
User Stories
- A short way to capture requirements from the user’s perspective.
- Often in the format: As a [user], I want [something] so that [benefit].
-
Small Releases
- Release frequently in small, usable increments.
- Goal: put working software in users’ hands early and get real feedback.
-
Simple Design
- Design that is “just enough” for current needs, not overly complex.
- Combined with refactoring to keep the design healthy over time.
-
Pair Programming
- Two programmers sit at one machine:
- One “driver” types the code.
- One “navigator” thinks about design, edge cases, direction.
- Benefits:
- Higher quality code, faster knowledge sharing.
Everyday analogy:
- Like two people learning to drive:
- One holds the wheel, the other keeps saying “watch that corner, signal here, check the mirror.”
- Two programmers sit at one machine:
-
Test-Driven Development (TDD)
- The cycle: Red → Green → Refactor:
- Write a test first (it fails → red).
- Write just enough code to make the test pass (green).
- Refactor the code to make it cleaner while keeping tests green.
- Benefits:
- Better design, fewer bugs, safer refactoring.
- The cycle: Red → Green → Refactor:
-
Customer / Acceptance Tests
- Tests defined with/for the Customer/PO to validate the solution meets real needs (beyond unit tests).
- Common exam trick:
- “Tests” are not only developer-centric; acceptance tests support early customer feedback.
-
Refactoring
- Changing the internal structure of code to make it:
- Cleaner, easier to understand, easier to modify.
- Without changing its external behavior.
- Always combined with tests to ensure you don’t break functionality.
- Changing the internal structure of code to make it:
-
Continuous Integration (CI)
- Integrating code into the mainline frequently (often several times per day).
- Each integration:
- Triggers automated build and tests (unit + sometimes acceptance tests).
- Benefits:
- Find integration issues early, avoid “big bang merge” at the end.
-
Collective Code Ownership
- Any programmer can change any part of the code when needed.
- No “this is A’s module, nobody else touches it”.
- Fits well with pair programming and CI.
-
Coding Standards
- Agreed rules for:
- Code style, naming, layout, comments, etc.
- Goal:
- Code looks consistent, as if written by one person.
- Agreed rules for:
-
Sustainable Pace
- Working at a pace you can sustain long term (often summarized as a “40-hour work week”).
- Key idea: avoid chronic overtime → protect quality, learning, and team health.
-
Planning Game
- XP’s way of doing Release Planning & Iteration Planning.
- Customers prioritize by business value, programmers estimate technical effort → together they negotiate the scope for each iteration.
-
Whole Team
- Everyone needed to deliver the product (customer, dev, test, ops, etc.) is considered part of one team.
- Reduces “throwing work over the wall” between departments.
-
System Metaphor
- A simple, shared metaphor that describes how the system works (e.g., “like a post office delivering letters”).
- Helps the team discuss architecture in non-technical language.
In exams, practices like Planning Game, Whole Team, System Metaphor often appear at a name recognition level rather than in-depth questions. But when you see these terms, it’s a strong hint that the question is about XP.
4.2. How exam questions hint at XP
-
When you see:
- Pair programming, TDD, CI, refactoring, collective code ownership, sustainable pace, acceptance tests → XP is the keyword.
-
In comparison questions:
- Scrum: talks about Sprints, Product Backlog, Scrum Master, Product Owner...
- XP: talks about Coach, Customer/On-site Customer, Programmers, Testers, and technical practices.
-
If a question is about a Scrum team wanting to improve technical practices, the best answers usually say:
- Adopt XP practices (TDD, CI, refactoring, pair programming, coding standards, acceptance tests...),
- Not “work overtime” or “skip tests”.
- Exam patterns & traps – XP in PMI-ACP
- “To speed up, the team stops writing tests and drops CI, leaving testing to the very end” → against XP, against technical excellence.
- “Only one developer is allowed to modify module A to maintain clear accountability” → conflicts with collective code ownership.
- “To save costs, the team bans pair programming because it uses two people on one machine” → contradicts XP’s focus on quality and shared knowledge.
- “The team works 60–70 hours per week for many months to meet deadlines” → violates sustainable pace.
Patterns to remember:
- XP:
- Prioritizes technical quality and rapid feedback.
- Uses specific engineering practices (TDD, CI, refactoring, acceptance tests, etc.).
- Scrum:
- Focuses more on team-level structure and collaboration.
- Does not prescribe detailed technical practices like XP.
6. Checklist & self-reflection
Can you explain how XP differs from Scrum (in focus & audience) ?
- Can you name and describe the 5 XP values?
Can you map XP Coach / Customer / Programmers / Testers to Scrum Master / Product Owner / Developers/QA?
Can you recognize XP practices in a question: pair programming, TDD, CI, refactoring, collective code ownership, sustainable pace, customer/acceptance tests, Planning Game, Whole Team, System Metaphor…?
Can you look at a scenario (chronic overtime / banning pair programming / skipping early tests) and tell whether it supports or contradicts XP?
Checklist – XP Terms (EN)
Mini-mock – XP Terms
- XP = Agile for technical practices, focused on software development.
- Seeing pair programming, TDD, CI, refactoring, customer/acceptance tests, collective code ownership, sustainable pace, Planning Game, Whole Team, System Metaphor → think XP.
- XP Coach ≈ Scrum Master, Customer ≈ Product Owner, Programmers/Testers ≈ Developers/QA.
- XP values quality + early feedback; it does NOT trade quality for “heroic overtime”.
- Scrum is more widely applicable; XP is primarily used in software development, often combined with Scrum to increase technical excellence.