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

Đáp án

D — PHÂN TÍCH CÂY QUYẾT ĐỊNH (decision tree analysis).

Vì sao đúng

⚠ Vì sao cây quyết định phù hợp với make-or-buy: | Lý do | Nội dung | |---|---| | ⚠ Có HAI NHÁNH lựa chọn rõ ràng: tự làm và mua | ⚠ đúng cấu trúc cây quyết định | | ⚠ Mỗi nhánh có CHI PHÍ và KẾT QUẢ có thể lượng hoá | | | ⚠ Tính được GIÁ TRỊ TIỀN TỆ KỲ VỌNG (EMV) cho từng nhánh | ⚠ so sánh khách quan bằng con số | | ⚠ Xử lý được cả yếu tố BẤT ĐỊNH | ⚠ "nếu nhà cung cấp giao trễ với xác suất 20% thì sao" | | ⚠ Kết luận | ⚠ chọn nhánh có EMV tốt hơn |

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

• A (phân tích ROI — tỷ suất hoàn vốn) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là công cụ tài chính: ⚠ nhưng ROI dùng để ⚠ quyết định CÓ NÊN ĐẦU TƯ vào một dự án hay không, ⚠ không dùng để so sánh HAI CÁCH THỰC HIỆN cùng một việc; ⚠ nó là công cụ CHỌN DỰ ÁN, không phải công cụ chọn phương án thực hiện.

• B (mô hình xương cá) và C (biểu đồ Ishikawa) — ⚠ HAI TÊN GỌI CỦA CÙNG MỘT CÔNG CỤ, ⚠ dùng để ⚠ TÌM NGUYÊN NHÂN GỐC của vấn đề, ⚠ hoàn toàn không liên quan tới quyết định mua sắm.

Ghi nhớ về chất lượng câu hỏi

⚠ Đề liệt kê "mô hình xương cá" (B) và "biểu đồ Ishikawa" (C) thành HAI phương án riêng, trong khi chúng là MỘT công cụ duy nhất. | Vấn đề | Nội dung | |---|---| | ⚠ Xương cá = Ishikawa = biểu đồ nhân quả | ⚠ cùng một thứ, ba tên gọi | | ⚠ Tách thành hai phương án làm giảm số lựa chọn thực tế xuống còn ba | | | ⚠ Xử lý | ⚠ GIỮ NGUYÊN khoá D — cả hai phương án đó đều sai như nhau, nên lỗi này không ảnh hưởng tới đáp án | | ⚠ Đối chiếu | ⚠ câu #25626 ở lô 177 mắc ĐÚNG lỗi này: liệt kê "Ishikawa" và "nhân quả" thành hai phương án riêng — đây là lần thứ HAI bộ đề lặp lại kiểu lỗi đó | | ⚠ Mẹo khi đi thi | ⚠ thấy hai phương án là đồng nghĩa thì loại CẢ HAI — đề không thể có hai đáp án đúng |

Ghi nhớ

⚠ Đối chiếu — nhóm mua sắm đã lên BẢY câu: ⚠ #25907 lô 183 (điểm hoà vốn make-or-buy = 17 tháng), ⚠ #25941, #25943, #25951, #25960, #25969 lô 184, ⚠ #25996 lô này (make-or-buy nằm trong lập kế hoạch mua sắm), ⚠ và câu này. ⚠ Ba câu về make-or-buy tạo thành bộ hoàn chỉnh: TÍNH thế nào (#25907), NẰM Ở ĐÂU trong quy trình (#25996), DÙNG CÔNG CỤ GÌ (câu này).

⚠ Cây quyết định hoạt động thế nào: | Thành phần | Nội dung | |---|---| | ⚠ NÚT QUYẾT ĐỊNH (hình vuông) | ⚠ nơi ta chọn — tự làm hay mua | | ⚠ NÚT CƠ HỘI (hình tròn) | ⚠ nơi may rủi quyết định — nhà cung cấp giao đúng hạn hay không | | ⚠ NHÁNH | ⚠ mỗi lựa chọn hoặc mỗi kết cục, kèm XÁC SUẤT | | ⚠ GIÁ TRỊ ở cuối mỗi nhánh | ⚠ chi phí hoặc lợi ích | | ⚠ EMV = tổng của (xác suất × giá trị) | ⚠ tính ngược từ phải sang trái | | ⚠ Chọn nhánh nào | ⚠ nhánh có EMV tốt nhất |

Từ khoá nhận diện:

"chọn giữa hai phương án có bất định" → ⚠ cây quyết định "có nên đầu tư vào dự án này không" → ⚠ ROI, NPV, thời gian hoàn vốn "tìm nguyên nhân gốc" → ⚠ xương cá / Ishikawa / nhân quả "mô phỏng nhiều kịch bản" → ⚠ Monte Carlo

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyết định make-or-buy của bạn có tính tới bất định không | ⚠ hay chỉ so hai con số chi phí | | Bạn có gán xác suất cho các kịch bản không | | | Có nhánh nào bạn chưa xét không | ⚠ ví dụ "mua rồi tự sửa" — nhiều bài toán có hơn hai lựa chọn |

Và điểm mạnh thật sự của cây quyết định: nó buộc bạn viết ra những giả định mà bình thường bạn chỉ giữ trong đầu — và phần lớn các quyết định sai đều bắt nguồn từ một giả định chưa bao giờ được nói ra.

Đáp án

A — Vì BÊN LIÊN QUAN đã xếp hạng ưu tiên cho hạng mục đó.

Vì sao đúng

⚠ Vì sao lấy từ ĐẦU backlog là đúng: | Lý do | Nội dung | |---|---| | ⚠ Backlog được XẾP THEO ƯU TIÊN từ trên xuống | ⚠ hạng mục đầu là hạng mục có giá trị cao nhất tiếp theo | | ⚠ Product owner xếp ưu tiên dựa trên giá trị của bên liên quan | ⚠ liên hệ #25912 và #25889 lô 183 | | ⚠ Đội xong sớm thì lấy việc CÓ GIÁ TRỊ NHẤT tiếp theo | ⚠ không phải lấy việc tuỳ tiện | | ⚠ Đây là hệ thống KÉO | ⚠ liên hệ #25940 lô 184 — Kanban và giới hạn WIP | | ⚠ Kết luận | ⚠ thứ tự trong backlog CHÍNH LÀ câu trả lời cho câu hỏi "làm gì tiếp theo" |

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

• B (đội quên gán hạng mục đó vào sprint) — ⚠ phương án gây nhiễu mạnh nhất vì giải thích được sự bối rối của Josh: ⚠ nhưng ⚠ hạng mục nằm trong PRODUCT backlog chứ không phải SPRINT backlog là chuyện BÌNH THƯỜNG; ⚠ đội không "quên" — họ chỉ cam kết đúng sức chứa và giờ còn dư năng lực.

• C (Shelley đã xin Scrum Master cho phép) — ⚠ SAI VAI: ⚠ Scrum Master ⚠ KHÔNG phê duyệt việc đội lấy việc gì; ⚠ đội tự tổ chức.

• D (đội cần trông có vẻ bận rộn) — ⚠ hoàn toàn đi ngược tinh thần agile; ⚠ mục tiêu là giao GIÁ TRỊ, không phải trông bận.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25993 ở lô này (PO không được áp velocity lên đội), câu #25987 (thêm tính năng vào backlog), câu #26002 (xếp hạng tuyệt đối), và câu #25957 ở lô 184 (khi nào phần tăng trưởng được coi là xong). ⚠ Nhóm quản trị backlog.

⚠ Hai loại backlog cần phân biệt: | Loại | Nội dung | |---|---| | ⚠ PRODUCT BACKLOG | ⚠ TOÀN BỘ công việc còn lại của sản phẩm, xếp theo ưu tiên, do PO sở hữu | | ⚠ SPRINT BACKLOG | ⚠ phần đội CAM KẾT làm trong sprint này, do ĐỘI sở hữu | | ⚠ Quan hệ | ⚠ sprint backlog được kéo từ ĐẦU product backlog | | ⚠ Khi đội xong sớm | ⚠ kéo thêm từ đầu product backlog — đúng việc Shelley bảo Josh làm | | ⚠ Điều kiện | ⚠ hạng mục kéo thêm phải ĐỦ NHỎ để xong trong sprint, và nên bàn với PO |

Từ khoá nhận diện:

"lấy hạng mục đầu backlog" → ⚠ vì nó có ưu tiên cao nhất "đội quên gán vào sprint" → ⚠ hiểu sai về hai loại backlog "Scrum Master cho phép" → ⚠ sai vai, đội tự tổ chức "trông có vẻ bận" → ⚠ đi ngược mục tiêu giao giá trị

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Backlog của bạn có được xếp theo thứ tự tuyệt đối không | ⚠ liên hệ #26002 | | Khi đội xong sớm, họ tự quyết hay chờ được giao việc | | | Nợ kỹ thuật của đội có bao giờ được trả không | |

Và điều Josh sẽ hiểu sau vài sprint nữa: danh sách công việc trong agile không phải để phân chia cho từng người, mà là một hàng đợi có thứ tự — ai rảnh thì lấy tiếp cái đầu tiên.

Đáp án

B — GẶP SCRUM MASTER của đội kia để THƯƠNG LƯỢNG một giải pháp.

Vì sao đúng

⚠ Vì sao đây là cách xử lý đúng: | Lý do | Nội dung | |---|---| | ⚠ Đây là vấn đề NGUỒN LỰC giữa hai đội | ⚠ liên hệ #25935 lô 184 — ràng buộc nguồn lực | | ⚠ Cần trao đổi giữa hai người ĐIỀU PHỐI, không phải giữa Kelly và đội kia | ⚠ Kelly không có vị thế để thương lượng thay đội mình | | ⚠ THƯƠNG LƯỢNG chứ không phải đồng ý hay từ chối ngay | ⚠ liên hệ #26009 cùng lô — tôn trọng và hợp tác | | ⚠ Bảo vệ cam kết sprint của đội mình mà không phá quan hệ | | | ⚠ Có thể tìm ra | ⚠ giải pháp trung gian: hỗ trợ 4 giờ, hoặc cử người khác, hoặc chỉ tư vấn qua một cuộc gọi |

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

• A (cho Kelly đi giúp đội kia) — ⚠ phương án gây nhiễu mạnh nhất vì tinh thần hợp tác là điều tốt: ⚠ nhưng nó ⚠ PHÁ VỠ cam kết sprint của đội ⚠ mà không ai được hỏi ý kiến; ⚠ sức chứa đã tính cho sprint này, rút người ra là ⚠ thay đổi phạm vi sprint mà không thương lượng ⚠ (liên hệ #25936 lô 184).

• C (từ chối yêu cầu) — ⚠ cực đoan ngược lại; ⚠ đội kia đang có vật cản NGHIÊM TRỌNG; ⚠ từ chối không thương lượng làm hỏng quan hệ giữa các đội.

• D (hỏi xem thành viên khác đi thay được không) — ⚠ có thể là MỘT phương án trong cuộc thương lượng, ⚠ nhưng ⚠ không thể quyết trước khi biết đội kia thật sự cần kỹ năng gì.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26008 ở lô này (bên liên quan không nhả nguồn lực → gặp trực tiếp) — ⚠ hai câu cùng một mẫu: vấn đề vượt ra ngoài đội thì người điều phối đi giải quyết, không đẩy cho thành viên. ⚠ Xem thêm câu #25935 lô 184 (hai PM tranh nhau một người) và câu #26009 (môi trường thương lượng).

⚠ Isobel nên mang gì vào cuộc thương lượng: | Nội dung | Chi tiết | |---|---| | ⚠ Cam kết sprint hiện tại của đội mình | ⚠ 96 điểm, đang ở vòng lặp thứ năm — dữ liệu ổn định | | ⚠ Ảnh hưởng nếu rút Kelly ra | ⚠ hạng mục nào sẽ không kịp | | ⚠ Câu hỏi: đội kia CỤ THỂ cần gì | ⚠ cần Kelly cả tuần hay chỉ cần hai giờ tư vấn? | | ⚠ Vài phương án thay thế | ⚠ cử người khác, hỗ trợ bán thời gian, hoãn tới sprint sau | | ⚠ Ai cần được thông báo | ⚠ PRODUCT OWNER — vì mọi thay đổi sức chứa đều ảnh hưởng tới giá trị giao được |

Từ khoá nhận diện:

"đội khác xin mượn người" → ⚠ hai Scrum Master thương lượng "đồng ý ngay" → ⚠ phá cam kết sprint "từ chối ngay" → ⚠ phá quan hệ giữa các đội "để thành viên tự quyết" → ⚠ đặt họ vào thế khó

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai bị nhiều nơi cùng cần không | ⚠ đó là nút thắt và là rủi ro — liên hệ #25928 lô 183 | | Yêu cầu từ bên ngoài đi qua bạn hay đi thẳng tới thành viên | | | Sprint gần nhất có bị gián đoạn vì việc ngoài kế hoạch không | |

Và điều Isobel bảo vệ khi nhận lấy cuộc thương lượng này về mình: không phải là thời gian của Kelly, mà là quyền của Kelly được tập trung vào việc mình đã cam kết mà không phải làm người xử lý xung đột giữa hai đội.

Đáp án

B — Eva phải GIẢI THÍCH và CHỨNG MINH cho đội thấy rằng cô có thể dẫn dắt việc này thành công, vì nó thuộc chuyên môn của cô.

Vì sao đúng

⚠ Vai trò lãnh đạo trong đội tự định hướng: | Nguyên tắc | Nội dung | |---|---| | ⚠ Lãnh đạo là VAI TRÒ LUÂN PHIÊN theo chuyên môn | ⚠ không phải chức vụ cố định | | ⚠ Quyền dẫn dắt đến từ NĂNG LỰC và SỰ TÍN NHIỆM CỦA ĐỘI | ⚠ không đến từ bổ nhiệm | | ⚠ Eva phải THUYẾT PHỤC ĐỒNG ĐỘI, không xin phép cấp trên | | | ⚠ Minh bạch về lý do vì sao cô phù hợp | | | ⚠ Khái niệm | ⚠ "lãnh đạo phân tán" hoặc "lãnh đạo nổi lên" — đặc trưng của đội tự tổ chức |

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

• C (Eva phải xin phép người lãnh đạo dự án) — ⚠ phương án gây nhiễu mạnh nhất vì đó là cách làm trong tổ chức phân cấp: ⚠ nhưng ⚠ đội TỰ ĐỊNH HƯỚNG thì không có "người lãnh đạo dự án" phê duyệt việc ai dẫn dắt việc gì; ⚠ xin phép là mang mô hình cũ áp vào.

• D (giải thích với BÊN LIÊN QUAN rằng cô đã làm việc này trước đây) — ⚠ SAI ĐỐI TƯỢNG: ⚠ đây là chuyện nội bộ đội, ⚠ bên liên quan không quyết ai dẫn dắt việc gì trong đội.

• A (giành quyền bằng cách lấn lướt người lãnh đạo một cách khéo léo) — ⚠ phi đạo đức và phá hoại lòng tin; ⚠ đi ngược mọi giá trị của agile.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25919 ở lô 183 (đội tự quyết kiến trúc), câu #25937 ở lô 184 (trao quyền cho đội tự giải quyết xung đột), câu #25970 (đội tự thực thi quy tắc chung), và câu #26014 ở lô này (đội tự kéo việc từ backlog). ⚠ Bốn câu cùng vẽ nên bức tranh đội TỰ TỔ CHỨC.

⚠ Đội tự tổ chức tự quyết những gì: | Quyết định | Thuộc về đội? | |---|---| | ⚠ Ai làm việc gì | ⚠ CÓ | | ⚠ Ai dẫn dắt việc gì | ⚠ CÓ — CÂU NÀY | | ⚠ Làm thế nào về mặt kỹ thuật | ⚠ CÓ | | ⚠ Nhận bao nhiêu việc trong sprint | ⚠ CÓ — liên hệ #25993 cùng lô | | ⚠ Định nghĩa Hoàn thành | ⚠ CÓ | | ⚠ Làm việc gì trước | ⚠ KHÔNG — đó là của product owner | | ⚠ Mục tiêu sản phẩm | ⚠ KHÔNG — của product owner | | ⚠ Ranh giới | ⚠ PO quyết CÁI GÌ và VÌ SAO, đội quyết AI, THẾ NÀO và BAO NHIÊU |

Từ khoá nhận diện:

"đội tự định hướng, muốn dẫn dắt một việc" → ⚠ thuyết phục đội bằng năng lực "xin phép lãnh đạo" → ⚠ mô hình phân cấp, không hợp với đội tự tổ chức "nói với bên liên quan" → ⚠ sai đối tượng "lấn lướt khéo léo" → ⚠ phi đạo đức, luôn sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Trong đội bạn, ai dẫn dắt một việc được quyết thế nào | | | Có phải lúc nào cũng cùng một người dẫn không | ⚠ nếu có, đội chưa thật sự tự tổ chức | | Người có chuyên môn nhưng ít nói có được dẫn dắt bao giờ chưa | |

Và điều làm nên sự khác biệt giữa quyền lực và quyền dẫn dắt trong một đội tự tổ chức: quyền lực được trao từ trên xuống, còn quyền dẫn dắt được cho mượn từ những người sẽ đi theo bạn — và họ có thể lấy lại bất cứ lúc nào.

Đáp án

B — WBS cho thấy MỐI QUAN HỆ giữa các công việc và làm cho việc LẬP KẾ HOẠCH DỄ HƠN.

Vì sao đúng

⚠ WBS làm được gì: | Công dụng | Nội dung | |---|---| | ⚠ Chia toàn bộ phạm vi thành các phần QUẢN LÝ ĐƯỢC | ⚠ gói công việc | | ⚠ Cho thấy quan hệ PHÂN CẤP giữa các phần việc | | | ⚠ Là nền tảng để ước lượng, lập lịch, phân công | | | ⚠ Giúp không BỎ SÓT công việc nào | ⚠ quy tắc 100% — WBS phải bao phủ toàn bộ phạm vi | | ⚠ Áp dụng cho MỌI dự án | ⚠ kể cả dự án nội bộ như nhà mẫu của Allan | | ⚠ Trả lời Milo | ⚠ giá trị của WBS nằm ở việc LẬP KẾ HOẠCH, không phụ thuộc vào việc có khách hàng bên ngoài hay không |

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

• C (không thể xác định được ngân sách nếu không có WBS) — ⚠ phương án gây nhiễu mạnh nhất vì WBS thật sự là cơ sở tốt nhất để lập ngân sách: ⚠ nhưng ⚠ nói "KHÔNG THỂ" là quá tuyệt đối ⚠ — vẫn ước lượng được bằng phương pháp tương tự hoặc tham số (liên hệ #25990 cùng lô); ⚠ ước lượng sẽ kém chính xác hơn, nhưng không phải là bất khả thi.

• A (cho phép lập kế hoạch theo vòng lặp) — ⚠ nhầm khung: ⚠ WBS là công cụ của cách tiếp cận DỰ ĐOÁN; ⚠ dự án nhà mẫu này rõ ràng là dự đoán (liên hệ #25988 cùng lô).

• D (bên liên quan thích nhìn thấy nó trong các buổi họp) — ⚠ lý do hình thức, ⚠ không nói lên giá trị thật.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25997 và #26007 ở lô này (mô tả phạm vi sản phẩm), câu #25989 (loại trừ khỏi phạm vi), và câu #25988 (dự án xây dựng → dự đoán). ⚠ Nhóm quản lý phạm vi — và WBS là bước tiếp theo sau tuyên bố phạm vi.

⚠ ĐƯỜNG CƠ SỞ PHẠM VI gồm ba phần: | Phần | Nội dung | |---|---| | ⚠ TUYÊN BỐ PHẠM VI | ⚠ bốn mục đã gặp qua sáu câu ở lô 184–185 | | ⚠ WBS | ⚠ cấu trúc phân rã công việc — CÂU NÀY | | ⚠ TỪ ĐIỂN WBS | ⚠ mô tả chi tiết từng gói công việc: nội dung, người chịu trách nhiệm, tiêu chí chấp nhận | | ⚠ Ba phần này | ⚠ là đường cơ sở, chỉ đổi được qua kiểm soát thay đổi |

⚠ Các quy tắc của WBS: | Quy tắc | Nội dung | |---|---| | ⚠ QUY TẮC 100% | ⚠ WBS phải chứa TOÀN BỘ phạm vi, không thiếu không thừa | | ⚠ Phân rã tới GÓI CÔNG VIỆC | ⚠ mức đủ nhỏ để ước lượng và giao được | | ⚠ Mỗi phần tử chỉ thuộc MỘT nhánh cha | ⚠ không trùng lặp | | ⚠ Mô tả bằng DANH TỪ — sản phẩm, không phải hành động | ⚠ "Hệ thống điện" chứ không phải "Lắp điện" | | ⚠ Quy tắc 8/80 | ⚠ gói công việc nên tốn từ 8 tới 80 giờ — hướng dẫn, không phải luật | | ⚠ WBS KHÔNG phải | ⚠ danh sách công việc theo thứ tự thời gian — nó không có trình tự, đó là việc của lịch trình |

Từ khoá nhận diện:

"quan hệ giữa các công việc, lập kế hoạch dễ hơn" → ⚠ WBS "không thể làm được nếu thiếu" → ⚠ cẩn thận với từ tuyệt đối "lập kế hoạch vòng lặp" → ⚠ agile, không phải WBS "để bên liên quan xem" → ⚠ lý do hình thức

Ba việc kiểm chứng: | Việc | Cách | |---|---| | WBS của bạn có bao phủ 100% phạm vi không | ⚠ thử hỏi: việc gì trong dự án không nằm ở đâu trong WBS? | | Các phần tử được đặt tên bằng danh từ hay động từ | | | Từ điển WBS có tồn tại không | ⚠ thường bị bỏ, và đó là lý do các gói công việc bị hiểu khác nhau |

Và câu trả lời ngắn nhất cho Milo: khách hàng nội bộ hay bên ngoài không làm thay đổi độ phức tạp của công việc — và WBS tồn tại để xử lý độ phức tạp đó, không phải để làm hài lòng ai.

Đáp án

D — CẢI TIẾN LIÊN TỤC (continual improvement).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Neil đã ĐẠT mốc — nhà máy chạy đủ sản lượng yêu cầu | ⚠ mục tiêu đã hoàn thành | | ⚠ NGAY HÔM SAU đã tìm ra vấn đề của quy trình | ⚠ không dừng lại ở mức "đủ tốt" | | ⚠ Vấn đề: một số bước không thể đảo ngược mà không phải làm lại từ đầu | | | ⚠ Neil nghĩ cách MÔ-ĐUN HOÁ để điều chỉnh được khi phát hiện lỗi | ⚠ chủ động cải tiến quy trình | | ⚠ Định nghĩa | ⚠ cải tiến liên tục là nỗ lực THƯỜNG XUYÊN nâng cao sản phẩm, dịch vụ hoặc quy trình |

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

• A (trách nhiệm của lãnh đạo) — ⚠ phương án gây nhiễu mạnh nhất vì Neil ĐANG là người quản lý chủ động: ⚠ nhưng nguyên tắc "trách nhiệm của lãnh đạo" nói về việc ⚠ lãnh đạo phải CUNG CẤP NGUỒN LỰC và cam kết cho chất lượng, ⚠ không nói về việc cải tiến quy trình sau khi đạt mục tiêu.

• B (sự hài lòng của khách hàng) — ⚠ hướng ra bên ngoài; ⚠ Neil đang cải thiện quy trình NỘI BỘ, chưa nói tới khách hàng.

• C (quan hệ đối tác đôi bên cùng có lợi) — ⚠ về quan hệ với NHÀ CUNG CẤP; ⚠ hoàn toàn không xuất hiện trong đề.

Ghi nhớ

⚠ Đối chiếu — BỘ NGUYÊN TẮC QUẢN LÝ CHẤT LƯỢNG lên câu thứ NĂM, và đây là KHOÁ MỚI: | Nguyên tắc | Câu đã hỏi | |---|---| | ⚠ Trách nhiệm của lãnh đạo | ⚠ #25744 (lô 180) | | ⚠ Sự hài lòng của khách hàng | ⚠ #25758 (lô 180), #25788 (lô 181) | | ⚠ Quan hệ đối tác cùng có lợi | ⚠ #25766 (lô 180) | | ⚠ CẢI TIẾN LIÊN TỤC | ⚠ #26018 (lô này) — KHOÁ MỚI, chưa từng xuất hiện | | ⚠ Nhận xét | ⚠ bốn nguyên tắc này luôn xuất hiện cùng nhau trong bộ phương án — thuộc cả bốn thì loại trừ rất nhanh | | ⚠ Dự đoán | ⚠ các lô sau nhiều khả năng vẫn dùng đúng bộ bốn này |

⚠ Bốn nguyên tắc — phân biệt bằng ĐỐI TƯỢNG: | Nguyên tắc | Hướng tới ai | |---|---| | ⚠ Hài lòng khách hàng | ⚠ KHÁCH HÀNG — đáp ứng và vượt kỳ vọng | | ⚠ Trách nhiệm lãnh đạo | ⚠ LÃNH ĐẠO — cấp nguồn lực, cam kết, làm gương | | ⚠ Đối tác cùng có lợi | ⚠ NHÀ CUNG CẤP — quan hệ dài hạn, không ép giá | | ⚠ Cải tiến liên tục | ⚠ QUY TRÌNH NỘI BỘ — luôn tìm cách làm tốt hơn | | ⚠ Mẹo làm đề | ⚠ xác định đề đang nói về ai, rồi chọn nguyên tắc tương ứng |

Từ khoá nhận diện:

"đạt mục tiêu rồi vẫn tìm cách cải thiện" → ⚠ cải tiến liên tục "vượt kỳ vọng khách hàng" → ⚠ hài lòng khách hàng "lãnh đạo cấp nguồn lực cho chất lượng" → ⚠ trách nhiệm lãnh đạo "quan hệ dài hạn với nhà cung cấp" → ⚠ đối tác cùng có lợi

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quy trình của bạn có bước nào không đảo ngược được không | ⚠ đó là chỗ rủi ro nhất | | Sau khi đạt mục tiêu, đội bạn có nhìn lại quy trình không | | | Cải tiến gần nhất do ai đề xuất | ⚠ nếu luôn là quản lý thì kaizen chưa thật sự hoạt động |

Và điều Neil hiểu đúng về cải tiến liên tục: đạt được mục tiêu không phải là đích đến — nó chỉ là lần đầu tiên bạn có đủ thông tin thật để biết quy trình của mình yếu ở đâu.

Đáp án

D — GHÉP CẶP thành viên đó với một lập trình viên GIÀU KINH NGHIỆM HƠN.

Vì sao đúng

⚠ Vì sao ghép cặp là giải pháp tốt nhất: | Lý do | Nội dung | |---|---| | ⚠ Gỡ vật cản NGAY LẬP TỨC | ⚠ công việc không bị dừng chờ đào tạo | | ⚠ Chuyển giao tri thức TRONG BỐI CẢNH công việc thật | ⚠ hiệu quả hơn khoá học rất nhiều | | ⚠ Xây dựng CHUYÊN GIA ĐA NĂNG cho đội | ⚠ liên hệ #25928 lô 183 | | ⚠ Không tách người khỏi đội | | | ⚠ Là thực hành kinh điển của XP: lập trình cặp | | | ⚠ Vai của George | ⚠ Scrum Master gỡ vật cản bằng cách sắp xếp nguồn lực trong đội, không tự đi code thay |

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

• C (cử thành viên đi đào tạo) — ⚠ phương án gây nhiễu mạnh nhất vì đào tạo là đầu tư đúng đắn: ⚠ nhưng nó ⚠ QUÁ CHẬM cho vấn đề đang xảy ra ngay bây giờ, ⚠ tách người khỏi đội giữa sprint, ⚠ và khoá đào tạo chung hiếm khi khớp chính xác với công việc cụ thể đang mắc.

• A (không làm gì, đội sẽ tự lo) — ⚠ bỏ mặc; ⚠ George đã BIẾT có vấn đề, ⚠ và gỡ vật cản là trách nhiệm của anh (liên hệ #26008 cùng lô).

• B (phàn nàn với quản lý của lập trình viên) — ⚠ biến vấn đề năng lực thành chuyện kỷ luật; ⚠ người đó đang CHẬT VẬT chứ không phải lười (liên hệ #25939 lô 184 — tìm nguyên nhân trước khi trừng phạt).

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25931 ở lô 184 (thành viên mới đặt câu hỏi → trả lời và chỉ tài liệu), câu #25968 (người ngại nói trong retrospective), câu #26011 ở lô này (Stephen học agile bằng cách hợp tác với đồng đội), và câu #25928 lô 183 (chuyên gia đa năng). ⚠ Cả nhóm: phát triển con người bằng cách làm việc CÙNG NHAU, không bằng cách tách họ ra.

⚠ Lập trình cặp mang lại gì: | Lợi ích | Nội dung | |---|---| | ⚠ Chuyển giao tri thức tức thời | | | ⚠ Rà soát mã ngay trong lúc viết | ⚠ thay vì rà soát sau | | ⚠ Ít lỗi hơn | | | ⚠ Giảm rủi ro "chỉ một người biết" | ⚠ liên hệ #26015 cùng lô — người bị nhiều nơi cùng cần | | ⚠ Người mới hoà nhập nhanh hơn | | | ⚠ Chi phí | ⚠ hai người cho một việc — nhưng thường bù lại bằng ít lỗi và ít thời gian sửa | | ⚠ Lưu ý | ⚠ không cần cặp mọi lúc; dùng cho phần khó, phần mới, hoặc khi cần lan toả kiến thức |

Từ khoá nhận diện:

"thành viên chật vật với một việc cụ thể" → ⚠ ghép cặp "cử đi đào tạo" → ⚠ quá chậm cho vấn đề đang xảy ra "báo quản lý" → ⚠ biến vấn đề năng lực thành kỷ luật "không làm gì" → ⚠ bỏ mặc, gần như luôn sai

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai đang mắc mà không dám nói không | | | Lập trình cặp có được dùng khi cần không | | | Người trẻ trong đội có được giao việc khó kèm hỗ trợ không | ⚠ hay chỉ được giao việc dễ mãi mãi |

Và điều đáng chú ý về lựa chọn của George: anh không giải quyết vấn đề, cũng không giao vấn đề cho người khác — anh sắp xếp để đội tự giải quyết. Đó là định nghĩa gọn nhất của việc gỡ vật cản.

Đáp án

A — KHOẢNG CÁCH (distance).

Vì sao đúng

⚠ Nhiễu trong mô hình giao tiếp là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Bất cứ thứ gì CẢN TRỞ hoặc LÀM MÉO thông điệp | ⚠ giữa người gửi và người nhận | | ⚠ KHOẢNG CÁCH gây ra | ⚠ lệch múi giờ, mất ngôn ngữ cơ thể, chậm phản hồi, khó gặp trực tiếp | | ⚠ Nó làm giảm cả MẬT ĐỘ lẫn TÍNH TƯƠNG TÁC | ⚠ liên hệ #25979 lô 184 — hai trục hiệu quả giao tiếp | | ⚠ Đúng định nghĩa | ⚠ khoảng cách không mang thông tin nào, nó chỉ làm thông điệp khó tới đích hơn |

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

• D (máy chủ email) — ⚠ phương án gây nhiễu mạnh nhất vì máy chủ HỎNG thì đúng là gây nhiễu: ⚠ nhưng bản thân máy chủ email là ⚠ PHƯƠNG TIỆN truyền tin ⚠ trong mô hình giao tiếp, ⚠ không phải nhiễu ⚠ — nó là thứ giúp thông điệp đi tới, không phải thứ cản trở.

• C (trò chuyện tuỳ hứng) — ⚠ một PHƯƠNG PHÁP giao tiếp, ⚠ và là phương pháp có tính tương tác cao.

• B (thoả thuận hợp đồng) — ⚠ một loại NỘI DUNG hoặc RÀNG BUỘC, ⚠ không phải nhiễu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25948 ở lô 184 (nhà tài trợ là người mã hoá), câu #25950 (xác nhận qua ngôn ngữ cơ thể), câu #25942 (ràng buộc giao tiếp — vị trí địa lý), và câu #25979 (hai trục hiệu quả). ⚠ Mô hình giao tiếp đã được khai thác từ bốn góc khác nhau, và câu này là góc thứ năm: NHIỄU.

⚠ Các thành phần của mô hình giao tiếp: | Thành phần | Nội dung | |---|---| | ⚠ NGƯỜI GỬI / MÃ HOÁ | ⚠ biến ý nghĩ thành thông điệp | | ⚠ THÔNG ĐIỆP | ⚠ nội dung được truyền | | ⚠ PHƯƠNG TIỆN | ⚠ kênh truyền — email, họp, điện thoại, MÁY CHỦ EMAIL thuộc đây | | ⚠ NHIỄU | ⚠ thứ làm méo hoặc cản trở — KHOẢNG CÁCH thuộc đây | | ⚠ NGƯỜI NHẬN / GIẢI MÃ | ⚠ diễn giải thông điệp | | ⚠ PHẢN HỒI / XÁC NHẬN | ⚠ liên hệ #25950 | | ⚠ Mẹo phân biệt | ⚠ PHƯƠNG TIỆN giúp thông điệp ĐI TỚI; NHIỄU khiến nó KHÔNG TỚI hoặc TỚI SAI |

⚠ Các nguồn nhiễu thường gặp trong dự án: | Nguồn | Ví dụ | |---|---| | ⚠ VẬT LÝ | ⚠ khoảng cách, tiếng ồn, đường truyền kém — CÂU NÀY | | ⚠ NGÔN NGỮ | ⚠ khác tiếng mẹ đẻ, thuật ngữ chuyên ngành | | ⚠ VĂN HOÁ | ⚠ cách hiểu khác nhau về sự lịch sự, về việc nói thẳng | | ⚠ TÂM LÝ | ⚠ định kiến, cảm xúc, thiếu lòng tin | | ⚠ TỔ CHỨC | ⚠ quá nhiều tầng trung gian, thông tin bị lọc dần | | ⚠ Nguồn nhiễu bị đánh giá thấp nhất | ⚠ TÂM LÝ — người nghe không tin người nói thì mọi thông điệp đều bị méo |

Từ khoá nhận diện:

"khoảng cách, tiếng ồn, đường truyền" → ⚠ nhiễu "email, họp, điện thoại, hệ thống" → ⚠ phương tiện "trò chuyện, thuyết trình" → ⚠ phương pháp giao tiếp "hợp đồng, quy định" → ⚠ nội dung hoặc ràng buộc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bao nhiêu địa điểm và múi giờ | | | Có bao nhiêu tầng trung gian giữa bạn và nhà tài trợ | ⚠ mỗi tầng là một lớp nhiễu | | Bạn có xác nhận người ta đã hiểu không, hay chỉ biết đã gửi | |

Và điều mô hình này nhắc lại lần nữa: khoảng cách không xoá được, nhưng ảnh hưởng của nó lên thông điệp thì hoàn toàn có thể bù đắp — với điều kiện là người gửi ý thức được rằng nó đang ở đó.

Đáp án

B — KIỂM TRA CHẤT LƯỢNG LÀ PHẦN THIẾT YẾU của bất kỳ dự án nào.

Vì sao đúng

⚠ Vì sao Penny làm đúng: | Lý do | Nội dung | |---|---| | ⚠ Chất lượng KHÔNG PHẢI việc tuỳ chọn khi còn thời gian | ⚠ nó là điều kiện để bàn giao được chấp nhận | | ⚠ Đối chiếu với DANH SÁCH KIỂM là kỹ thuật kiểm soát chất lượng chuẩn | ⚠ liên hệ #25955 lô 184 | | ⚠ Dự án ĐANG ĐÚNG TIẾN ĐỘ — đây là lúc tốt nhất để làm | ⚠ không phải lúc chạy nước rút | | ⚠ Phát hiện lỗi sớm rẻ hơn nhiều | ⚠ liên hệ #25924 lô 183 — chi phí phù hợp với chất lượng | | ⚠ Trả lời PO | ⚠ không phải "vì tôi lo dự án hỏng", mà là "vì đó là việc phải làm ở mọi dự án" |

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

• A (Penny nghĩ dự án có thể thất bại) — ⚠ phương án gây nhiễu mạnh nhất vì nghe như một lý do chính đáng: ⚠ nhưng nó ⚠ biến việc kiểm chất lượng thành phản ứng với NỖI SỢ, ⚠ trong khi nó phải là ⚠ hoạt động THƯỜNG XUYÊN có kế hoạch; ⚠ trả lời như vậy còn khiến PO hoảng hốt không cần thiết.

• C (đồng ý với PO và bỏ các bước kiểm) — ⚠ nhượng bộ sai nguyên tắc; ⚠ Scrum Master phải bảo vệ chất lượng.

• D (đội cần lấp đầy lịch làm việc) — ⚠ lý do vô nghĩa, ⚠ và làm mất uy tín của chính đề xuất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25953 ở lô 184 (kiểm thử phải nằm trong Định nghĩa Hoàn thành), câu #25986 ở lô này (tích hợp liên tục cần kiểm thử tự động), câu #26000 (kiểm thử thăm dò bổ sung cho kiểm thử theo kịch bản), và câu #25955 (danh sách kiểm). ⚠ Nhóm chất lượng đã lên năm câu.

⚠ Vì sao chất lượng hay bị coi là "việc thêm": | Lý do | Nội dung | |---|---| | ⚠ Nó không tạo ra TÍNH NĂNG MỚI nhìn thấy được | | | ⚠ Lợi ích của nó là thứ KHÔNG XẢY RA | ⚠ lỗi không lọt ra ngoài — khó ghi nhận | | ⚠ Áp lực giao hàng luôn hiện hữu hơn | | | ⚠ Lập luận thuyết phục PO | ⚠ "nếu lỗi lọt tới khách hàng, chi phí sửa gấp nhiều lần thời gian chúng ta bỏ ra hôm nay" | | ⚠ Cách tốt hơn nữa | ⚠ đưa các bước kiểm vào ĐỊNH NGHĨA HOÀN THÀNH để không phải xin phép mỗi lần — liên hệ #25953 |

Từ khoá nhận diện:

"vì sao dành thời gian kiểm chất lượng" → ⚠ vì nó là phần thiết yếu của mọi dự án "vì tôi lo dự án thất bại" → ⚠ biến việc thường xuyên thành phản ứng hoảng loạn "đồng ý bỏ đi" → ⚠ nhượng bộ sai nguyên tắc "lấp đầy lịch" → ⚠ lý do vô nghĩa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các bước kiểm chất lượng của bạn có nằm trong DoD không | ⚠ nếu có thì không ai hỏi "vì sao tốn thời gian" nữa | | Có ai từng đề nghị bỏ bước kiểm để kịp hạn không | | | Chi phí làm lại của dự án trước là bao nhiêu | ⚠ con số này thuyết phục hơn mọi lập luận |

Và điều Penny nên nhớ khi PO phản đối: câu hỏi của anh ta không phải là dấu hiệu thiếu quan tâm tới chất lượng — đó là dấu hiệu chất lượng chưa được đưa vào định nghĩa chung, nên nó vẫn còn phải xin phép từng lần.

Đáp án

B — GẶP bên liên quan và HƯỚNG DẪN họ những điều cơ bản.

Vì sao đúng

⚠ Vì sao gặp trực tiếp là đúng: | Lý do | Nội dung | |---|---| | ⚠ GIÁO DỤC tổ chức là vai trò của Scrum Master | ⚠ liên hệ #25913 lô 183 | | ⚠ Gặp trực tiếp là kênh hiệu quả nhất | ⚠ liên hệ #25954 lô 184 | | ⚠ Cho phép HỎI ĐÁP theo đúng nhu cầu của người đó | ⚠ tài liệu chung không làm được | | ⚠ Xây dựng quan hệ ngay từ đầu | ⚠ quan trọng vì họ sẽ đồng hành suốt dự án | | ⚠ Bối cảnh | ⚠ dự án đang TRỄ một tuần — càng cần bên liên quan hiểu đúng cách đọc tiến độ trong agile |

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

• A (gửi các đường dẫn về agile cho họ) — ⚠ phương án gây nhiễu mạnh nhất vì tài liệu là hỗ trợ hợp lý: ⚠ nhưng ⚠ chỉ gửi link là đẩy việc học sang người khác; ⚠ nó lạnh nhạt với một người MỚI THAM GIA, ⚠ và không giúp họ hiểu agile ÁP DỤNG CỤ THỂ ra sao trong dự án này.

• D (nhờ product owner nói chuyện với họ) — ⚠ đẩy việc; ⚠ giáo dục về agile là vai của Scrum Master, không phải của PO.

• C (mời bên liên quan dự daily standup) — ⚠ SAI BUỔI HỌP: ⚠ daily scrum là buổi của ĐỘI, 15 phút, để đồng bộ và nêu vật cản ⚠ (liên hệ #25921 lô 183); ⚠ buổi phù hợp để mời bên liên quan là SPRINT REVIEW ⚠ (liên hệ #25877 lô 182).

Ghi nhớ

⚠ Đối chiếu — câu GẦN TRÙNG: ⚠ câu #25913 ở lô 183 ⚠ (bên liên quan không hiểu story point → nhắc ngắn gọn rồi gửi tài liệu bổ sung). ⚠ Hai khoá NHẤT QUÁN: cả hai đều là TƯƠNG TÁC TRỰC TIẾP TRƯỚC, tài liệu là phần bổ sung. ⚠ Khác biệt: #25913 xảy ra giữa một buổi họp khác nên phải NGẮN GỌN; ở đây là người mới tham gia nên cần một buổi HƯỚNG DẪN đầy đủ. ⚠ Điểm chung quan trọng nhất: KHÔNG câu nào chọn phương án "chỉ gửi tài liệu". ⚠ Xem thêm câu #25931 lô 184 (trả lời câu hỏi VÀ chỉ tài liệu) và câu #25961 (Ethel chưa gắn kết bên liên quan).

⚠ Nên hướng dẫn bên liên quan mới những gì: | Nội dung | Vì sao | |---|---| | ⚠ Nhịp làm việc: sprint dài bao lâu, có những buổi họp nào | | | ⚠ Họ được mời tham gia buổi nào | ⚠ sprint review — và VÌ SAO không phải daily scrum | | ⚠ Cách đọc tiến độ trong agile | ⚠ velocity, burndown — và ý nghĩa thật của chúng | | ⚠ Cách đưa yêu cầu mới vào | ⚠ qua backlog và product owner — liên hệ #25905 lô 183 | | ⚠ Ai làm gì: PO, Scrum Master, đội | | | ⚠ Vì sao dự án trễ một tuần và kế hoạch xử lý | ⚠ minh bạch ngay từ đầu — liên hệ #26004 cùng lô | | ⚠ Nguyên tắc trình bày | ⚠ nói bằng ngôn ngữ của HỌ, tránh thuật ngữ Scrum không cần thiết |

Từ khoá nhận diện:

"bên liên quan mới chưa quen agile" → ⚠ gặp và hướng dẫn cơ bản "chỉ gửi link/tài liệu" → ⚠ đẩy việc học sang người khác "mời dự daily standup" → ⚠ sai buổi họp — đó là buổi của đội "nhờ người khác nói" → ⚠ đẩy trách nhiệm giáo dục

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có biết họ được mời buổi nào không | | | Có ai đang dự nhầm buổi họp không | | | Người mới tham gia dự án có được đón tiếp không | ⚠ hay tự mò như một người ngoài cuộc |

Và điều Durand mua được bằng một buổi gặp: một bên liên quan hiểu cách đọc tiến độ sẽ không hoảng lên khi thấy dự án trễ một tuần — họ sẽ hỏi kế hoạch xử lý. Đó là khác biệt giữa một đồng minh và một nguồn áp lực.