XP Practices
Ngôn ngữ • Language
- VI
- EN
XP Practices – “thói quen làm việc” của team XP
XP mạnh nhất ở chỗ: nó không chỉ nói “làm theo Agile”, mà nói thẳng team nên làm gì mỗi ngày để giữ chất lượng kỹ thuật cao.
TL;DR – XP Practices trong 1 phút
- XP practices thường xoay quanh 2 nhóm:
- Planning & collaboration: Planning Game (Release Planning + Iteration Planning), Small Releases, On-site Customer (Whole Team), Customer/Acceptance Tests.
- Technical excellence: Continuous Integration (CI), Test-Driven Development (TDD), Pair Programming, Simple Design, Refactoring, Coding Standards, Collective Code Ownership, Sustainable Pace (40-hour week), System Metaphor.
- PMI-ACP hay gài theo kiểu:
- “Bỏ test/CI để chạy deadline” → ngược XP.
- “Chỉ một người được sửa module” → ngược collective ownership.
- “OT triền miên” → ngược sustainable pace.
Khi gặp câu hỏi nói về engineering practices / technical excellence, hãy nghĩ ngay đến XP: TDD, CI, refactoring, pair programming, coding standards, collective code ownership, acceptance tests, sustainable pace (40-hour week), on-site customer/whole team.
- XP practices là gì?
XP practices là những “việc team XP làm thường xuyên” để:
- giữ chất lượng phần mềm cao, và
- nhận feedback sớm (từ customer và từ test),
- giảm rủi ro “làm xong mới biết sai”.
Nói vui cho dễ nhớ:
- Scrum giống “lịch sinh hoạt & cách quản việc” của team (Sprint, Daily, Review, Retro).
- XP giống “bộ thói quen kỹ thuật” để code sạch, ít lỗi, dễ nâng cấp.
- Planning Game – XP gọi planning là “game”
Trong XP, “planning activities” đôi khi được gọi là games (Planning Game). Bạn có thể coi nó gồm 2 lớp:
2.1 Release Planning (lập kế hoạch phát hành)
- Release = thứ “đưa tới tay người dùng” (installable/usable).
- Release Planning = quyết định:
- release tới sẽ gồm những tính năng nào,
- cần bao nhiêu iteration để ra được một bản release đủ dùng.
Điểm hay gặp trong đề (và cần nói “chuẩn PMI” cho an toàn):
- Kết thúc mỗi iteration nên tạo ra working software / usable increment (demo được, chạy được, có thể đưa lên staging).
- Business có thể chưa chọn deploy production ngay (ví dụ: timing thị trường, kiểm soát rủi ro, hoặc gom đủ “mảnh” để release có ý nghĩa).
- Vì vậy, release planning thường bàn: “muốn ship một release có ý nghĩa với user thì cần bao nhiêu iteration/increment.”
Vai trò quyết định “cái gì vào release” là ai?
- Trong XP: Customer / On-site Customer quyết định ưu tiên theo nhu cầu business.
- Team dev cung cấp ước lượng và trao đổi về khả năng thực hiện.
Ví dụ đời thường:
- Làm hệ thống “invoices + payments”:
- Chỉ có “danh sách khách hàng” → chưa đủ dùng.
- Có “tạo hoá đơn” → vẫn chưa đủ dùng.
- Có “thu tiền” → tốt hơn.
- Nhưng business nói “phải có thanh toán thẻ tín dụng” mới gọi là “release có ý nghĩa”. => Release Planning là lúc customer nói: “Muốn release được, phải đủ các mảnh này.”
2.2 Iteration Planning (lập kế hoạch cho 1 vòng lặp)
- Trong XP: Iteration thường tương đương ý nghĩa với Sprint trong Scrum.
- Một iteration thường là timebox ngắn (hay gặp 1–2 tuần; một số team dùng dài hơn, tối đa khoảng vài tuần).
Iteration Planning tương tự Sprint Planning:
- Customer giải thích “iteration này muốn deliver cái gì”.
- Developers chia nhỏ thành tasks, ước lượng thời gian/effort.
- Team dự báo phạm vi dựa trên dữ liệu đã làm được trước đó (velocity/throughput).
Ví dụ dễ hình dung:
- Hỏi thợ sơn “sơn phòng này mất bao lâu?”
→ họ dựa vào “phòng tương tự trước đây sơn mất bao lâu”. - Team Agile cũng vậy: dựa vào dữ liệu iteration trước để biết iteration này “ôm được bao nhiêu”.
- Small Releases – release nhỏ, thường xuyên (thậm chí lên test environment)
Small Releases = ra phiên bản nhỏ, đều đặn, để:
- tăng visibility cho customer,
- nhận feedback sớm,
- giảm rủi ro “đợi cuối mới kiểm”.
Lưu ý thực tế/đề thi hay gài:
- “release nhỏ” không bắt buộc nghĩa là “đẩy thẳng production”.
- Nhiều team XP đ ẩy bản nhỏ lên test/staging environment trước để chạy test kỹ, cho customer dùng thử, rồi mới production.
Kết quả:
- progress rõ ràng hơn,
- chất lượng được giữ nhờ test chặt,
- customer “sờ được” sản phẩm sớm.
- Customer / Acceptance Tests – “test đúng nghĩa phải do người dùng định nghĩa”
Customer Tests (hiểu như acceptance tests theo góc nhìn business):
- Customer mô tả một hoặc vài bài test để chứng minh “phần mềm đáp ứng yêu cầu”.
- Team biến nó thành test có thể chạy được, lý tưởng là tự động hoá.
Để “bắt keyword” chắc hơn cho PMI-ACP, nhớ 2 tầng test hay bị hỏi lẫn:
- Unit Tests (dev-centric): bảo vệ logic nhỏ, hỗ trợ TDD, giúp refactor không sợ “gãy”.
- Acceptance/Customer Tests (business-centric): chứng minh “đúng nhu cầu”, thường là end-to-end theo luồng nghiệp vụ.
Vì sao customer phải là người “định nghĩa test quan trọng”?
- Dev giỏi đến đâu vẫn có thể làm “đúng kỹ thuật” nhưng không đúng nhu cầu.
- Người dùng/business mới biết “thế nào là dùng được”.
Ví dụ:
- Customer nói: “Tôi muốn test theo luồng: tạo hoá đơn → gửi hoá đơn → nhận thanh toán thẻ ngay.”
- Team sẽ tìm cách automate/verify luồng đó.
4.1 On-site Customer / Whole Team – XP “kéo customer lại gần team”
On-site Customer (thường đi kèm tinh thần Whole Team) nghĩa là:
- Có đại diện business/customer luôn sẵn sàng trả lời câu hỏi, làm rõ yêu cầu, ưu tiên, tiêu chí chấp nhận.
- Mục tiêu: giảm “đợi phản hồi 3 ngày”, giảm hiểu sai → giảm rework.
Lưu ý “phiên bản hiện đại” (team phân tán):
- “On-site” không nhất thiết là ngồi cùng phòng. Có thể là customer proxy/PO luôn available qua chat/call trong giờ làm để team hỏi là có câu trả lời nhanh.
Nói đời thường:
- Bạn xây nhà mà chủ nhà không bao giờ nghe máy thì thợ phải “đoán ý” → dễ sửa đi sửa lại.
- On-site customer giúp team hỏi là có câu trả lời nhanh, làm đúng ngay từ đầu.
Nếu câu hỏi nhấn mạnh “đảm bảo đúng nhu cầu người dùng” + “đo bằng điều kiện chấp nhận” → nghĩ đến acceptance/customer tests và on-site customer/whole team.
- Collective Ownership • Coding Standards • Sustainable Pace
5.1 Collective Code Ownership (ai cũng “có quyền” sửa code)
Collective Code Ownership nghĩa là:
- Bất kỳ cặp dev nào cũng có thể sửa phần code nào đó khi cần.
- Không có “đây là code của Bob, cấm ai đụng”.
Lợi ích:
- nhiều người nhìn → ít lỗi hơn,
- chia sẻ kiến thức → giảm rủi ro khi một dev nghỉ/điều chuyển,
- tránh “kẹt cổ chai” do một người giữ kiến thức.
5.2 Coding Standards (Agile không có nghĩa là “code bừa”)
Coding Standards giúp:
- code nhìn như “một người viết”,
- dễ đọc, dễ review, dễ maintain,
- phù hợp với collective ownership (ai cũng sửa được vì code thống nhất).
5.3 Sustainable Pace (nhịp độ bền vững) = “40-hour week” trong XP classic
Sustainable Pace nhấn mạnh:
- đôi khi OT ngắn hạn có thể xảy ra,
- nhưng OT lặp lại dài hạn là không bền (burnout, bug tăng, chất lượng giảm).
Trong XP “cổ điển”, bạn sẽ gặp từ khoá 40-hour week — ý chính vẫn là:
- làm việc theo nhịp độ bền vững,
- không lấy “heroic overtime” làm chiến lược.
PMI-ACP rất thích tinh thần:
- tối ưu giá trị dài hạn,
- không đánh đổi chất lượng bằng kiệt sức.
- System Metaphor – dùng ẩn dụ để team “nhìn cùng một thứ”
Metaphor trong XP là:
- một cách mô tả hệ thống bằng hình ảnh/ẩn dụ dễ hiểu
- để customer và dev cùng “đồng bộ” cách hiểu.
Ví dụ:
- “Module hoá đơn giống như một nhân viên kế toán công nợ (accounts receivable) – nhiệm vụ là đảm bảo tiền được thu về.”
Vì sao nó hữu ích?
- Vấn đề khó nhất của dự án thường là: customer tưởng một kiểu, dev hiểu một kiểu.
- Metaphor giúp giảm “lệch pha”, tạo ngôn ngữ chung.
Ghi chú “PMI-safe”:
- Đây là practice kiểu classic XP; nhiều team hiện đại dùng domain language / ubiquitous language (ngôn ngữ chung của nghiệp vụ) để đạt mục tiêu tương tự.
- CI • TDD • Pair Programming – bộ 3 hay gặp nhất trong đề
7.1 Continuous Integration (CI)
Continuous Integration = tích hợp code thường xuyên vào mainline và kiểm tra liên tục:
- build + chạy test tự động,
- lỗi lòi ra sớm trước khi “đắp thêm tầng”.
Lý do:
- code mới có thể vô tình làm “gãy” code cũ (bug, crash, regression).
- CI giúp phát hiện sớm, sửa rẻ.
7.2 Test-Driven Development (TDD)
TDD = viết test trước, rồi viết code để pass test. Cách phổ biến: Red → Green → Refactor.
Nghe “lạ” nhưng dễ hiểu bằng ví dụ học thi:
- Bạn làm đề thử trước để biết “đề hay hỏi gì”.
- Rồi bạn học vào đúng chỗ để làm được đề.
- Kết quả: học có mục tiêu, ít lan man.
7.3 Pair Programming (pair code) — 2 người code 1 việc, nhưng không phải “2 người làm 1 việc cho vui”
Pair Programming = 2 dev cùng làm một story/task trên cùng một “luồng suy nghĩ”:
- Driver: người gõ code, xử lý chi tiết ngay trước mắt.
- Navigator: người quan sát, soi lỗi, nghĩ hướng tổng thể (logic, edge cases, thiết kế, test, naming).
Nói đời thường: Driver là “tay lái”, Navigator là “người ngồi bên nhắc đường + nhắc coi chừng ổ gà”.
Vì sao XP thích pair code?
- Review real-time: lỗi nhỏ được bắt ngay, khỏi đợi PR mới thấy.
- Chia sẻ kiến thức nhanh: codebase không bị “một người một cõi” → hỗ trợ Collective Ownership.
- Chất lượng ổn định hơn: ít bug, ít rework → về lâu dài thường nhanh hơn dù nhìn bề ngoài “tốn 2 người”.
Làm pair code kiểu “chuẩn XP” (rất hay lên đề)
- Luân phiên vai trò (driver ↔ navigator) mỗi 15–30 phút, hoặc khi chuyển đoạn việc.
- Navigator không ngồi im: phải actively review, nghĩ test cases, hỏi “nếu user làm X thì sao?”.
- Ưu tiên pair khi:
- code rủi ro cao (payment, security),
- module khó,
- onboarding người mới,
- bug “lặp đi lặp lại” khó trị.
Anti-pattern (bẫy PMI-ACP hay gài)
- “Pair programming = 2 người cùng gõ vào 2 máy” → sai. (đó là 2 người làm 2 việc)
- “Navigator chỉ ngồi xem TikTok chờ driver code xong” → sai.
- “Cấm pair vì tốn người, cứ làm nhanh rồi test sau” → thường ngược XP (tăng bug, tăng chi phí sửa).
- “Pair 8 tiếng/ngày mọi lúc” → cực đoan; XP khuyến khích dùng đúng chỗ, vẫn phải giữ Sustainable Pace.
Thấy bối cảnh “nhiều defect”, “knowledge silo”, “code review quá muộn”, “junior lên dự án” → đáp án thường nghiêng về Pair Programming + Coding Standards + Collective Ownership + CI/TDD (tổ hợp nâng chất lượng).
- Simple Design • Refactoring – giữ code “sạch và đủ dùng”
8.1 Simple Design
Simple Design nhấn mạnh:
- làm cái đơn giản nhất có thể chạy và tạo giá trị,
- code nên testable, readable, explainable.
Câu thần chú:
- “Do the simplest thing that could possibly work.”
8.2 Refactoring
Refactoring là “dọn code” một cách có kỷ luật:
- bỏ trùng lặp,
- xoá phần không dùng,
- cải thiện thiết kế,
- giữ code sạch theo thời gian.
Nói nôm na:
- càng code lâu càng dễ sinh “rác” (đoạn thừa, comment thừa, logic rối).
- refactor là lúc mình “lau nhà” để về sau sửa nhanh hơn và ít bug hơn.
9) Practice → Intent → Exam keywords (bảng nhồi nhanh)
| Practice (XP) | Intent (ý nghĩa) | Exam keywords hay gặp |
|---|---|---|
| Planning Game | Align scope + estimates | release planning, iteration planning, customer prioritization |
| Small Releases | Feedback sớm, giảm rủi ro big-bang | frequent release, staging, early feedback |
| On-site Customer / Whole Team | Giảm lệch pha, hỏi-đáp nhanh | on-site customer, collaboration, shared understanding |
| Customer/Acceptance Tests | “Working” theo góc nhìn business | acceptance criteria, E2E, customer tests |
| CI | Tích hợp + test liên tục | integrate often, automated build/test |
| TDD | Test trước để dẫn đường code | red-green-refactor, unit tests |
| Pair Programming | Review real-time + chia sẻ kiến thức | driver/navigator, rotate roles, real-time review |
| Refactoring | Giữ code sạch lâu dài | clean code, remove duplication |
| Coding Standards | Code thống nhất, dễ sửa | consistency, readability |
| Collective Ownership | Không độc quyền code | shared codebase, no single owner |
| Sustainable Pace (40-hour week) | Bền vững, tránh burnout | no chronic overtime, burnout |
| System Metaphor | Ngôn ngữ chung cho hệ thống | shared story, align understanding |
- Exam patterns & traps – bẫy XP trong PMI-ACP
- “Bỏ test/CI để chạy deadline” → ngược XP (giảm chất lượng, tăng rủi ro).
- “Chỉ một người được sửa module để giữ accountability” → ngược collective ownership.
- “Cấm pair programming vì tốn 2 người” → bỏ mất lợi ích chất lượng & shared knowledge.
- “OT 60–70h/tuần nhiều tháng” → ngược sustainable pace (40-hour week).
- “Customer chỉ họp lúc kickoff, còn lại dev tự đoán” → ngược on-site customer/whole team.
11) Checklist học nhanh
Checklist – XP Practices (VI)
Mini-mock – XP Practices
- XP = tập hợp thực hành cụ thể để giữ technical excellence và feedback sớm.
- Thấy Planning Game, Small Releases, On-site Customer/Whole Team, Customer Tests, CI, TDD, Pair Programming, Refactoring, Collective Ownership, Sustainable Pace (40-hour week) → gần như chắc là XP.
- Đề PMI-ACP hay gài bằng các “anti-pattern”: bỏ test/CI, OT triền miên, độc quyền code, customer “biến mất”.
XP Practices – what an XP team actually does (in plain language)
XP is powerful because it doesn’t just say “be Agile”. It tells the team what to do every day to keep technical excellence and get fast feedback.
TL;DR – XP Practices in 1 minute
XP practices usually fall into two buckets:
Planning & collaboration: Planning Game (Release Planning + Iteration Planning), Small Releases, On-site Customer (Whole Team), Customer/Acceptance Tests.
Technical excellence: Continuous Integration (CI), Test-Driven Development (TDD), Pair Programming, Simple Design, Refactoring, Coding Standards, Collective Code Ownership, Sustainable Pace (40-hour week), System Metaphor.
Common PMI-ACP traps:
- “Skip tests/CI to hit the deadline” → anti-XP.
- “Only one person can touch module A” → anti-collective ownership.
- “Chronic overtime” → anti-sustainable pace.
If a question emphasizes engineering practices / technical excellence, think XP: TDD, CI, refactoring, pair programming, coding standards, collective code ownership, acceptance tests, sustainable pace (40-hour week), on-site customer / whole team.
- What are XP practices?
XP practices are the “things an XP team does regularly” to:
- keep software quality high,
- get fast feedback (from customers and from tests),
- avoid discovering problems only at the end.
A simple way to remember:
- Scrum is mainly about work structure and cadence (events, roles, artifacts).
- XP is mainly about daily engineering habits that protect quality.
- Planning Game – XP calls planning a “game”
In XP, planning activities are often called games (the Planning Game). Think of two layers:
2.1 Release Planning
A release is something users can actually install/use.
Release planning decides what goes into a release and how many iterations are needed to make it truly meaningful to ship.
Important (PMI-safe) nuance:
Each iteration should produce working software / a usable increment (demo-able, testable, safe to push to staging).
But business may choose not to deploy to production yet (e.g., timing, risk controls, bundling a coherent release).
That’s why release planning often discusses how many iterations are needed to assemble a “ship-worthy” release.
Who decides what “must be in the release”?
- In XP: the Customer / On-site Customer prioritizes based on business needs.
- The team provides estimates and negotiates scope realistically.
2.2 Iteration Planning
In XP, an iteration is essentially the same idea as a Scrum sprint.
It is a short, timeboxed cycle (often 1–2 weeks; sometimes longer, up to a few weeks).
Iteration Planning is like Sprint Planning:
- The customer explains what they want in this iteration.
- Developers break work into tasks and estimate effort.
- The team forecasts scope based on previous performance (velocity/throughput).
Everyday analogy:
Ask a painter how long a hall takes to paint — they’ll use past experience with similar rooms.
Agile teams do the same using historical data from previous iterations.
- Small Releases – frequent, small drops (often to test/staging first)
Small releases mean releasing small increments frequently to:
- increase customer visibility,
- get earlier feedback,
- reduce “big bang” risk.
Practical (and exam-friendly) nuance: “small release” doesn’t always mean “ship straight to production”. Many teams push small increments to test/staging first to run rigorous tests and let customers try it safely.
- Customer / Acceptance Tests – the customer defines what “working” means
Customer tests (think acceptance tests from a business viewpoint):
- The customer describes one or more tests that prove the software meets real needs.
- The team implements and ideally automates those tests.
PMI-ACP often mixes test levels, so remember this split:
- Unit tests (dev-centric): protect small logic, enable safe refactoring, support TDD.
- Acceptance/customer tests (business-centric): prove end-to-end behavior meets acceptance criteria.
Why does the customer define the best “proof”? Because devs can build something technically correct but not what users actually need.
Example:
- Customer test: “Create an invoice → send it → receive payment instantly via credit card.”
- Team automates/verifies that end-to-end flow.
4.1 On-site Customer / Whole Team – keep business close
On-site Customer means a business/customer representative is available to clarify requirements, priorities, and acceptance criteria quickly.
It often comes with the Whole Team mindset: everyone collaborates tightly to reduce misunderstandings and rework.
Modern nuance (distributed teams):
“On-site” doesn’t have to mean “same room”. It can mean a customer proxy/PO is reliably available via chat/calls during working hours for fast clarifications.
Everyday translation:
- If the “owner” never answers questions, builders are forced to guess — then redo work later.
- On-site customer reduces guessing and speeds up correct decisions.
- Collective Ownership • Coding Standards • Sustainable Pace
5.1 Collective Code Ownership
- Any developer pair can improve or fix any part of the code.
- No “this is Bob’s code, don’t touch it”.
Benefits:
- More eyes → fewer defects.
- Shared knowledge → lower risk if someone leaves.
- Less bottleneck behavior.
5.2 Coding Standards
- Agile does not mean “messy code”.
- Standards make the codebase feel like it was written by one skilled programmer.
- It supports collective ownership and faster reviews.
5.3 Sustainable Pace (aka “40-hour week” in classic XP)
- Short bursts of overtime may happen.
- But repeatable long hours are unsustainable (burnout, more bugs, lower quality).
- Classic XP often uses the keyword 40-hour week for the same idea.
- System Metaphor – a shared story to align understanding
A metaphor is a simple shared comparison that helps all stakeholders understand how the system should work.
Example:
“The invoicing module is like an accounts receivable clerk — its job is to make sure money gets collected.”
Why it matters:
- Customers and builders often “see different things” even when they talk a lot.
- A metaphor reduces misunderstanding by creating a shared language.
PMI-safe note:
System Metaphor is a more classic XP practice; many modern teams achieve the same goal via shared domain language (ubiquitous language).
- CI • TDD • Pair Programming – the “big 3” you’ll see in exams
7.1 Continuous Integration (CI)
- Integrate frequently into mainline.
- Run automated build + tests.
- Surface problems early before more code piles on.
7.2 Test-Driven Development (TDD)
- Write tests first, then write code to satisfy them.
- Common loop: Red → Green → Refactor.
Everyday analogy:
- Do a practice exam first, then study with the questions in mind.
- You learn with clearer targets and validate progress continuously.
7.3 Pair Programming (“pair coding”) — two people, one task, one shared flow
Pair programming means two developers work on the same story/task together:
- Driver: types code and handles immediate details.
- Navigator: reviews in real time, thinks ahead (logic, edge cases, design, tests, naming).
Everyday picture: the driver “steers”, the navigator “reads the map and watches for potholes”.
Why XP likes pairing
- Real-time review: catch defects early, not days later in a PR.
- Fast knowledge sharing: reduces silos and supports collective ownership.
- More stable quality: fewer bugs and less rework — often faster overall in the long run.
How to do it the “XP way” (exam-friendly)
- Rotate roles (driver ↔ navigator) every 15–30 minutes or when switching tasks.
- The navigator should stay active: propose test cases, question assumptions, spot risks.
- Pair especially when work is high-risk (payments/security), complex, onboarding new members, or recurring hard bugs.
Common traps (PMI-ACP loves these)
- “Pair programming = two people coding separately on two laptops” → not pairing.
- Navigator is passive (just watching) → misses the point.
- “Ban pairing because it costs two people; we’ll test later” → typically anti-XP (more defects, more rework).
- “Pair all day, every day, for everything” → extreme; use it where it adds value and protect sustainable pace.
If the scenario mentions “too many defects”, “knowledge silos”, “late code reviews”, or “junior onboarding”, answers often point to a combo of Pair Programming + Coding Standards + Collective Ownership + CI/TDD.
- Simple Design • Refactoring – keep the code clean and “just enough”
8.1 Simple Design
- Do the simplest thing that could possibly work.
- Keep design testable, readable, explainable.
8.2 Refactoring
- Remove redundancy, eliminate unused functionality, improve structure.
- Clean code continuously to save time and increase quality.
9) Practice → Intent → Exam keywords (quick cram table)
| Practice (XP) | Intent | Common exam keywords |
|---|---|---|
| Planning Game | Align scope + estimates | release planning, iteration planning, customer prioritization |
| Small Releases | Early feedback, reduce big-bang risk | frequent release, staging, early feedback |
| On-site Customer / Whole Team | Fast clarification, less rework | on-site customer, collaboration, shared understanding |
| Customer/Acceptance Tests | Define “working” from business view | acceptance criteria, end-to-end, customer tests |
| CI | Integrate + test continuously | integrate often, automated build/test |
| TDD | Let tests drive design | red-green-refactor, unit tests |
| Pair Programming | Real-time review + learning | driver/navigator, rotate roles, real-time review |
| Refactoring | Keep code clean over time | clean code, remove duplication |
| Coding Standards | Consistency + maintainability | consistency, readability |
| Collective Ownership | Avoid single-owner bottlenecks | shared codebase, no single owner |
| Sustainable Pace (40-hour week) | Long-term quality | no chronic overtime, burnout |
| System Metaphor | Shared language | shared story, align understanding |
- Exam patterns & traps – XP in PMI-ACP
- “Stop tests and drop CI to go faster” → anti-XP.
- “Only one developer can modify module A” → anti-collective ownership.
- “Ban pair programming because it costs two people” → misses XP’s quality/learning benefits.
- “Work 60–70 hours every week for months” → violates sustainable pace (40-hour week).
- “Customer only shows up at kickoff, then disappears” → anti on-site customer/whole team.
11) Checklist & self-reflection
Checklist – XP Practices (EN)
Mini-mock – XP Practices
- XP = concrete practices for technical excellence + early feedback.
- Seeing Planning Game, Small Releases, On-site Customer/Whole Team, Customer Tests, CI, TDD, Pair Programming, Refactoring, Collective Ownership, Sustainable Pace (40-hour week) → think XP.
- PMI-ACP often tests XP via anti-patterns (skip tests/CI, chronic overtime, single-owner code, “missing customer”).