Ngân hàng đề — PMP® Mock Exam Set I Exam

Đáp án

D — MA TRẬN RACI (đây KHÔNG phải phương pháp trình bày hiệu suất dự án).

Vì sao đúng

⚠ Vì sao RACI không thuộc nhóm này: | Lý do | Nội dung | |---|---| | ⚠ RACI thể hiện VAI TRÒ và TRÁCH NHIỆM | ⚠ ai làm, ai chịu trách nhiệm, ai được hỏi, ai được báo | | ⚠ Nó KHÔNG chứa dữ liệu về TIẾN ĐỘ hay CHI PHÍ | | | ⚠ Nó là công cụ của quản lý NGUỒN LỰC | ⚠ liên hệ #25944 lô 184 — định nghĩa vai trò và trách nhiệm | | ⚠ Ba phương án còn lại đều hiển thị SỐ LIỆU theo thời gian hoặc phân bố | | | ⚠ Kết luận | ⚠ RACI trả lời "AI làm gì", ba cái kia trả lời "dự án đang thế nào" |

Vì sao các phương án khác sai

• C (biểu đồ tần suất — histogram) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như công cụ chất lượng thuần tuý: ⚠ nhưng histogram ⚠ ĐƯỢC dùng để trình bày hiệu suất ⚠ — biểu đồ tần suất nguồn lực (resource histogram) cho thấy mức sử dụng nhân lực theo thời gian, và phân bố lỗi theo loại.

• B (đường cong S) — ⚠ công cụ kinh điển trình bày chi phí hoặc công việc tích luỹ theo thời gian ⚠ (liên hệ #25920 lô 183).

• A (biểu đồ thanh — bar chart) — ⚠ biểu đồ Gantt là một dạng biểu đồ thanh, ⚠ công cụ trình bày tiến độ phổ biến nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25920 ở lô 183 (đường cong chữ S của chi tiêu), câu #25967 lô 185 (phân tích xu hướng lỗi), câu #26045 ở lô này (Monte Carlo), và câu #25944 lô 184 (ma trận RACI). ⚠ Nhóm công cụ trình bày và phân tích.

⚠ Các công cụ TRÌNH BÀY hiệu suất dự án: | Công cụ | Trình bày gì | |---|---| | ⚠ BIỂU ĐỒ THANH / GANTT | ⚠ lịch trình, tiến độ từng hoạt động | | ⚠ ĐƯỜNG CONG S | ⚠ chi phí hoặc công việc TÍCH LUỸ theo thời gian | | ⚠ HISTOGRAM | ⚠ phân bố — mức dùng nguồn lực, tần suất lỗi | | ⚠ BẢNG ĐIỀU KHIỂN (dashboard) | ⚠ tổng hợp nhiều chỉ số, thường dùng đèn giao thông | | ⚠ BURNDOWN / BURNUP | ⚠ công việc còn lại hoặc đã xong trong agile | | ⚠ BIỂU ĐỒ LUỒNG TÍCH LUỸ | ⚠ WIP và thời gian chu kỳ — Kanban | | ⚠ Không thuộc nhóm này | ⚠ RACI (vai trò), WBS (phạm vi), sơ đồ mạng (trình tự), sổ rủi ro |

⚠ Ma trận RACI — nhắc lại: | Chữ | Nghĩa | |---|---| | ⚠ R — Responsible | ⚠ người THỰC HIỆN công việc | | ⚠ A — Accountable | ⚠ người CHỊU TRÁCH NHIỆM cuối cùng — chỉ MỘT người mỗi việc | | ⚠ C — Consulted | ⚠ được HỎI Ý KIẾN trước khi làm | | ⚠ I — Informed | ⚠ được THÔNG BÁO sau khi làm | | ⚠ Lỗi hay gặp | ⚠ hai chữ A cho một việc — thực chất là KHÔNG AI chịu trách nhiệm | | ⚠ Thuộc lĩnh vực | ⚠ quản lý NGUỒN LỰC, không phải giám sát và kiểm soát |

Từ khoá nhận diện:

"biểu đồ thanh, đường cong S, histogram, dashboard" → ⚠ trình bày hiệu suất "RACI" → ⚠ vai trò và trách nhiệm "WBS" → ⚠ phạm vi ⚠ Câu có chữ "KHÔNG" → ⚠ tìm công cụ thuộc LĨNH VỰC KHÁC

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có phù hợp với người đọc không | | | Có ai đọc biểu đồ của bạn mà hiểu sai không | ⚠ liên hệ #26051 cùng lô — nhà tài trợ tưởng lag là dự phòng | | Ma trận RACI của bạn có việc nào hai chữ A không | |

Và cách phân biệt nhanh trong mọi câu hỏi kiểu này: công cụ nào có TRỤC THỜI GIAN hoặc có SỐ LIỆU đo được thì trình bày hiệu suất; công cụ nào chỉ có TÊN NGƯỜI và TÊN VIỆC thì không.

Đáp án

D — KHI HAI LẬP TRÌNH VIÊN HOÀN THÀNH MỘT PHIÊN LẬP TRÌNH CẶP.

Vì sao đúng

⚠ Vì sao lập trình cặp có vòng phản hồi ngắn nhất: | Lý do | Nội dung | |---|---| | ⚠ Phản hồi diễn ra trong VÀI GIÂY | ⚠ người kia thấy lỗi ngay lúc bạn đang gõ | | ⚠ Không cần chờ build, không cần chờ họp, không cần chờ ai đọc | | | ⚠ Rà soát mã diễn ra ĐỒNG THỜI với việc viết mã | | | ⚠ Là vòng phản hồi NGẮN NHẤT trong mọi thực hành agile | | | ⚠ So sánh | ⚠ daily standup: 1 ngày · CI build: vài phút · lập trình cặp: VÀI GIÂY |

Vì sao các phương án khác sai

• A (tại buổi standup hằng ngày) — ⚠ phương án gây nhiễu mạnh nhất vì daily scrum thật sự là vòng phản hồi ngắn nhất trong các SỰ KIỆN của Scrum: ⚠ nhưng chu kỳ của nó là ⚠ MỘT NGÀY, ⚠ dài hơn nhiều so với vài giây của lập trình cặp; ⚠ câu hỏi hỏi vòng NGẮN NHẤT trong dự án, không giới hạn ở sự kiện Scrum.

• C (bộ phận kinh doanh rà soát một bản phát hành mục tiêu) — ⚠ chu kỳ tính bằng tuần hoặc tháng.

• B (hoàn thành kiểm thử beta) — ⚠ chu kỳ dài nhất trong bốn phương án; ⚠ diễn ra gần cuối.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26019 ở lô 185 (ghép cặp lập trình viên trẻ với người có kinh nghiệm), câu #26042 ở lô này (TDD), câu #26053 (tích hợp liên tục), và câu #26047 (vực đánh giá do vòng phản hồi bị đứt). ⚠ Cả nhóm về vòng phản hồi — chủ đề xương sống của agile.

⚠ THANG VÒNG PHẢN HỒI trong agile — từ ngắn tới dài: | Vòng | Chu kỳ | |---|---| | ⚠ LẬP TRÌNH CẶP | ⚠ vài GIÂY — CÂU NÀY | | ⚠ TDD (đỏ-xanh-tái cấu trúc) | ⚠ vài PHÚT — liên hệ #26042 | | ⚠ Build của CI | ⚠ vài phút tới vài chục phút — liên hệ #26053 | | ⚠ DAILY SCRUM | ⚠ một NGÀY | | ⚠ SPRINT REVIEW và RETROSPECTIVE | ⚠ một tới bốn TUẦN | | ⚠ Phát hành cho người dùng | ⚠ vài tuần tới vài tháng | | ⚠ Kiểm thử beta, phản hồi thị trường | ⚠ dài nhất | | ⚠ Nguyên tắc nền tảng | ⚠ vòng càng NGẮN thì sai lầm càng RẺ — toàn bộ agile được thiết kế quanh ý tưởng này |

Từ khoá nhận diện:

"vòng phản hồi ngắn nhất" → ⚠ lập trình cặp "phản hồi hằng ngày" → ⚠ daily scrum "phản hồi mỗi sprint" → ⚠ sprint review "phản hồi từ thị trường" → ⚠ dài nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Vòng phản hồi NGẮN NHẤT trong dự án của bạn dài bao lâu | | | Lỗi gần nhất mất bao lâu từ lúc gây ra tới lúc phát hiện | ⚠ con số này nói lên nhiều điều về quy trình | | Có vòng phản hồi nào đang bị đứt không | ⚠ liên hệ #26047 — vực đánh giá |

Và cách hiểu gọn nhất về toàn bộ agile qua một câu hỏi: mọi thực hành trong đó — từ lập trình cặp vài giây tới sprint review vài tuần — đều là cùng một ý tưởng ở các quy mô thời gian khác nhau: rút ngắn khoảng cách giữa lúc làm sai và lúc biết mình đã sai.

Đáp án

C — Dự án chi 1 ĐÔ LA để thu về 89 XU giá trị công việc.

Vì sao đúng

⚠ Đọc chỉ số CPI: | Thành phần | Nội dung | |---|---| | ⚠ CPI = EV ÷ AC | ⚠ giá trị thu được chia chi phí thực tế | | ⚠ CPI = 0,89 | ⚠ mỗi đô la bỏ ra chỉ đổi lấy 89 xu giá trị công việc | | ⚠ CPI < 1 | ⚠ VƯỢT CHI — hiệu suất chi phí kém | | ⚠ CPI = 1 | ⚠ đúng kế hoạch | | ⚠ CPI > 1 | ⚠ dưới ngân sách — tốt | | ⚠ Cách đọc dễ nhớ nhất | ⚠ CPI chính là số xu giá trị thu được trên mỗi đô la chi ra |

⚠ Dự báo cho dự án này: | Chỉ số | Phép tính | |---|---| | ⚠ EAC = BAC ÷ CPI | ⚠ 750.000 ÷ 0,89 ≈ 842.700 | | ⚠ VAC = BAC − EAC | ⚠ 750.000 − 842.700 ≈ −92.700 — vượt chi gần 93.000 | | ⚠ Kết luận | ⚠ nếu hiệu suất giữ nguyên, dự án sẽ vượt ngân sách khoảng 12,4% |

Vì sao các phương án khác sai

• A (dự án nhiều khả năng kết thúc khớp với đường cơ sở chi phí) — ⚠ phương án gây nhiễu mạnh nhất vì nghe trung tính và an toàn: ⚠ nhưng ⚠ CPI 0,89 dự báo VƯỢT CHI rõ ràng; ⚠ khớp đường cơ sở đòi hỏi CPI xấp xỉ 1,0.

• B (dự án nhiều khả năng kết thúc DƯỚI ngân sách) — ⚠ ngược hoàn toàn; ⚠ dưới ngân sách cần CPI > 1.

• D (dự án đang chạy tốt) — ⚠ sai; ⚠ CPI dưới 1 là dấu hiệu vấn đề về chi phí.

Ghi nhớ

⚠ Đối chiếu — họ EVM đã gặp: ⚠ #25581 lô 176 (CV), #25648 (CPI 0,91), #25685 lô 179 (CPI 0,96), #25708 (ETC), #25718 (CPI 0,93), #25985 lô 185 (EV = 80.000), #26027 (EAC là công cụ dự báo), ⚠ và câu này. ⚠ TÁM câu EVM — và đây là câu duy nhất hỏi cách DIỄN GIẢI ý nghĩa của CPI bằng lời.

⚠ Bảng đọc nhanh CPI và SPI: | Giá trị | CPI | SPI | |---|---|---| | ⚠ Dưới 1 | ⚠ vượt chi — mỗi đồng thu về ít hơn một đồng giá trị | ⚠ chậm tiến độ | | ⚠ Bằng 1 | ⚠ đúng ngân sách | ⚠ đúng tiến độ | | ⚠ Trên 1 | ⚠ dưới ngân sách | ⚠ vượt tiến độ | | ⚠ Cách nhớ chung | ⚠ mọi chỉ số hiệu suất: DƯỚI 1 là xấu, TRÊN 1 là tốt | | ⚠ Cách nhớ chỉ số sai lệch | ⚠ CV và SV: ÂM là xấu, DƯƠNG là tốt |

Từ khoá nhận diện:

"CPI 0,89" → ⚠ 89 xu giá trị trên mỗi đô la chi ra "sẽ kết thúc dưới ngân sách" → ⚠ cần CPI trên 1 "đang chạy tốt" → ⚠ cần CPI ít nhất bằng 1 "BAC ÷ CPI" → ⚠ dự báo tổng chi phí cuối cùng — liên hệ #26027 lô 185

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 750.000 ÷ 0,89 ≈ 842.700 | ⚠ kiểm lại phép chia | | CPI của bạn hiện là bao nhiêu | | | Bạn có báo cáo bằng tỷ số hay bằng tiền | |

Và cách diễn giải CPI dễ hiểu nhất với người không quen EVM: cứ mỗi đô la dự án tiêu ra, chỉ có 89 xu biến thành công việc thật — 11 xu còn lại đã tan biến ở đâu đó, và việc của bạn là tìm ra ở đâu.

Đáp án

C — THỰC HIỆN HÀNH ĐỘNG KHẮC PHỤC để Scotty không tiếp nhận thêm thay đổi nào mà không qua hệ thống kiểm soát thay đổi.

Vì sao đúng

⚠ Vì sao đây là hành động đúng: | Lý do | Nội dung | |---|---| | ⚠ Hiệu suất đang LỆCH khỏi quy trình đã định | ⚠ đúng định nghĩa hành động khắc phục | | ⚠ Nhắm vào việc ĐƯA CÔNG VIỆC TRỞ LẠI đúng kế hoạch | ⚠ không nhắm vào trừng phạt | | ⚠ Vấn đề là HÀNH VI ĐANG DIỄN RA, cần chặn ngay | | | ⚠ Áp dụng được cho cả các trường hợp tương tự khác | | | ⚠ Định nghĩa | ⚠ hành động khắc phục là hoạt động có chủ đích nhằm đưa hiệu suất công việc trở lại phù hợp với kế hoạch |

Vì sao các phương án khác sai

• A (họp với đội và bên liên quan chính ở Phoenix để bàn kỹ về quy trình quản lý thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì đó là một phần hợp lý của việc khắc phục: ⚠ nhưng nó là ⚠ MỘT BIỆN PHÁP CỤ THỂ, không phải TÊN GỌI của hành động cần thực hiện; ⚠ câu hỏi hỏi bạn PHẢI LÀM GÌ ở mức quy trình — và câu trả lời bao trùm là hành động khắc phục.

• B (họp với Scotty và cấp trên của anh ta để bàn hình thức kỷ luật) — ⚠ nhảy tới trừng phạt trước khi tìm nguyên nhân; ⚠ có thể Scotty không hiểu quy trình, hoặc bị bên liên quan gây sức ép (liên hệ #25939 lô 184).

• D (rà các thay đổi đã lọt vào rồi bắt Scotty đảo ngược những gì bạn không duyệt) — ⚠ xử lý HẬU QUẢ mà không chặn NGUYÊN NHÂN; ⚠ và việc rà soát các thay đổi đã lọt vào là việc phải làm, nhưng chưa đủ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25933 ở lô 184 (sửa lỗi — sản phẩm làm sai) và câu #25939 (hành động khắc phục — thành viên liên tục lệch chuẩn chất lượng) — ⚠ câu này là câu THỨ HAI về hành động khắc phục, khoá NHẤT QUÁN. ⚠ Xem thêm câu #26012 lô 185 (việc ngoài phạm vi → dừng và nộp yêu cầu thay đổi) và câu #26052 ở lô này (kiểm soát thay đổi tích hợp).

⚠ BA loại hành động — nhắc lại: | Loại | Nhắm vào | Ví dụ | |---|---|---| | ⚠ SỬA LỖI | ⚠ SẢN PHẨM đã làm sai | ⚠ làm lại phần sai | | ⚠ HÀNH ĐỘNG KHẮC PHỤC | ⚠ HIỆU SUẤT đang lệch | ⚠ chặn việc nhận thay đổi ngoài quy trình — CÂU NÀY | | ⚠ HÀNH ĐỘNG PHÒNG NGỪA | ⚠ RỦI RO chưa xảy ra | ⚠ đào tạo trước cho các nhóm khác để không lặp lại | | ⚠ Ở tình huống này | ⚠ thực tế cần CẢ BA: khắc phục hành vi, sửa các thay đổi đã lọt, và phòng ngừa cho các địa điểm khác |

Từ khoá nhận diện:

"hành vi đang lệch khỏi quy trình" → ⚠ hành động khắc phục "sản phẩm đã làm sai" → ⚠ sửa lỗi "ngăn chuyện chưa xảy ra" → ⚠ hành động phòng ngừa "kỷ luật ngay" → ⚠ bỏ qua bước tìm nguyên nhân

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi thành viên ở mọi địa điểm có biết quy trình thay đổi không | | | Form yêu cầu thay đổi của bạn mất bao lâu để điền | ⚠ quá lâu thì người ta sẽ tránh | | Có thay đổi nào đã lọt vào mà chưa được ghi nhận không | ⚠ liên hệ #25956 lô 184 — nhật ký thay đổi |

Và điều đáng suy nghĩ nhất trong tình huống này: Scotty không phá hoại dự án — anh ta đang cố làm hài lòng bên liên quan bằng cách duy nhất anh ta biết. Hành động khắc phục đúng phải trao cho anh ta một cách khác.

Đáp án

D — MỨC TRANH ĐUA (Contest), nơi đội tập trung vào việc MÌNH ĐÚNG hơn người khác.

Vì sao đúng

⚠ Dấu hiệu trong đề khớp với mức tranh đua: | Dấu hiệu | Ý nghĩa | |---|---| | ⚠ Đội tập trung vào việc THẮNG cuộc tranh luận | ⚠ đặc trưng số một của mức 3 | | ⚠ Đã HÌNH THÀNH PHE — người theo bên này, người theo bên kia | | | ⚠ ĐỔ LỖI cho phe đối diện | ⚠ chuyển từ nói về VẤN ĐỀ sang nói về NGƯỜI | | ⚠ Mục tiêu đã đổi: từ giải quyết vấn đề sang giành phần thắng | | | ⚠ Định nghĩa | ⚠ mức 3 — thắng-thua, mọi người muốn mình đúng hơn là muốn tìm giải pháp |

Vì sao các phương án khác sai

• C (mức Thập tự chinh — Crusade, đội tập trung bảo vệ NHÓM của mình) — ⚠ phương án gây nhiễu mạnh nhất vì cũng nói về việc chia phe: ⚠ nhưng mức 4 nghiêm trọng HƠN — ⚠ người ta không còn muốn thắng nữa mà muốn LOẠI BỎ phe kia, ⚠ và xung đột trở thành vấn đề nguyên tắc chứ không còn về công việc; ⚠ ở đây họ vẫn đang tranh cãi để giành phần đúng, chưa tới mức đó.

• A (mức Bất đồng, nơi mọi người tập trung TỰ BẢO VỆ) — ⚠ mức 2, ⚠ nhẹ hơn: ⚠ bắt đầu phòng thủ nhưng chưa chia phe rõ ràng.

• B (mức Norming) — ⚠ NHẦM MÔ HÌNH: ⚠ norming là một giai đoạn trong ⚠ thang phát triển đội của TUCKMAN, ⚠ không phải mức xung đột; ⚠ và norming là giai đoạn đội đã ỔN ĐỊNH, ngược hẳn tình huống này.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25937 ở lô 184 ⚠ (xung đột giai đoạn SỚM → trao quyền cho đội tự giải quyết) — ⚠ câu đó đã liệt kê đủ NĂM MỨC, và câu này hỏi trực tiếp về mức 3. ⚠ Xem thêm bộ năm câu xung đột ở lô 184–185 (#25945, #25963, #25982, #26001) và câu #25916 lô 183 (bảng đối chiếu chiến lược xung đột).

⚠ NĂM MỨC XUNG ĐỘT — thang Speed Leas: | Mức | Tên | Dấu hiệu | Can thiệp | |---|---|---|---| | ⚠ 1 | ⚠ VẤN ĐỀ CẦN GIẢI QUYẾT | ⚠ bất đồng dựa trên dữ kiện, vẫn tôn trọng nhau | ⚠ để đội tự xử — liên hệ #25937 | | ⚠ 2 | ⚠ BẤT ĐỒNG | ⚠ bắt đầu tự bảo vệ, giữ thông tin cho riêng mình | ⚠ người dẫn dắt điều phối | | ⚠ 3 | ⚠ TRANH ĐUA (Contest) | ⚠ chia phe, muốn THẮNG, đổ lỗi — CÂU NÀY | ⚠ làm trung gian, có thể cần ngoại giao con thoi | | ⚠ 4 | ⚠ THẬP TỰ CHINH (Crusade) | ⚠ bảo vệ NHÓM mình, muốn LOẠI BỎ phe kia | ⚠ can thiệp mạnh, có thể phải tách người | | ⚠ 5 | ⚠ CHIẾN TRANH THẾ GIỚI | ⚠ "một mất một còn", huỷ hoại lẫn nhau | ⚠ can thiệp của tổ chức | | ⚠ Nguyên tắc | ⚠ mức can thiệp phải TƯƠNG XỨNG — quá nhẹ thì để leo thang, quá nặng thì làm nó lớn hơn thực tế |

⚠ Đừng nhầm với THANG TUCKMAN — mô hình phát triển đội: | Giai đoạn | Nội dung | |---|---| | ⚠ FORMING — Hình thành | ⚠ mới gặp, còn dè dặt, lịch sự | | ⚠ STORMING — Bão tố | ⚠ xung đột xuất hiện, va chạm cá tính | | ⚠ NORMING — Chuẩn hoá | ⚠ hình thành quy tắc, bắt đầu hợp tác tốt | | ⚠ PERFORMING — Vận hành hiệu quả | ⚠ đội tự tổ chức, năng suất cao | | ⚠ ADJOURNING — Giải tán | | | ⚠ Bẫy của phương án B | ⚠ trộn hai mô hình khác nhau vào cùng một bộ phương án — cách gây nhiễu điển hình |

Từ khoá nhận diện:

"chia phe, muốn thắng, đổ lỗi" → ⚠ mức 3 — Tranh đua "muốn loại bỏ phe kia" → ⚠ mức 4 — Thập tự chinh "tự bảo vệ, giữ thông tin" → ⚠ mức 2 — Bất đồng "forming, storming, norming" → ⚠ Tuckman, KHÔNG phải thang xung đột

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn, tranh luận gần nhất nói về việc hay về người | ⚠ ranh giới giữa mức 1 và mức 2 | | Có "phe" nào đang hình thành không | | | Có ai đã ngừng nói chuyện với ai không | ⚠ dấu hiệu đã lên mức 4 |

Và điều nguy hiểm nhất của mức 3: đội vẫn làm việc, vẫn họp, vẫn có vẻ chuyên nghiệp — nhưng mọi cuộc thảo luận kỹ thuật từ đó trở đi đều có một tầng nghĩa thứ hai mà không ai nói ra.

Đáp án

C — Anh đã dùng DỰ PHÒNG BẤT TRẮC (contingency reserve) trong khi lẽ ra phải dùng DỰ PHÒNG QUẢN LÝ (management reserve).

Vì sao đúng

⚠ Điểm mấu chốt: rủi ro này thuộc loại nào: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Đề nói rõ đây là rủi ro KHÔNG LƯỜNG TRƯỚC (unanticipated) | ⚠ tức là RỦI RO CHƯA BIẾT | | ⚠ Rủi ro CHƯA BIẾT phải dùng DỰ PHÒNG QUẢN LÝ | | | ⚠ Dự phòng BẤT TRẮC chỉ dành cho rủi ro ĐÃ NHẬN DIỆN | ⚠ đã nằm trong sổ đăng ký rủi ro | | ⚠ Joachim dùng nhầm quỹ | | | ⚠ Hệ quả | ⚠ quỹ dự phòng bất trắc bị tiêu cho việc không thuộc phạm vi của nó, làm mất khả năng ứng phó với rủi ro đã biết |

Vì sao các phương án khác sai

• B (không nên đưa đường cơ sở lịch trình vào yêu cầu thay đổi) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như một lỗi quy trình: ⚠ nhưng ⚠ Joachim làm ĐÚNG ở điểm này ⚠ — đường cơ sở lịch trình bị ảnh hưởng thì PHẢI qua yêu cầu thay đổi để điều chỉnh.

• A (không lường trước được mọi rủi ro khi lập kế hoạch) — ⚠ KHÔNG AI lường trước được mọi rủi ro; ⚠ đó chính là lý do dự phòng quản lý tồn tại.

• D (không nên nộp yêu cầu thay đổi vì rủi ro là chưa biết) — ⚠ sai: ⚠ mọi thay đổi đường cơ sở đều phải qua yêu cầu thay đổi, bất kể nguồn gốc.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26003 ở lô 185 (điểm rủi ro = xác suất × tác động), câu #26037 ở lô này (rủi ro thuần), câu #26040 (chuyển giao rủi ro), và câu #26045 (Monte Carlo). ⚠ Nhóm rủi ro đã lên bảy câu — và đây là câu duy nhất về hai loại DỰ PHÒNG.

⚠ BẢNG PHÂN BIỆT hai loại dự phòng — nội dung cốt lõi của câu này: | | DỰ PHÒNG BẤT TRẮC | DỰ PHÒNG QUẢN LÝ | |---|---|---| | ⚠ Dành cho | ⚠ rủi ro ĐÃ NHẬN DIỆN (known unknowns) | ⚠ rủi ro CHƯA BIẾT (unknown unknowns) — CÂU NÀY | | ⚠ Nằm trong | ⚠ ĐƯỜNG CƠ SỞ CHI PHÍ | ⚠ NGÂN SÁCH DỰ ÁN, NGOÀI đường cơ sở | | ⚠ Ai được dùng | ⚠ QUẢN LÝ DỰ ÁN tự quyết | ⚠ phải xin phép LÃNH ĐẠO hoặc nhà tài trợ | | ⚠ Dùng có cần yêu cầu thay đổi không | ⚠ KHÔNG — đã nằm trong đường cơ sở | ⚠ CÓ — vì làm thay đổi đường cơ sở chi phí | | ⚠ Tính thế nào | ⚠ từ phân tích rủi ro: EMV, Monte Carlo | ⚠ thường là tỷ lệ phần trăm theo chính sách tổ chức | | ⚠ Công thức quan trọng | ⚠ ĐƯỜNG CƠ SỞ CHI PHÍ = ước lượng công việc + dự phòng BẤT TRẮC | | ⚠ Và | ⚠ NGÂN SÁCH DỰ ÁN = đường cơ sở chi phí + dự phòng QUẢN LÝ |

Từ khoá nhận diện:

"rủi ro KHÔNG lường trước, chưa biết" → ⚠ dự phòng QUẢN LÝ "rủi ro đã nhận diện, có trong sổ rủi ro" → ⚠ dự phòng BẤT TRẮC "trong đường cơ sở chi phí" → ⚠ bất trắc "ngoài đường cơ sở, cần xin phép lãnh đạo" → ⚠ quản lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án bạn có tách hai loại dự phòng không | ⚠ nhiều dự án chỉ có một khoản "dự phòng" chung — và đó là vấn đề | | Ai được quyền dùng từng loại | | | Dự phòng bất trắc của bạn được tính từ đâu | ⚠ từ phân tích rủi ro hay từ một con số tròn |

Và lý do sự phân biệt này quan trọng hơn vẻ ngoài kỹ thuật của nó: quỹ bất trắc là tiền bạn đã tính trước cho những gì mình biết; quỹ quản lý là tiền cho những gì mình chưa biết. Tiêu nhầm là bạn đã tiêu hết phần dành cho tương lai để trả cho hiện tại.

Đáp án

D — NÊU VẤN ĐỀ TRONG BUỔI DAILY SCRUM.

Vì sao đúng

⚠ Vì sao daily scrum là nơi đúng: | Lý do | Nội dung | |---|---| | ⚠ Đây là một VẬT CẢN đối với công việc của Sharon | ⚠ đúng nội dung câu hỏi thứ ba của daily scrum | | ⚠ Cần cả đội biết vì nó ảnh hưởng tới ước lượng và kế hoạch sprint | | | ⚠ Đội TỰ TỔ CHỨC — quyết định thuộc về cả đội, không của riêng Sharon | ⚠ đề mô tả rõ đây là đội tự định hướng | | ⚠ Nêu SỚM, ngay ngày hôm sau, không đợi tới cuối sprint | | | ⚠ Lưu ý quan trọng | ⚠ daily scrum để NÊU vật cản, không phải để GIẢI QUYẾT — việc bàn giải pháp diễn ra sau buổi họp (liên hệ #25921 lô 183) |

Vì sao các phương án khác sai

• B (cập nhật sprint backlog) — ⚠ phương án gây nhiễu mạnh nhất vì cuối cùng sprint backlog CÓ THỂ phải cập nhật: ⚠ nhưng ⚠ đó là KẾT QUẢ của một quyết định tập thể, không phải hành động ĐẦU TIÊN; ⚠ Sharon tự sửa backlog mà chưa bàn với ai là bỏ qua đội.

• A (cập nhật mục tiêu sprint) — ⚠ mục tiêu sprint hiếm khi thay đổi giữa sprint, ⚠ và một vấn đề chất lượng mã không đủ để đổi mục tiêu.

• C (huỷ sprint) — ⚠ phản ứng CỰC ĐOAN; ⚠ chỉ product owner mới có quyền huỷ sprint, ⚠ và chỉ khi mục tiêu sprint trở nên vô nghĩa (liên hệ #25936 lô 184).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25921 ở lô 183 (ba câu hỏi của daily scrum), câu #26014 lô 185 (đội tự kéo việc từ backlog), câu #26016 (Eva muốn dẫn dắt trong đội tự định hướng), và câu #26030 (Rose tin tưởng đội tự tổ chức). ⚠ Nhóm đội tự tổ chức đã lên sáu câu.

⚠ Vấn đề Sharon gặp: NỢ KỸ THUẬT: | Khái niệm | Nội dung | |---|---| | ⚠ Mã cũ không đạt chuẩn của tổ chức | ⚠ đó là NỢ KỸ THUẬT đã tồn tại từ trước | | ⚠ Sửa nó tốn thêm thời gian ngoài ước lượng ban đầu | | | ⚠ Không sửa thì nợ tích thêm và lan sang mã mới | | | ⚠ Quyết định cần cả đội | ⚠ sửa ngay, sửa một phần, hay ghi nhận để xử lý sau | | ⚠ Ai quyết cuối cùng về ưu tiên | ⚠ nếu tốn nhiều thời gian tới mức ảnh hưởng cam kết sprint thì phải có PRODUCT OWNER tham gia |

Từ khoá nhận diện:

"phát hiện vật cản khi đang làm" → ⚠ nêu ở daily scrum "tự cập nhật backlog" → ⚠ bỏ qua đội, sai với đội tự tổ chức "huỷ sprint" → ⚠ cực đoan, và chỉ PO có quyền "đổi mục tiêu sprint" → ⚠ rất hiếm khi đúng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ghi nhận nợ kỹ thuật ở đâu không | ⚠ hay chỉ than phiền rồi bỏ qua | | Có bao nhiêu phần trăm sức chứa sprint dành cho trả nợ kỹ thuật | | | Khi gặp vật cản, người trong đội nêu ngay hay tự xoay | |

Và điều Sharon làm đúng khi chọn nêu ra thay vì tự xử lý: thời gian cô bỏ ra để sửa mã cũ là thời gian lấy từ cam kết chung của đội — nên quyết định đó cũng phải là của cả đội.

Đáp án

A — 10 KÊNH.

Vì sao đúng

⚠ Phép tính: | Bước | Nội dung | |---|---| | ⚠ Đếm số người | ⚠ Bryant (1) + 3 lập trình viên + 1 chuyên viên QA = 5 người | | ⚠ Công thức | ⚠ n × (n − 1) ÷ 2 | | ⚠ Thay số | ⚠ 5 × 4 ÷ 2 = 10 kênh | | ⚠ Điểm mấu chốt | ⚠ PHẢI TÍNH CẢ BRYANT — anh là một người tham gia giao tiếp, không đứng ngoài | | ⚠ Nếu quên Bryant | ⚠ 4 người → 4 × 3 ÷ 2 = 6, chính là phương án nhiễu C |

Vì sao các phương án khác sai

• C (6) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ đó là kết quả khi ⚠ QUÊN TÍNH BRYANT ⚠ — chỉ đếm 4 người trong đội; ⚠ đây là lỗi phổ biến nhất với dạng bài này.

• B (4) — ⚠ số người trong đội trừ Bryant, ⚠ không phải số kênh.

• D (5) — ⚠ tổng số người, ⚠ không phải số kênh.

Ghi nhớ

⚠ Đối chiếu — BA câu về công thức kênh giao tiếp, và cách đếm KHÔNG NHẤT QUÁN: | Câu | Đề bài | Cách đếm để ra khoá | |---|---|---| | ⚠ #25620 (lô 177) | ⚠ "18 bên liên quan" | ⚠ TÍNH THÊM quản lý dự án → 19 người → 171 kênh | | ⚠ #26057 (lô này) | ⚠ "19 bên liên quan" + 3 thành viên | ⚠ KHÔNG tính Vera → 22 người → tăng 60 kênh | | ⚠ #26070 (câu này) | ⚠ Bryant + 3 dev + 1 QA | ⚠ TÍNH CẢ Bryant → 5 người → 10 kênh | ⚠ Hai trong ba câu tính cả quản lý dự án, một câu thì không. ⚠ Cả ba khoá được giữ nguyên — trong mỗi câu chỉ có MỘT cách đếm cho ra con số nằm trong bộ phương án. ⚠ Ở câu này thì đề liệt kê Bryant ngay trong danh sách người tham gia, nên việc tính cả anh là hiển nhiên. ⚠ Mẹo chung: tính cả hai cách rồi chọn con số CÓ trong bộ phương án.

⚠ Bảng tra nhanh số kênh: | Số người | Số kênh | |---|---| | ⚠ 2 | ⚠ 1 | | ⚠ 3 | ⚠ 3 | | ⚠ 4 | ⚠ 6 | | ⚠ 5 | ⚠ 10 | | ⚠ 6 | ⚠ 15 | | ⚠ 10 | ⚠ 45 | | ⚠ Quy luật | ⚠ thêm một người vào nhóm n người thì thêm đúng n kênh mới |

Từ khoá nhận diện:

"n(n−1)/2" → ⚠ công thức duy nhất cần thuộc "quản lý dự án chịu trách nhiệm bao nhiêu kênh" → ⚠ TÍNH CẢ anh ta "số người" xuất hiện trong bộ phương án → ⚠ luôn là phương án bẫy "tăng thêm bao nhiêu kênh" → ⚠ tính hiệu số — liên hệ #26057

Ba việc kiểm chứng: | Việc | Cách | |---|---| | 5 × 4 ÷ 2 = 10 | ⚠ kiểm lại | | Bạn đã tính cả chính mình chưa | ⚠ lỗi phổ biến nhất của dạng bài này | | Đội của bạn có bao nhiêu kênh | ⚠ và bạn có kế hoạch giao tiếp cho từng kênh quan trọng không |

Và điều công thức này nhắc lại mỗi lần bạn định thêm một người vào cuộc họp: người thứ sáu trong một nhóm năm người không mang theo một mối quan hệ — anh ta mang theo năm mối quan hệ mới.

Đáp án

B — TÍNH NĂNG THỪA vượt quá mức cơ bản cần thiết, SỰ TRÌ HOÃN, và CÔNG VIỆC LÀM DỞ.

Vì sao đúng

⚠ Ba thứ cần giảm thiểu và tên gọi lãng phí tương ứng: | Thứ cần giảm | Loại lãng phí | |---|---| | ⚠ TÍNH NĂNG THỪA vượt mức cần thiết | ⚠ lãng phí TÍNH NĂNG THỪA — chính là mạ vàng | | ⚠ TRÌ HOÃN, chờ đợi | ⚠ lãng phí CHỜ ĐỢI | | ⚠ CÔNG VIỆC LÀM DỞ | ⚠ lãng phí TỒN KHO — vốn bị đóng băng | | ⚠ Cả ba đều nằm trong | ⚠ BẢY LOẠI LÃNG PHÍ của lean phát triển phần mềm | | ⚠ Mục tiêu của lean | ⚠ tối đa hoá GIÁ TRỊ bằng cách tối thiểu hoá LÃNG PHÍ — không phải cắt giảm chi phí một cách máy móc |

Vì sao các phương án khác sai

• D (lãng phí như việc ra quyết định MUỘN) — ⚠ phương án gây nhiễu mạnh nhất vì có đúng chữ "lãng phí": ⚠ nhưng lean có nguyên tắc ⚠ "TRÌ HOÃN CAM KẾT" — quyết định ở THỜI ĐIỂM MUỘN NHẤT CÓ TRÁCH NHIỆM ⚠ (liên hệ #25919 lô 183); ⚠ ra quyết định muộn KHÔNG tự động là lãng phí — quyết định SỚM KHI CHƯA ĐỦ THÔNG TIN mới là lãng phí.

• A (giá trị mang lại cho khách hàng) — ⚠ lean TỐI ĐA HOÁ giá trị, không giảm thiểu nó; ⚠ phương án này đảo ngược mục tiêu.

• C (việc tái cấu trúc sản phẩm) — ⚠ tái cấu trúc là hoạt động TẠO GIÁ TRỊ, ⚠ giữ cho mã không bị mục nát; ⚠ liên hệ #26042 cùng lô — nó là một bước bắt buộc của TDD.

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG trong CÙNG MỘT LÔ: ⚠ câu #26059 ⚠ (loại bỏ lãng phí: giảm phê duyệt, kiểm thử ngay, đội ngồi chung) ⚠ và câu này ⚠ (giảm tính năng thừa, trì hoãn, việc làm dở). ⚠ Hai câu cùng chủ đề lean, khoá HOÀN TOÀN NHẤT QUÁN — chỉ khác góc nhìn: #26059 nói THỰC HÀNH nào loại bỏ lãng phí, câu này nói LOẠI LÃNG PHÍ nào cần giảm. ⚠ Xem thêm câu #25975 lô 184 (mạ vàng) và câu #25940 (giới hạn WIP).

⚠ BẢY LOẠI LÃNG PHÍ trong lean phần mềm — bảng đầy đủ: | Lãng phí | Ví dụ | Xuất hiện ở câu nào | |---|---|---| | ⚠ CÔNG VIỆC LÀM DỞ | ⚠ yêu cầu chờ sẵn, mã chưa tích hợp | ⚠ #26071 (câu này), #26059 | | ⚠ TÍNH NĂNG THỪA | ⚠ mạ vàng | ⚠ #26071, #25975 lô 184 | | ⚠ HỌC LẠI | ⚠ tri thức mất rồi phải tìm lại | ⚠ #26035 cùng lô — quản lý tri thức | | ⚠ BÀN GIAO | ⚠ chuyển việc giữa người, mất thông tin | ⚠ #26059 — đội ngồi chung | | ⚠ CHUYỂN ĐỔI NHIỆM VỤ | ⚠ một người nhiều dự án cùng lúc | | | ⚠ CHỜ ĐỢI (trì hoãn) | ⚠ chờ phê duyệt, chờ môi trường | ⚠ #26071, #26059 | | ⚠ KHUYẾT TẬT | ⚠ lỗi phải sửa | ⚠ #26053 — CI bắt lỗi sớm | | ⚠ Nguyên tắc bao trùm | ⚠ tối ưu hoá TOÀN BỘ DÒNG CHẢY, không tối ưu từng khâu |

⚠ Bảy nguyên tắc của Lean Software Development: | Nguyên tắc | Nội dung | |---|---| | ⚠ Loại bỏ lãng phí | ⚠ CÂU NÀY | | ⚠ Khuếch đại việc học | ⚠ liên hệ #25994 lô 185 — vòng lặp ngắn để học | | ⚠ TRÌ HOÃN CAM KẾT | ⚠ quyết ở thời điểm muộn nhất có trách nhiệm — bẫy của phương án D | | ⚠ Giao hàng nhanh | ⚠ liên hệ #25984 lô 185 | | ⚠ Trao quyền cho đội | ⚠ liên hệ #26030 lô 185 | | ⚠ Xây chất lượng vào bên trong | ⚠ liên hệ #26042 — TDD | | ⚠ Nhìn toàn cục | |

Từ khoá nhận diện:

"tính năng thừa, trì hoãn, việc làm dở" → ⚠ ba loại lãng phí cần giảm "ra quyết định muộn" → ⚠ BẪY — lean khuyến khích trì hoãn cam kết "giảm giá trị cho khách hàng" → ⚠ đảo ngược mục tiêu của lean "tái cấu trúc" → ⚠ hoạt động tạo giá trị, không phải lãng phí

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có bao nhiêu công việc đang nằm dở trong quy trình của bạn | | | Tính năng gần nhất bạn làm có ai yêu cầu không | | | Quyết định nào bạn đang hoãn — vì thiếu thông tin hay vì né tránh | ⚠ hai lý do rất khác nhau |

Và cách hiểu gọn nhất về lean: nó không đòi bạn làm nhanh hơn — nó đòi bạn ngừng làm những thứ không ai cần, và ngừng để công việc nằm chờ.

Đáp án

D — SỔ ĐĂNG KÝ RỦI RO (đây KHÔNG phải phần của kế hoạch quản lý rủi ro).

Vì sao đúng

⚠ Phân biệt hai tài liệu: | Tài liệu | Nội dung | |---|---| | ⚠ KẾ HOẠCH QUẢN LÝ RỦI RO | ⚠ mô tả CÁCH sẽ quản lý rủi ro — phương pháp, vai trò, ngân sách, thời điểm, phân loại, thang xác suất và tác động, ngưỡng chịu đựng | | ⚠ SỔ ĐĂNG KÝ RỦI RO | ⚠ DANH SÁCH các rủi ro CỤ THỂ đã nhận diện, kèm đánh giá và ứng phó | | ⚠ Quan hệ | ⚠ kế hoạch là KHUNG, sổ đăng ký là NỘI DUNG được điền vào khung đó | | ⚠ Thời điểm ra đời | ⚠ kế hoạch có TRƯỚC, sổ đăng ký được tạo và cập nhật SAU, suốt vòng đời dự án | | ⚠ Vì sao không thể là một | ⚠ kế hoạch gần như không đổi; sổ đăng ký thay đổi liên tục |

Vì sao các phương án khác sai

• C (chiến lược rủi ro) — ⚠ phương án gây nhiễu mạnh nhất vì "chiến lược" nghe như việc ứng phó với từng rủi ro cụ thể: ⚠ nhưng ở đây nó là ⚠ CÁCH TIẾP CẬN CHUNG của dự án với rủi ro ⚠ — mức chịu đựng rủi ro của tổ chức, thái độ chung; ⚠ đó là nội dung của KẾ HOẠCH.

• A (phân loại rủi ro) — ⚠ cấu trúc phân rã rủi ro (RBS), ⚠ nằm trong kế hoạch để chuẩn hoá việc nhận diện.

• B (phương pháp luận) — ⚠ cách tiếp cận, công cụ và nguồn dữ liệu sẽ dùng; ⚠ nội dung cốt lõi của kế hoạch.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25923 ở lô 183 (kỹ thuật nhận diện rủi ro — phân tích định tính KHÔNG thuộc nhóm này), câu #26003 lô 185 (điểm rủi ro), câu #26037 ở lô này (rủi ro thuần), câu #26068 (hai loại dự phòng), và câu #26045 (Monte Carlo). ⚠ Nhóm rủi ro đã lên TÁM câu qua bốn lô — chủ đề dày thứ hai sau giao tiếp.

⚠ KẾ HOẠCH QUẢN LÝ RỦI RO gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ PHƯƠNG PHÁP LUẬN | ⚠ cách tiếp cận, công cụ, nguồn dữ liệu | | ⚠ VAI TRÒ và TRÁCH NHIỆM | ⚠ ai làm gì trong việc quản lý rủi ro | | ⚠ NGÂN SÁCH và THỜI ĐIỂM | ⚠ bao nhiêu tiền, làm khi nào, bao lâu một lần | | ⚠ PHÂN LOẠI RỦI RO (RBS) | | | ⚠ ĐỊNH NGHĨA xác suất và tác động | ⚠ "tác động cao" nghĩa là bao nhiêu tiền | | ⚠ MA TRẬN xác suất – tác động | | | ⚠ NGƯỠNG CHỊU ĐỰNG rủi ro của bên liên quan | ⚠ liên hệ #25983 lô 185 — ngưỡng | | ⚠ Định dạng BÁO CÁO và cách THEO DÕI | | | ⚠ KHÔNG gồm | ⚠ danh sách rủi ro cụ thể — đó là sổ đăng ký |

⚠ SỔ ĐĂNG KÝ RỦI RO gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ Mô tả từng rủi ro cụ thể | | | ⚠ Xác suất và tác động đã đánh giá | ⚠ liên hệ #26003 lô 185 | | ⚠ Điểm rủi ro và thứ hạng ưu tiên | | | ⚠ CHIẾN LƯỢC ỨNG PHÓ cho từng rủi ro | ⚠ né tránh, chuyển giao, giảm nhẹ, chấp nhận, leo thang | | ⚠ CHỦ SỞ HỮU rủi ro | | | ⚠ Rủi ro TỒN DƯ và rủi ro THỨ CẤP | | | ⚠ Điểm kích hoạt và kế hoạch dự phòng | | | ⚠ Đặc điểm | ⚠ là tài liệu SỐNG, cập nhật suốt dự án |

Từ khoá nhận diện:

"CÁCH quản lý rủi ro, phương pháp, vai trò, ngưỡng" → ⚠ kế hoạch quản lý rủi ro "DANH SÁCH rủi ro cụ thể, chủ sở hữu, ứng phó" → ⚠ sổ đăng ký rủi ro ⚠ Mẫu chung: "KẾ HOẠCH quản lý X" mô tả CÁCH LÀM; "SỔ ĐĂNG KÝ / NHẬT KÝ" chứa NỘI DUNG cụ thể ⚠ Áp dụng được cho mọi lĩnh vực → ⚠ kế hoạch giao tiếp và ma trận giao tiếp, kế hoạch bên liên quan và sổ đăng ký bên liên quan

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có tách kế hoạch và sổ đăng ký rủi ro không | | | Kế hoạch của bạn có định nghĩa "tác động cao" bằng con số không | ⚠ không có thì mỗi người đánh giá một kiểu | | Sổ đăng ký rủi ro cập nhật lần cuối khi nào | |

Và quy tắc chung áp dụng cho mọi câu hỏi dạng này: hễ thấy chữ "KẾ HOẠCH quản lý", hãy hỏi "tài liệu này mô tả CÁCH LÀM hay chứa DỮ LIỆU CỤ THỂ?" — dữ liệu cụ thể luôn nằm ở một tài liệu khác.