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

Tìm thấy 720 câu.

Câu 501 Business Environment
Roger is the project manager for a business that specializes in gas engineering. Recent legislation was passed by the federal government that restricts the use of lead in the gas's chemical composition, which is the primary component used in gases at Roger's company. Which of the following choices is not a project management knowledge area that Roger should assess through integrated change control for projects currently underway?
  1. A Schedule
  2. B Cost
  3. C Technological
  4. D Procurement
Xem giải thích

Đáp án

C — CÔNG NGHỆ (Technological) — đây KHÔNG phải một lĩnh vực kiến thức quản lý dự án.

Vì sao đúng

⚠ MƯỜI lĩnh vực kiến thức của PMBOK — thuộc lòng danh sách này: | # | Lĩnh vực | |---|---| | ⚠ 1 | ⚠ TÍCH HỢP (Integration) | | ⚠ 2 | ⚠ PHẠM VI (Scope) | | ⚠ 3 | ⚠ LỊCH TRÌNH (Schedule) — ⚠ phương án A | | ⚠ 4 | ⚠ CHI PHÍ (Cost) — ⚠ phương án B | | ⚠ 5 | ⚠ CHẤT LƯỢNG (Quality) | | ⚠ 6 | ⚠ NGUỒN LỰC (Resource) | | ⚠ 7 | ⚠ TRUYỀN THÔNG (Communications) | | ⚠ 8 | ⚠ RỦI RO (Risk) | | ⚠ 9 | ⚠ MUA SẮM (Procurement) — ⚠ phương án D | | ⚠ 10 | ⚠ BÊN LIÊN QUAN (Stakeholder) | | ⚠ Kết luận | ⚠ "Công nghệ" KHÔNG có trong danh sách — đó là đáp án của câu hỏi phủ định này |

Vì sao các phương án khác sai — ba phương án còn lại ĐỀU là lĩnh vực thật

  • A (lịch trình) — ⚠ LĨNH VỰC THẬT: ⚠ luật mới có thể buộc đổi công thức, kéo dài thời gian thử nghiệm.
  • B (chi phí) — ⚠ LĨNH VỰC THẬT: ⚠ nguyên liệu thay thế thường đắt hơn.
  • D (mua sắm) — ⚠ LĨNH VỰC THẬT: ⚠ phải tìm nhà cung cấp nguyên liệu mới, sửa hợp đồng cũ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26206 ở lô này (thay đổi được duyệt KHÔNG dẫn tới cập nhật điều lệ), ⚠ câu #26101 lô 187 (quy trình kiểm soát thay đổi), ⚠ câu #26023 lô 185 (đổi đường cơ sở), ⚠ câu #26136 lô 188 (yếu tố địa chính trị).

⚠ Vì sao "công nghệ" nghe có vẻ hợp lý mà vẫn sai: | Lý do gây nhầm | Sự thật | |---|---| | ⚠ Công nghệ RÕ RÀNG ảnh hưởng tới dự án của Roger | ⚠ đúng, nhưng nó là NỘI DUNG chuyên môn, không phải lĩnh vực quản lý | | ⚠ Nhiều tổ chức có "bộ phận công nghệ" | ⚠ đó là cơ cấu tổ chức, không phải khung PMBOK | | ⚠ Câu hỏi hỏi về LĨNH VỰC KIẾN THỨC QUẢN LÝ DỰ ÁN | ⚠ danh sách cố định gồm mười mục | | ⚠ Mẹo làm bài | ⚠ thấy phương án là một danh từ chuyên ngành (công nghệ, kỹ thuật, pháp lý, marketing) trong câu hỏi về lĩnh vực kiến thức → gần như chắc chắn đó là đáp án của câu phủ định |

Từ khoá nhận diện:

"công nghệ, kỹ thuật, pháp lý" → ⚠ KHÔNG phải lĩnh vực kiến thức "lịch trình, chi phí, mua sắm, rủi ro, chất lượng" → ⚠ là lĩnh vực kiến thức "tích hợp" → ⚠ lĩnh vực bao trùm, nơi kiểm soát thay đổi tích hợp nằm "kiểm soát thay đổi tích hợp" → ⚠ thuộc lĩnh vực TÍCH HỢP

⚠ Luật mới của Roger ảnh hưởng tới lĩnh vực nào — rà hết mười lĩnh vực Ảnh hưởng
⚠ PHẠM VI ⚠ đổi công thức sản phẩm
⚠ LỊCH TRÌNH ⚠ thêm thời gian nghiên cứu và thử nghiệm
⚠ CHI PHÍ ⚠ nguyên liệu thay thế, thử nghiệm lại
⚠ CHẤT LƯỢNG ⚠ tiêu chuẩn mới phải đạt
⚠ MUA SẮM ⚠ nhà cung cấp mới, hợp đồng cũ có thể phải chấm dứt
⚠ RỦI RO ⚠ rủi ro tuân thủ, rủi ro sản phẩm không đạt
⚠ BÊN LIÊN QUAN ⚠ cơ quan quản lý trở thành bên liên quan quan trọng
⚠ Bài học ⚠ một thay đổi từ bên ngoài chạm vào gần như MỌI lĩnh vực — đó chính là lý do phải KIỂM SOÁT THAY ĐỔI TÍCH HỢP chứ không xử lý rời rạc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có kể được mười lĩnh vực kiến thức không | | | Thay đổi gần nhất của bạn đã rà đủ các lĩnh vực chưa | ⚠ hay chỉ nhìn lịch và tiền | | Có thay đổi luật lệ nào sắp tới ảnh hưởng dự án bạn không | |

Và giá trị thật của việc thuộc mười lĩnh vực: nó là danh sách kiểm để không bỏ sót — khi một thay đổi lớn ập tới, bạn rà từng mục thay vì chỉ nhìn thứ đập vào mắt trước nhất.

Câu 502 Process
Frankie is working on collecting the requirements for a project as part of developing the scope management plan. However, several conditions require acquiring classified information from stakeholders. Frankie is debating on several data-gathering techniques to gather the information he needs to determine the customer requirements. Which data gathering technique would be most helpful for Frankie to obtain classified information?
  1. A Brainstorming
  2. B Benchmarking
  3. C Focus groups
  4. D Interviews
Xem giải thích

Đáp án

D — PHỎNG VẤN (interviews).

Vì sao đúng

⚠ Vì sao phỏng vấn hợp với thông tin mật: | Lý do | Nội dung | |---|---| | ⚠ RIÊNG TƯ — chỉ có người hỏi và người trả lời | ⚠ yếu tố quyết định | | ⚠ Kiểm soát được AI nghe thông tin gì | | | ⚠ Người ta nói thẳng hơn khi không có mặt người khác | | | ⚠ Đào sâu được bằng câu hỏi nối tiếp | | | ⚠ Ba kỹ thuật kia | ⚠ đều là hoạt động NHÓM — không dùng được cho thông tin mật |

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

  • C (nhóm tập trung — focus groups) — ⚠ phương án gây nhiễu mạnh nhất vì nó ⚠ có điều phối viên và quy mô nhỏ, ⚠ nghe có vẻ kiểm soát được: ⚠ nhưng nó vẫn là ⚠ hoạt động NHIỀU NGƯỜI ⚠ — thông tin mật nói ra trước một nhóm thì không còn mật nữa.

  • A (động não — brainstorming) — ⚠ hoạt động nhóm mở, mọi người nghe hết.

  • B (so chuẩn — benchmarking) — ⚠ so sánh với tổ chức khác; ⚠ hoàn toàn không phải cách thu thập yêu cầu từ bên liên quan nội bộ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26183 ở lô này (gặp riêng từng bên liên quan trước rồi họp chung) — ⚠ cùng một nguyên lý: gặp riêng cho thông tin nhạy cảm và cho ý kiến thật; ⚠ câu #26185 ở lô này (phân tích bên liên quan), ⚠ câu #26178 lô 188 (xác định phạm vi).

⚠ Các kỹ thuật thu thập yêu cầu — dùng cái nào khi nào: | Kỹ thuật | Đặc điểm | Hợp với | |---|---|---| | ⚠ PHỎNG VẤN | ⚠ một–một, riêng tư, đào sâu | ⚠ thông tin mật, nhạy cảm, ý kiến cá nhân — CÂU NÀY | | ⚠ NHÓM TẬP TRUNG | ⚠ nhóm nhỏ có điều phối viên | ⚠ khai thác ý kiến tương tác giữa người dùng | | ⚠ ĐỘNG NÃO | ⚠ nhóm mở, tạo nhiều ý tưởng | ⚠ giai đoạn tìm ý, không phải chốt yêu cầu | | ⚠ HỘI THẢO HƯỚNG DẪN | ⚠ nhóm liên chức năng, giải quyết bất đồng nhanh | ⚠ liên hệ #26191 cùng lô | | ⚠ BẢNG HỎI, KHẢO SÁT | ⚠ số lượng lớn, thống kê được | ⚠ nhiều người ở nhiều nơi | | ⚠ SO CHUẨN | ⚠ so với tổ chức khác | ⚠ tìm chuẩn mực, không phải yêu cầu cụ thể | | ⚠ QUAN SÁT | ⚠ xem người ta LÀM thật | ⚠ khi người dùng không nói được điều họ làm | | ⚠ Với thông tin mật | ⚠ chỉ PHỎNG VẤN đáp ứng được yêu cầu bảo mật |

Từ khoá nhận diện:

"thông tin mật, nhạy cảm" → ⚠ phỏng vấn "tương tác nhóm nhỏ có điều phối" → ⚠ nhóm tập trung "tạo nhiều ý tưởng nhanh" → ⚠ động não "so sánh với tổ chức khác" → ⚠ so chuẩn

⚠ Phỏng vấn thu thập thông tin mật cần lưu ý gì Lưu ý
⚠ Xác định rõ AI được biết thông tin đó ⚠ trước khi bắt đầu
⚠ Ghi chép và LƯU TRỮ có kiểm soát ⚠ thông tin mật trong file chung là rò rỉ chờ xảy ra
⚠ Có thể cần THOẢ THUẬN BẢO MẬT
⚠ Khi tổng hợp vào tài liệu yêu cầu phải cân nhắc mức chi tiết ⚠ tài liệu yêu cầu thường được phát rộng
⚠ Liên hệ ⚠ #26216 cùng lô — truyền thông ĐẨY có kiểm soát cho thông tin nhạy cảm
⚠ Kỹ thuật phỏng vấn tốt Cách làm
⚠ Chuẩn bị câu hỏi trước, nhưng cho phép đi lệch
⚠ Hỏi MỞ trước, hỏi ĐÓNG để xác nhận sau
⚠ Nghe nhiều hơn nói ⚠ liên hệ #26191 cùng lô — lắng nghe chủ động
⚠ XÁC NHẬN lại cách hiểu ở cuối buổi ⚠ liên hệ #26192 cùng lô — vòng phản hồi
⚠ Sai lầm phổ biến ⚠ hỏi dẫn dắt — "anh cũng muốn tính năng này đúng không?" chỉ thu về câu trả lời bạn đã có sẵn trong đầu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Yêu cầu dự án bạn thu thập bằng cách nào | | | Thông tin nhạy cảm trong tài liệu yêu cầu có được kiểm soát không | | | Bạn có hỏi mở hay hỏi dẫn dắt | |

Và lý do phỏng vấn vẫn là kỹ thuật giá trị nhất dù tốn thời gian nhất: những điều quan trọng nhất về một dự án thường là những điều không ai muốn nói trước mặt người khác.

Câu 503 People
As the project manager for Lakeview Plumbing, Avi has shared a velocity chart with the owner of the product. What does a velocity chart measure?
  1. A How many project hours have been burned
  2. B Team capacity
  3. C How many hours the project has burned
  4. D How many team members exist at any given time
Xem giải thích

Đáp án

B — NĂNG LỰC CỦA ĐỘI (team capacity).

Vì sao đúng

⚠ Biểu đồ tốc độ đo gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Số ĐIỂM CÂU CHUYỆN đội hoàn thành mỗi sprint | | | ⚠ Qua nhiều sprint cho thấy đội LÀM ĐƯỢC BAO NHIÊU | ⚠ đó chính là năng lực | | ⚠ Đơn vị là ĐIỂM, KHÔNG phải GIỜ | ⚠ điểm phân biệt với biểu đồ burndown | | ⚠ Dùng để dự báo bao nhiêu sprint nữa xong backlog | | | ⚠ Vì sao dùng điểm chứ không dùng giờ | ⚠ điểm đo ĐỘ PHỨC TẠP TƯƠNG ĐỐI, ổn định hơn giờ và không biến thành công cụ chấm công |

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

  • A và C (đã tiêu bao nhiêu giờ dự án) — ⚠ hai phương án này gần như GIỐNG HỆT NHAU và cùng SAI: ⚠ giờ đã tiêu là thứ BIỂU ĐỒ BURNDOWN hoặc báo cáo chi phí theo dõi, ⚠ không phải biểu đồ tốc độ.

  • D (đội có bao nhiêu người tại một thời điểm) — ⚠ là số lượng nhân sự, ⚠ không phải năng lực; ⚠ hai đội cùng năm người có tốc độ rất khác nhau.

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

⚠ Phương án A và C nói gần như CÙNG MỘT ĐIỀU ⚠ — "đã tiêu bao nhiêu giờ dự án" và "dự án đã tiêu bao nhiêu giờ" ⚠ chỉ khác trật tự từ. ⚠ Điều này không làm câu hỏi sai, ⚠ nhưng nó ⚠ giảm số phương án thật xuống còn ba, ⚠ khiến câu dễ hơn mức đề định. ⚠ Cùng loại lỗi soạn đề với #26013 lô 185 và #25626 lô 177 ⚠ (xương cá và Ishikawa liệt kê thành hai phương án). ⚠ KHOÁ ĐÁP ÁN GIỮ NGUYÊN — B vẫn là câu trả lời đúng duy nhất.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26220 ở lô này (tốc độ là thước đo thực nghiệm, KHÔNG phải chỉ tiêu) — ⚠ cặp câu bổ sung nhau trong cùng một lô; ⚠ câu #26214 ở lô này (công cụ không phải để quản lý vi mô), ⚠ câu #26208 ở lô này (bảng thông tin).

⚠ Phân biệt các biểu đồ agile hay bị lẫn: | Biểu đồ | Đo gì | Trục dọc | |---|---|---| | ⚠ TỐC ĐỘ (velocity chart) | ⚠ hoàn thành bao nhiêu điểm MỖI sprint | ⚠ điểm câu chuyện — CÂU NÀY | | ⚠ BURNDOWN sprint | ⚠ còn lại bao nhiêu việc trong sprint hiện tại | ⚠ điểm hoặc giờ, giảm dần | | ⚠ BURNDOWN phát hành | ⚠ còn lại bao nhiêu tới lúc phát hành | | | ⚠ BURNUP | ⚠ đã làm được bao nhiêu, và TỔNG phạm vi có thay đổi không | ⚠ ưu điểm: thấy được trượt phạm vi | | ⚠ BIỂU ĐỒ DÒNG TÍCH LUỸ (CFD) | ⚠ việc ứ ở cột nào | ⚠ liên hệ #26226 cùng lô | | ⚠ Mẹo nhớ | ⚠ tốc độ nhìn NHIỀU sprint; burndown nhìn TRONG một sprint |

Từ khoá nhận diện:

"biểu đồ tốc độ" → ⚠ năng lực của đội, tính bằng điểm "đã tiêu bao nhiêu giờ" → ⚠ burndown hoặc báo cáo chi phí "còn lại bao nhiêu việc" → ⚠ burndown "phạm vi có phình ra không" → ⚠ burnup

⚠ Avi nên nói gì với chủ sản phẩm khi chia sẻ biểu đồ Cách trình bày
⚠ Nói đây là DỰ BÁO, không phải cam kết ⚠ liên hệ #26220 cùng lô
⚠ Dùng khoảng, không dùng con số đơn ⚠ "khoảng 4 tới 6 sprint nữa" thay vì "đúng 5 sprint"
⚠ Giải thích vì sao vài sprint đầu thấp ⚠ đội đang hình thành — liên hệ #26156 lô 188
⚠ ĐỪNG để nó thành chỉ tiêu ép đội ⚠ rủi ro lớn nhất khi chia sẻ ra ngoài đội
⚠ Nếu chủ sản phẩm hỏi "sao tốc độ không tăng" ⚠ câu trả lời đúng: tốc độ ỔN ĐỊNH là dấu hiệu tốt, không phải vấn đề

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Biểu đồ tốc độ của bạn tính bằng điểm hay bằng giờ | | | Có ai đang dùng biểu đồ đó để ép đội không | | | Bạn có đủ 3–5 sprint để dự báo đáng tin chưa | |

Và điều một biểu đồ tốc độ thật sự cho bạn: không phải là câu trả lời "đội này giỏi cỡ nào", mà là câu trả lời "với đội này, kế hoạch nào là thực tế".

Câu 504 Process
As the amount of work in progress grows, you can also expect growth in:
  1. A The percentage of project completion
  2. B The amount of value provided
  3. C The risk related to potential rework
  4. D The amount of project efficiency
Xem giải thích

Đáp án

C — RỦI RO LIÊN QUAN TỚI VIỆC PHẢI LÀM LẠI (rework).

Vì sao đúng

⚠ Vì sao nhiều việc dở dang làm tăng rủi ro làm lại: | Cơ chế | Nội dung | |---|---| | ⚠ Việc dở dang chưa được KIỂM CHỨNG | ⚠ chưa ai xác nhận nó đúng | | ⚠ Nếu yêu cầu thay đổi, TOÀN BỘ việc dở dang có thể phải sửa | ⚠ cơ chế chính | | ⚠ Càng nhiều việc dở, càng nhiều thứ phải sửa khi có thay đổi | | | ⚠ Việc dở dang là TỒN KHO — mang rủi ro mà chưa mang giá trị | ⚠ quan điểm của tư duy tinh gọn | | ⚠ Đó là lý do | ⚠ Kanban GIỚI HẠN VIỆC ĐANG LÀM (WIP limit) — liên hệ #26214 cùng lô |

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

  • B (lượng giá trị mang lại) — ⚠ phương án gây nhiễu mạnh nhất vì trực giác nói ⚠ "làm nhiều thì được nhiều": ⚠ nhưng ⚠ việc DỞ DANG mang lại giá trị BẰNG KHÔNG ⚠ — chỉ việc HOÀN THÀNH mới có giá trị; ⚠ đây chính là nghịch lý mà tư duy tinh gọn chỉ ra.

  • A (phần trăm hoàn thành dự án) — ⚠ bắt đầu nhiều việc KHÔNG làm dự án tiến gần đích hơn.

  • D (hiệu quả dự án) — ⚠ NGƯỢC LẠI: ⚠ nhiều việc dở dang làm ⚠ chuyển ngữ cảnh nhiều, thời gian chu kỳ dài ra, hiệu quả GIẢM.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26162 lô 188 (Lý thuyết ràng buộc — tìm nút thắt), ⚠ câu #26214 ở lô này (việc bị lẫn mất khi thêm quá nhiều), ⚠ câu #26220 ở lô này (tốc độ), ⚠ câu #26210 ở lô này (chồng lấn sinh rủi ro làm lại).

⚠ BỐN cái giá của quá nhiều việc đang làm dở: | Cái giá | Nội dung | |---|---| | ⚠ RỦI RO LÀM LẠI | ⚠ CÂU NÀY — thay đổi thì phải sửa tất cả | | ⚠ THỜI GIAN CHU KỲ DÀI RA | ⚠ định luật Little: thời gian chu kỳ = việc dở dang ÷ thông lượng | | ⚠ CHI PHÍ CHUYỂN NGỮ CẢNH | ⚠ làm ba việc cùng lúc thì mất tới 40% thời gian cho việc chuyển qua lại | | ⚠ PHẢN HỒI ĐẾN MUỘN | ⚠ chưa xong thì chưa ai kiểm chứng được — sai sót nằm im và tích luỹ | | ⚠ Định luật Little | ⚠ muốn giao nhanh hơn thì GIẢM việc dở dang, không phải bắt đầu thêm việc |

Từ khoá nhận diện:

"việc dở dang tăng" → ⚠ rủi ro làm lại tăng "làm nhiều thì giá trị nhiều" → ⚠ sai — chỉ việc XONG mới có giá trị "tăng phần trăm hoàn thành" → ⚠ bắt đầu không phải hoàn thành "tăng hiệu quả" → ⚠ ngược lại

⚠ Vì sao đội hay bắt đầu quá nhiều việc Nguyên nhân
⚠ Bị chặn ở việc A nên nhảy sang việc B ⚠ thay vì GỠ vật cản ở A — liên hệ #26179 lô 188
⚠ Muốn "trông có vẻ bận rộn" ⚠ văn hoá đo bằng hoạt động thay vì kết quả
⚠ Bên liên quan gây áp lực "khi nào bắt đầu việc của tôi"
⚠ Không có giới hạn việc đang làm ⚠ thiếu cơ chế chặn
⚠ Cách chữa ⚠ đặt GIỚI HẠN cứng cho từng cột, và khi chạm trần thì cả đội xúm vào ĐẨY việc đang có ra khỏi bảng thay vì kéo việc mới vào
⚠ Câu khẩu hiệu tinh gọn ⚠ "DỪNG BẮT ĐẦU, BẮT ĐẦU HOÀN THÀNH" (stop starting, start finishing)
⚠ Đo việc dở dang bằng gì Công cụ
⚠ Đếm số thẻ trong các cột đang xử lý trên bảng Kanban ⚠ đơn giản nhất
⚠ BIỂU ĐỒ DÒNG TÍCH LUỸ (CFD) ⚠ dải màu phình ra là việc đang ứ lại ở cột đó
⚠ THỜI GIAN CHU KỲ trung bình ⚠ dài ra là dấu hiệu việc dở dang tăng
⚠ Chỉ số nên theo dõi nhất ⚠ THỜI GIAN CHU KỲ — nó phản ánh trải nghiệm thật của người chờ kết quả

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có bao nhiêu việc đang làm dở lúc này | ⚠ so với số người trong đội | | Bảng của bạn có giới hạn việc đang làm không | | | Việc dở dang lâu nhất của bạn bắt đầu từ bao giờ | ⚠ con số này thường gây bất ngờ |

Và nghịch lý trung tâm của tư duy tinh gọn: cách nhanh nhất để làm được nhiều việc hơn là bắt đầu ít việc hơn.

Câu 505 People
Heath is the scrum master for Project K, which is in its first iteration. Heath has noticed that several tasks have not met quality checks and is concerned about future tasks. What action should Heath take next?
  1. A Complain to the product owner.
  2. B Determine what training would help improve the team’s quality checks.
  3. C Perform a Monte Carlo analysis.
  4. D Perform a gap analysis.
Xem giải thích

Đáp án

B — XÁC ĐỊNH loại ĐÀO TẠO nào sẽ giúp cải thiện việc kiểm tra chất lượng của đội.

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Dự án đang ở VÒNG LẶP ĐẦU TIÊN | ⚠ đội mới, đang học cách làm việc với nhau | | ⚠ NHIỀU việc không đạt kiểm tra chất lượng | ⚠ không phải một sự cố lẻ — đây là mẫu hình | | ⚠ Mẫu hình lặp lại thường do THIẾU KỸ NĂNG hoặc THIẾU HIỂU BIẾT về chuẩn | | | ⚠ Đào tạo gỡ đúng nguyên nhân gốc | | | ⚠ Vai của Scrum Master | ⚠ gỡ vật cản và PHÁT TRIỂN đội — liên hệ #26177 lô 188 |

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

  • D (thực hiện phân tích khoảng cách — gap analysis) — ⚠ phương án gây nhiễu mạnh nhất vì phân tích khoảng cách ⚠ là công cụ hợp lệ để so hiện trạng với mong muốn: ⚠ nhưng ở đây ⚠ khoảng cách ĐÃ RÕ RÀNG — ⚠ việc không đạt chuẩn chất lượng; ⚠ phân tích thêm chỉ trì hoãn hành động.

  • C (phân tích Monte Carlo) — ⚠ mô phỏng xác suất cho lịch trình và chi phí; ⚠ hoàn toàn không liên quan tới chất lượng công việc.

  • A (than phiền với product owner) — ⚠ product owner không chịu trách nhiệm về kỹ năng kỹ thuật của đội; ⚠ và "than phiền" không phải hành động của lãnh đạo phục vụ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26184 ở lô này (đội chưa biết agile → đào tạo chuyên nghiệp) — ⚠ cùng một kết luận: thiếu kỹ năng thì đào tạo, đừng trông chờ tự khắc giỏi; ⚠ câu #26209 ở lô này (biểu đồ kiểm soát), ⚠ câu #26213 ở lô này (lập trình cặp — cách truyền kỹ năng tại chỗ).

⚠ Vì sao đào tạo là đáp án ở vòng lặp ĐẦU TIÊN: | Lý do | Nội dung | |---|---| | ⚠ Còn SỚM — sửa bây giờ thì cả dự án được hưởng | ⚠ liên hệ #26062 lô 186 — chi phí sửa tăng theo thời gian | | ⚠ Vấn đề LẶP LẠI nhiều việc, không phải sự cố đơn lẻ | ⚠ dấu hiệu vấn đề hệ thống | | ⚠ Đội mới thường chưa rõ ĐỊNH NGHĨA HOÀN THÀNH | ⚠ rất hay là nguyên nhân thật | | ⚠ Đầu tư đào tạo sớm rẻ hơn nhiều so với làm lại suốt dự án | | | ⚠ Nhưng trước khi đào tạo | ⚠ Heath nên tìm hiểu NGUYÊN NHÂN cụ thể — thiếu kỹ năng, chuẩn không rõ, hay thiếu thời gian? |

Từ khoá nhận diện:

"nhiều việc không đạt chuẩn, đội mới" → ⚠ xác định đào tạo cần thiết "phân tích khoảng cách" → ⚠ khi chưa rõ khoảng cách ở đâu "Monte Carlo" → ⚠ mô phỏng rủi ro lịch trình và chi phí "than phiền với product owner" → ⚠ sai vai và sai thái độ

⚠ Ba nguyên nhân thường gặp của việc không đạt chuẩn chất lượng Nguyên nhân
⚠ Đội KHÔNG BIẾT chuẩn là gì ⚠ định nghĩa hoàn thành chưa rõ hoặc chưa thống nhất
⚠ Đội BIẾT nhưng KHÔNG ĐỦ KỸ NĂNG ⚠ đào tạo — CÂU NÀY
⚠ Đội BIẾT và ĐỦ KỸ NĂNG nhưng KHÔNG ĐỦ THỜI GIAN ⚠ vấn đề về khối lượng cam kết, không phải kỹ năng
⚠ Cách phân biệt ⚠ hỏi đội ở buổi nhìn lại — họ biết rõ nhất nguyên nhân nào đúng
⚠ Nếu là nguyên nhân thứ ba ⚠ giải pháp là giảm khối lượng sprint, không phải đào tạo — liên hệ #26220 cùng lô
⚠ Các cách nâng chất lượng ngoài đào tạo lớp học Cách
⚠ LẬP TRÌNH CẶP ⚠ truyền kỹ năng tại chỗ — liên hệ #26213 cùng lô
⚠ Làm rõ và công bố ĐỊNH NGHĨA HOÀN THÀNH ⚠ rẻ nhất, hiệu quả nhanh nhất
⚠ Tự động hoá kiểm thử ⚠ phát hiện sớm, phản hồi nhanh
⚠ Rà soát mã có cấu trúc
⚠ Mời chuyên gia kèm cặp trong vài sprint ⚠ liên hệ #26173 lô 188 — huấn luyện
⚠ Nên phối hợp ⚠ đào tạo cho kiến thức, cặp và kèm cho việc áp dụng — liên hệ ba tầng học ở #26184 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có định nghĩa hoàn thành viết ra không | | | Việc không đạt chuẩn là do không biết, không làm nổi, hay không kịp | | | Bạn xử lý ở vòng lặp đầu hay chờ tới lúc dồn thành đống | |

Và điều Heath làm đúng nhất trong tình huống này: anh phản ứng ở vòng lặp thứ nhất — chứ không đợi tới vòng thứ năm rồi mới hỏi vì sao chất lượng kém.

Câu 506 People
You are the project manager for your organization, and you are working with management and several subject matter experts to create the project scope statement. Once the statement is complete, you mention that the key project stakeholders should receive a copy of the project scope statement. Why should the key stakeholders receive a copy of the project scope statement?
  1. A To ensure that all the key stakeholders have a common understanding of the project.
  2. B To ensure that all the key stakeholders have been identified.
  3. C To ensure that the project manager is identified.
  4. D To ensure that all the project team members are accounted for among the functional managers.
Xem giải thích

Đáp án

A — Để bảo đảm mọi bên liên quan chính có CÁCH HIỂU CHUNG về dự án.

Vì sao đúng

⚠ Mô tả phạm vi làm được gì khi chia sẻ: | Tác dụng | Nội dung | |---|---| | ⚠ Mọi người đọc CÙNG MỘT tài liệu | ⚠ nền tảng của hiểu chung | | ⚠ Nêu rõ cái gì TRONG phạm vi và cái gì NGOÀI | ⚠ mục loại trừ ngăn kỳ vọng sai | | ⚠ Có tiêu chí nghiệm thu — biết trước thế nào là xong | | | ⚠ Phát hiện SỚM chỗ hiểu khác nhau | ⚠ rẻ hơn phát hiện lúc bàn giao rất nhiều | | ⚠ Liên hệ trực tiếp | ⚠ #26183 cùng lô — kỳ vọng lệch nhau phải xử lý ở giai đoạn lập kế hoạch |

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

  • B (bảo đảm đã nhận diện hết bên liên quan) — ⚠ phương án gây nhiễu mạnh nhất vì gửi tài liệu ⚠ có thể vô tình lộ ra người bị bỏ sót: ⚠ nhưng đó là ⚠ tác dụng phụ tình cờ; ⚠ nhận diện bên liên quan có quy trình riêng ⚠ (liên hệ #26185 cùng lô), ⚠ không dựa vào việc phát tài liệu.

  • C (bảo đảm quản lý dự án được xác định) — ⚠ việc đó thuộc ĐIỀU LỆ DỰ ÁN, ⚠ không phải mô tả phạm vi ⚠ (liên hệ #26206 cùng lô).

  • D (bảo đảm mọi thành viên đội được các trưởng phòng tính đến) — ⚠ thuộc quản lý nguồn lực, ⚠ không phải mục đích của mô tả phạm vi.

Ghi nhớ

⚠ Đối chiếu — BỘ MÔ TẢ PHẠM VI nay lên BẢY câu: ⚠ #25959, #26005 (bàn giao), ⚠ #25977 (tiêu chí nghiệm thu), ⚠ #25989 (loại trừ), ⚠ #25997, #26007 (mô tả phạm vi sản phẩm), ⚠ và câu này (vì sao chia sẻ). ⚠ Xem thêm #26178 lô 188 (vì sao phải xác định phạm vi kỹ), #26180 lô 188 (kế hoạch quản lý phạm vi).

⚠ BỐN mục của mô tả phạm vi dự án — và mỗi mục ngăn hiểu lầm gì: | Mục | Ngăn hiểu lầm nào | |---|---| | ⚠ MÔ TẢ PHẠM VI SẢN PHẨM | ⚠ "tôi tưởng nó sẽ trông khác cơ" | | ⚠ BÀN GIAO | ⚠ "tôi tưởng có cả tài liệu hướng dẫn" | | ⚠ TIÊU CHÍ NGHIỆM THU | ⚠ "tôi tưởng thế này là chưa đạt" | | ⚠ LOẠI TRỪ | ⚠ "tôi tưởng phần đó cũng nằm trong dự án" | | ⚠ Mục quan trọng nhất cho việc hiểu chung | ⚠ LOẠI TRỪ — vì nó nói ra thứ người ta hay TỰ GIẢ ĐỊNH là có | | ⚠ Liên hệ | ⚠ #25989 lô 185 — mục loại trừ chống trượt phạm vi |

Từ khoá nhận diện:

"vì sao gửi mô tả phạm vi cho bên liên quan" → ⚠ để có cách hiểu chung "nhận diện bên liên quan" → ⚠ quy trình riêng, không phải mục đích ở đây "xác định quản lý dự án" → ⚠ thuộc điều lệ dự án "tính người cho đội" → ⚠ thuộc quản lý nguồn lực

⚠ Gửi tài liệu KHÔNG tự động tạo ra hiểu chung Bước cần thêm
⚠ Gửi rồi HỌP để đi qua các mục chính ⚠ nhất là mục loại trừ
⚠ Mời họ ĐẶT CÂU HỎI, đừng hỏi "có ổn không" ⚠ liên hệ #26221 cùng lô — xác nhận cách hiểu
⚠ Ghi nhận và giải quyết bất đồng NGAY ⚠ liên hệ #26183 cùng lô
⚠ Lấy PHÊ DUYỆT chính thức
⚠ Báo mỗi khi phạm vi thay đổi ⚠ liên hệ #26206 cùng lô — bước hay bị quên nhất
⚠ Nguyên tắc từ mô hình truyền thông ⚠ gửi đi mới là ĐẨY; hiểu chung cần vòng PHẢN HỒI — liên hệ #26192 và #26216 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan chính của bạn đã đọc mô tả phạm vi chưa | ⚠ đã NHẬN khác đã ĐỌC | | Mô tả phạm vi của bạn có mục loại trừ không | | | Có ai đang giả định dự án sẽ giao thứ không nằm trong phạm vi không | |

Và lý do bước tưởng như hình thức này lại đáng giá: mọi tranh cãi tốn kém ở cuối dự án đều bắt đầu từ một giả định mà không ai nói ra ở đầu dự án.

Câu 507 Process
Over lunch with your colleague, Bruce, the topic of iterative development arises. Bruce says iterative development is better than incremental development when a useable delivery is needed early on for a project. Which of the following is true?
  1. A Iterative delivery yields a useable piece of the project in each iteration.
  2. B Iterative development is planned in complete detail in the planning stage, while incremental development plans at a high level and develops the scope more and more over time.
  3. C Incremental development and iterative development mean the same thing and can be used interchangeably.
  4. D Incremental delivery yields a useable piece of the project in each iteration.
Xem giải thích

Đáp án

D — Giao hàng GIA TĂNG mới cho ra một phần DÙNG ĐƯỢC của dự án sau mỗi vòng lặp.

Vì sao đúng

⚠ Bruce nói sai ở đâu: | Bruce nói | Sự thật | |---|---| | ⚠ "Phát triển LẶP tốt hơn GIA TĂNG khi cần bàn giao dùng được sớm" | ⚠ NGƯỢC LẠI | | ⚠ LẶP làm đi làm lại CÙNG một thứ cho tốt dần | ⚠ giữa chừng chưa chắc đã dùng được | | ⚠ GIA TĂNG thêm từng phần HOÀN CHỈNH | ⚠ mỗi phần DÙNG ĐƯỢC ngay | | ⚠ Cần bàn giao dùng được sớm thì chọn GIA TĂNG | ⚠ đúng đáp án D | | ⚠ Ví dụ dễ nhớ | ⚠ LẶP: phác cả bức tranh rồi tô đậm dần. GIA TĂNG: vẽ xong hẳn góc trái rồi sang góc phải |

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

  • A (giao LẶP cho ra phần dùng được sau mỗi vòng) — ⚠ phương án gây nhiễu mạnh nhất vì nó ⚠ chỉ khác đáp án đúng ĐÚNG MỘT TỪ: ⚠ đổi "gia tăng" thành "lặp"; ⚠ đây là bẫy đọc lướt kinh điển — phải đọc kỹ chữ đầu tiên của mỗi phương án.

  • B (lặp lập kế hoạch chi tiết từ đầu, gia tăng lập kế hoạch ở mức cao) — ⚠ MÔ TẢ NGƯỢC; ⚠ và "lập kế hoạch chi tiết từ đầu" là đặc điểm của DỰ ĐOÁN, không phải lặp.

  • C (hai khái niệm giống nhau, dùng thay thế được) — ⚠ SAI: ⚠ chúng khác nhau rõ ràng, ⚠ dù thực tế hay dùng kết hợp.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26195 ở lô này (Peter thêm vật liệu giảm ồn vào máy xay → GIA TĂNG) — ⚠ câu đó ÁP DỤNG, câu này ĐỊNH NGHĨA, khoá NHẤT QUÁN; ⚠ câu #25972 lô 184 (nguyên mẫu là LẶP nhưng đề không có phương án đó), ⚠ câu #26204 ở lô này (chọn agile).

⚠ BẢNG PHÂN BIỆT LẶP và GIA TĂNG — thuộc bảng này là làm được mọi câu về chủ đề: | | LẶP (iterative) | GIA TĂNG (incremental) | |---|---|---| | ⚠ Mục đích | ⚠ làm ĐÚNG dần | ⚠ làm ĐỦ dần | | ⚠ Mỗi vòng cho ra | ⚠ phiên bản tốt hơn của CÙNG thứ | ⚠ một PHẦN MỚI dùng được | | ⚠ Dùng được sớm không | ⚠ KHÔNG chắc | ⚠ CÓ — CÂU NÀY | | ⚠ Hợp khi | ⚠ yêu cầu chưa rõ, cần thử nghiệm | ⚠ yêu cầu rõ, muốn giao giá trị sớm | | ⚠ Rủi ro chính | ⚠ mài mãi không xong | ⚠ các phần ghép lại không khớp | | ⚠ Thực tế | ⚠ agile thường dùng CẢ HAI: lặp để làm đúng, gia tăng để giao sớm | | ⚠ Mẹo nhớ | ⚠ LẶP làm SÂU, GIA TĂNG làm RỘNG |

Từ khoá nhận diện:

"cần bàn giao dùng được sớm" → ⚠ gia tăng "yêu cầu chưa rõ, cần thử và sửa" → ⚠ lặp "hai khái niệm như nhau" → ⚠ sai "lập kế hoạch chi tiết ngay từ đầu" → ⚠ dự đoán, không phải lặp hay gia tăng

⚠ Vì sao cặp khái niệm này bị lẫn nhiều đến vậy Lý do
⚠ Cả hai đều chia công việc thành các vòng ngắn
⚠ Cả hai đều thuộc ô agile
⚠ Trong thực tế chúng luôn đi cùng nhau ⚠ một sprint scrum vừa lặp vừa gia tăng
⚠ Nhiều tài liệu dùng lẫn lộn hai từ này
⚠ Nhưng trong đề thi ⚠ chúng LUÔN được phân biệt rạch ròi — và câu hỏi thường xoáy vào đúng chỗ khác nhau
⚠ Câu hỏi phân biệt nhanh nhất ⚠ "sau vòng này người dùng có dùng được gì chưa?" — có là gia tăng, chưa chắc là lặp

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sau mỗi sprint đội bạn có thứ gì dùng được không | | | Bạn đang làm sâu hay làm rộng ở sprint này | | | Có tính năng nào bị mài đi mài lại nhiều vòng không | ⚠ dấu hiệu lặp quá đà |

Và cách nhớ gọn nhất cho phòng thi: muốn NHANH CÓ THỨ DÙNG ĐƯỢC thì gia tăng; muốn CHẮC LÀ ĐÚNG THỨ CẦN thì lặp — và hầu hết dự án cần cả hai.

Câu 508 Process
Tom is the scrum master for Project M, which is in its second iteration and has a velocity of thirty-five story points. During a recent retrospective, Tom was informed that several servers had shown signs of overheating and were at serious risk of failing during the project. Project M could not continue without these servers. While discussing solutions, one of the team members suggests hosting backup servers with a cloud company. What type of risk response is this?
  1. A Sharing
  2. B Accepting
  3. C Escalating
  4. D Transfer
Xem giải thích

Đáp án

D — CHUYỂN GIAO (transfer).

Vì sao đúng

⚠ Vì sao thuê máy chủ dự phòng ở nhà cung cấp đám mây là chuyển giao: | Đặc điểm | Nội dung | |---|---| | ⚠ Chuyển TRÁCH NHIỆM ứng phó rủi ro sang BÊN THỨ BA | ⚠ định nghĩa của chuyển giao | | ⚠ Nhà cung cấp đám mây chịu trách nhiệm giữ máy chủ hoạt động | | | ⚠ TRẢ TIỀN cho việc đó — phí dịch vụ | ⚠ chuyển giao luôn có giá | | ⚠ Rủi ro KHÔNG BIẾN MẤT, chỉ đổi người gánh | ⚠ điểm mấu chốt | | ⚠ Các dạng chuyển giao khác | ⚠ bảo hiểm, bảo lãnh, hợp đồng giá cố định, thuê ngoài |

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

  • A (chia sẻ — sharing) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất giống việc "cùng làm với nhà cung cấp": ⚠ nhưng ⚠ CHIA SẺ chỉ dùng cho rủi ro TÍCH CỰC (cơ hội) ⚠ — hợp tác với bên khác để cùng nắm bắt cơ hội ⚠ (liên hệ #26164 lô 188); ⚠ máy chủ quá nhiệt là rủi ro TIÊU CỰC.

  • C (leo thang — escalating) — ⚠ dùng khi rủi ro NGOÀI THẨM QUYỀN của dự án, ⚠ phải chuyển lên chương trình hoặc tổ chức; ⚠ ở đây đội tự xử lý được.

  • B (chấp nhận — accepting) — ⚠ là KHÔNG làm gì hoặc chỉ lập dự phòng; ⚠ đội đang chủ động hành động.

Ghi nhớ

⚠ Đối chiếu — nhóm ứng phó rủi ro nay lên MƯỜI LĂM câu: ⚠ #26144 lô 188 (báo rủi ro tích cực cho nhà tài trợ), ⚠ #26147 lô 188 (rủi ro thứ cấp), ⚠ #26164 lô 188 (CHIA SẺ cơ hội), ⚠ #26166 lô 188 (giải phóng dự phòng), ⚠ #26176 lô 188 (hàm hữu dụng), ⚠ #26187 ở lô này (giải pháp tình thế), ⚠ và câu này.

⚠ BẢNG ỨNG PHÓ RỦI RO — tiêu cực và tích cực đối xứng nhau: | Rủi ro TIÊU CỰC (mối đe doạ) | Rủi ro TÍCH CỰC (cơ hội) | |---|---| | ⚠ NÉ TRÁNH — loại bỏ hẳn nguyên nhân | ⚠ KHAI THÁC — bảo đảm cơ hội chắc chắn xảy ra | | ⚠ CHUYỂN GIAO — đẩy sang bên thứ ba | ⚠ CHIA SẺ — hợp tác để cùng nắm cơ hội | | ⚠ GIẢM NHẸ — giảm xác suất hoặc tác động | ⚠ NÂNG CAO — tăng xác suất hoặc tác động | | ⚠ CHẤP NHẬN — sống chung | ⚠ CHẤP NHẬN — không chủ động theo đuổi | | ⚠ LEO THANG — ngoài thẩm quyền dự án | ⚠ LEO THANG — cùng lý do | | ⚠ Mẹo nhớ | ⚠ chuyển giao ↔ chia sẻ là cặp đối xứng; nhầm chúng là lỗi phổ biến nhất của nhóm câu này |

Từ khoá nhận diện:

"thuê bên ngoài, mua bảo hiểm, bảo lãnh" → ⚠ chuyển giao "hợp tác để cùng nắm cơ hội" → ⚠ chia sẻ, chỉ cho rủi ro TÍCH CỰC "ngoài thẩm quyền dự án" → ⚠ leo thang "không làm gì, chỉ lập dự phòng" → ⚠ chấp nhận

⚠ Nhưng cẩn thận — chuyển giao KHÔNG chuyển hết mọi thứ Điều còn lại
⚠ Chuyển được TRÁCH NHIỆM XỬ LÝ và một phần hậu quả tài chính
⚠ KHÔNG chuyển được HẬU QUẢ TỚI DỰ ÁN ⚠ máy chủ đám mây cũng sập thì dự án vẫn dừng
⚠ KHÔNG chuyển được UY TÍN với khách hàng
⚠ SINH RA rủi ro thứ cấp ⚠ phụ thuộc nhà cung cấp, chi phí phát sinh, vấn đề dữ liệu — liên hệ #26147 lô 188
⚠ Việc phải làm sau khi chuyển giao ⚠ ghi rủi ro thứ cấp vào sổ và theo dõi tiếp — chuyển giao không phải là đóng hồ sơ rủi ro
⚠ Tình huống của Tom — vài điểm đáng chú ý Điểm
⚠ Rủi ro được phát hiện ở buổi NHÌN LẠI ⚠ buổi nhìn lại cũng là nơi phát hiện rủi ro, không chỉ cải tiến quy trình
⚠ Giải pháp do MỘT THÀNH VIÊN ĐỘI đề xuất ⚠ đội tự tổ chức đang hoạt động tốt — liên hệ #26197 cùng lô
⚠ "Dự án KHÔNG THỂ tiếp tục nếu thiếu máy chủ" ⚠ tác động rất cao → xứng đáng đầu tư ứng phó
⚠ Việc Tom nên làm tiếp ⚠ ghi vào sổ rủi ro, ước chi phí, xin phê duyệt nếu vượt ngân sách, và giao người phụ trách

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có phân biệt được chuyển giao và chia sẻ không | ⚠ chia sẻ CHỈ dùng cho cơ hội | | Các rủi ro đã chuyển giao của bạn có rủi ro thứ cấp nào không | | | Hạ tầng then chốt của dự án bạn có phương án dự phòng không | |

Và điều dễ quên nhất về chuyển giao rủi ro: bạn mua được người xử lý hậu quả, nhưng không mua được sự bảo đảm rằng hậu quả sẽ không xảy ra.

Câu 509 Process
You are the project manager of a large technical project that will replace equipment for your organization throughout the world. The budget for this project is $1,250,000, and to date, you have spent $702,000 of the project budget. Today, your team reports completing a major milestone in the project marking it 55 percent complete. While this is good news, the project was supposed to be 60 percent complete by this date. However, the stakeholders are still pleased with the progress. Based on this information, what is the planned value for the project work as of today?
  1. A $750,000
  2. B $1,250,000
  3. C $702,000
  4. D $900,200
Xem giải thích

Đáp án

A — 750.000 đô la.

Vì sao đúng

⚠ Tính giá trị kế hoạch (PV): | Bước | Tính | |---|---| | ⚠ Công thức | ⚠ PV = BAC × phần trăm công việc LẼ RA đã xong | | ⚠ BAC (ngân sách khi hoàn thành) | ⚠ 1.250.000 đô | | ⚠ Phần trăm THEO KẾ HOẠCH tới hôm nay | ⚠ 60% | | ⚠ PV | ⚠ 1.250.000 × 0,60 = 750.000 đô | | ⚠ Đáp án | ⚠ A — 750.000 đô |

⚠ Vì sao ba con số kia là bẫy: | Con số | Nó thật ra là gì | |---|---| | ⚠ 1.250.000 | ⚠ BAC — tổng ngân sách, không phải PV tại thời điểm này | | ⚠ 702.000 | ⚠ AC — chi phí THỰC TẾ đã tiêu | | ⚠ 900.200 | ⚠ con số vô nghĩa, không khớp phép tính nào | | ⚠ Nếu đề hỏi EV thay vì PV | ⚠ EV = 1.250.000 × 0,55 = 687.500 đô — dùng phần trăm THỰC TẾ | | ⚠ Ranh giới cần thuộc | ⚠ PV dùng % KẾ HOẠCH; EV dùng % THỰC TẾ; AC là tiền đã chi |

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

  • B (1.250.000) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ PV CÓ BẰNG BAC — nhưng chỉ khi đã tới NGÀY KẾT THÚC theo kế hoạch ⚠ (liên hệ #26159 lô 188, một câu đúng như vậy); ⚠ ở đây dự án ⚠ mới đi được 60% theo kế hoạch, ⚠ chưa tới hạn.

  • C (702.000) — ⚠ đó là AC, không phải PV.

  • D (900.200) — ⚠ không khớp phép tính nào.

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

⚠ ĐÂY LÀ LẦN THỨ BA cùng một kịch bản số liệu xuất hiện — ba lô liên tiếp: | Câu | Lô | Hỏi gì | Đáp án | |---|---|---|---| | ⚠ #26121 | ⚠ lô 187 | ⚠ SV (sai lệch tiến độ) | ⚠ −62.500 đô | | ⚠ #26172 | ⚠ lô 188 | ⚠ CPI (chỉ số hiệu suất chi phí) | ⚠ 0,98 | | ⚠ #26231 — câu này | ⚠ lô 189 | ⚠ PV (giá trị kế hoạch) | ⚠ 750.000 đô | | ⚠ Kịch bản chung | ⚠ BAC 1.250.000; AC 702.000; thực tế 55%; kế hoạch 60% | | | | ⚠ Kiểm tính nhất quán | ⚠ EV = 687.500; PV = 750.000; SV = −62.500 ✓; CPI = 687.500 ÷ 702.000 ≈ 0,98 ✓ — BA KHOÁ HOÀN TOÀN NHẤT QUÁN | | | | ⚠ Bài học về ôn thi | ⚠ hash MD5 không bắt được vì câu hỏi cuối khác nhau; nhưng nhận ra kịch bản lặp thì giải được cả ba trong vài giây |

Ghi nhớ

⚠ BẢNG CÔNG THỨC EVM — thuộc bảng này là làm được mọi câu tính toán: | Ký hiệu | Công thức | Ý nghĩa | |---|---|---| | ⚠ PV | ⚠ BAC × % KẾ HOẠCH | ⚠ lẽ ra đã làm được bao nhiêu giá trị — CÂU NÀY | | ⚠ EV | ⚠ BAC × % THỰC TẾ | ⚠ thực tế đã làm được bao nhiêu giá trị | | ⚠ AC | ⚠ tiền đã chi thật | ⚠ đề luôn cho sẵn | | ⚠ SV | ⚠ EV − PV | ⚠ âm là chậm tiến độ | | ⚠ CV | ⚠ EV − AC | ⚠ âm là vượt chi | | ⚠ SPI | ⚠ EV ÷ PV | ⚠ dưới 1 là chậm | | ⚠ CPI | ⚠ EV ÷ AC | ⚠ dưới 1 là vượt chi | | ⚠ EAC | ⚠ BAC ÷ CPI | ⚠ dự báo tổng chi phí cuối cùng | | ⚠ ETC | ⚠ EAC − AC | ⚠ còn cần bao nhiêu nữa | | ⚠ Mẹo nhớ | ⚠ EV đứng ĐẦU cả bốn công thức SV, CV, SPI, CPI — nhớ điều này là không bao giờ lẫn dấu |

⚠ Tình hình dự án này ra sao — tính đủ cho trọn bộ: | Chỉ số | Giá trị | Kết luận | |---|---|---| | ⚠ PV | ⚠ 750.000 | | | ⚠ EV | ⚠ 687.500 | | | ⚠ AC | ⚠ 702.000 | | | ⚠ SV | ⚠ −62.500 | ⚠ CHẬM tiến độ | | ⚠ CV | ⚠ −14.500 | ⚠ VƯỢT chi nhẹ | | ⚠ SPI | ⚠ 0,92 | ⚠ làm được 92% khối lượng lẽ ra phải xong | | ⚠ CPI | ⚠ 0,98 | ⚠ mỗi đồng bỏ ra thu về 0,98 đồng giá trị | | ⚠ EAC | ⚠ ≈ 1.276.400 | ⚠ dự báo vượt ngân sách khoảng 26.400 đô | | ⚠ Nhận xét về đề | ⚠ đề nói "bên liên quan vẫn hài lòng" — chi tiết này KHÔNG ảnh hưởng phép tính, chỉ để gây nhiễu |

Từ khoá nhận diện:

"giá trị kế hoạch, PV" → ⚠ BAC × % kế hoạch "giá trị thu được, EV" → ⚠ BAC × % thực tế "đã chi bao nhiêu" → ⚠ AC, đề cho sẵn "PV = BAC" → ⚠ chỉ đúng khi đã tới ngày kết thúc theo kế hoạch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có phân biệt được % kế hoạch và % thực tế không | ⚠ đây là chỗ sai nhiều nhất | | Dự án bạn có tính EV không | ⚠ không có EV thì không đo được hiệu suất | | CPI và SPI của bạn tháng này so tháng trước thế nào | |

Và điều đáng nhớ nhất khi gặp một đề EVM: đọc kỹ xem đề hỏi % KẾ HOẠCH hay % THỰC TẾ — chỉ một chữ đó thôi đã tách 750.000 khỏi 687.500.

Câu 510 People
Marilyn is moving to a small private room near her team for the latter part of the afternoon to focus on a challenging part of her development work in a quiet environment. Her scrum master tells her
  1. A That she is welcome to use this as her space throughout the project if she would like
  2. B That she should not be isolating herself from the rest of the team like this
  3. C Nothing, as they have intentionally set up the team's cave for this purpose
  4. D That the team's cave is only to be used for private conversations
Xem giải thích

Đáp án

C — KHÔNG NÓI GÌ CẢ, vì đội đã CỐ Ý dựng ra "hang của đội" đúng cho mục đích này.

Vì sao đúng

⚠ "Hang của đội" (team cave) là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Không gian YÊN TĨNH gần khu làm việc chung | | | ⚠ Dành cho công việc cần TẬP TRUNG SÂU | ⚠ đúng điều Marilyn đang làm | | ⚠ Là phần BỔ SUNG cho không gian mở, không thay thế nó | | | ⚠ Marilyn dùng đúng mục đích, đúng cách, trong một buổi chiều | | | ⚠ Vì thế | ⚠ Scrum Master không cần nói gì — hệ thống đang vận hành đúng như thiết kế |

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

  • B (nói rằng cô không nên tự cô lập khỏi đội như vậy) — ⚠ phương án gây nhiễu mạnh nhất vì agile ⚠ quả thật đề cao đồng địa điểm và giao tiếp mặt đối mặt: ⚠ nhưng ⚠ hiểu điều đó thành "không bao giờ được ở một mình" là hiểu cực đoan; ⚠ và ⚠ hang của đội được dựng RA CHÍNH XÁC cho việc này.

  • A (mời cô dùng chỗ này suốt dự án) — ⚠ SAI ở chỗ "suốt dự án": ⚠ hang là không gian ⚠ DÙNG CHUNG, dùng theo nhu cầu, ⚠ không phải phòng riêng của một người.

  • D (hang chỉ dùng cho trao đổi riêng tư) — ⚠ SAI mục đích: ⚠ hang dùng cho ⚠ cả làm việc tập trung lẫn trao đổi riêng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26189 ở lô này (đồng địa điểm hợp tác trong IPD), ⚠ câu #26213 ở lô này (lập trình cặp), ⚠ câu #26214 ở lô này (đội ảo), ⚠ câu #26221 ở lô này (đội ở xa). ⚠ Nhóm không gian và cách làm việc của đội.

⚠ Không gian làm việc của đội agile cần cả hai kiểu: | Kiểu không gian | Dùng cho | Tên gọi | |---|---|---| | ⚠ KHÔNG GIAN CHUNG mở | ⚠ trao đổi nhanh, phối hợp, lập trình cặp | ⚠ "phòng lớn" (big room / caves and commons) | | ⚠ KHÔNG GIAN YÊN TĨNH | ⚠ làm việc cần tập trung sâu | ⚠ "hang" (cave) — CÂU NÀY | | ⚠ Không gian TRỰC QUAN | ⚠ bảng thông tin, bảng Kanban | ⚠ liên hệ #26208 cùng lô | | ⚠ Mô hình gốc | ⚠ "CAVES AND COMMONS" — hang và sân chung, cả hai đều cần | | ⚠ Sai lầm phổ biến của văn phòng mở | ⚠ chỉ có sân chung mà không có hang — công việc cần tập trung bị cắt vụn liên tục |

Từ khoá nhận diện:

"vào phòng yên tĩnh gần đội để tập trung" → ⚠ dùng hang đúng mục đích "không nên tự cô lập" → ⚠ hiểu cực đoan về đồng địa điểm "dùng suốt dự án" → ⚠ hang là không gian dùng chung, không phải phòng riêng "chỉ để nói chuyện riêng" → ⚠ thu hẹp sai mục đích

⚠ Vì sao công việc cần tập trung sâu quan trọng với đội phát triển Lý do
⚠ Bị ngắt quãng một lần cần khoảng 15–20 phút mới lấy lại nhịp
⚠ Phần khó nhất của công việc cần thời gian liên tục dài
⚠ Văn phòng mở hoàn toàn khiến ngắt quãng xảy ra liên tục
⚠ Chất lượng giảm khi phải làm việc khó trong môi trường ồn ⚠ liên hệ #26227 cùng lô
⚠ Cân bằng đúng ⚠ agile cần giao tiếp CAO, nhưng KHÔNG có nghĩa là giao tiếp LIÊN TỤC
⚠ Scrum Master nên lo lắng khi nào Dấu hiệu đáng chú ý
⚠ Khi một người TRÁNH đội thường xuyên, không chỉ khi cần tập trung
⚠ Khi họ không dự họp đứng hay các sự kiện chung
⚠ Khi việc họ làm không ai biết tiến độ ra sao
⚠ Khi việc rút lui đi kèm dấu hiệu xung đột trong đội
⚠ Nhưng trong tình huống này ⚠ Marilyn chỉ dùng một buổi chiều, cho một phần việc khó, ở phòng NGAY GẦN đội — không có dấu hiệu nào ở trên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có chỗ yên tĩnh để làm việc khó không | | | Có ai đang phải đeo tai nghe cả ngày để tập trung không | ⚠ dấu hiệu thiếu hang | | Bạn có phân biệt được "tập trung" với "rút lui" không | |

Và điều câu này nhắc khéo về agile: đồng địa điểm là để giao tiếp DỄ HƠN, không phải để giao tiếp KHÔNG NGỪNG — và một đội trưởng thành biết khi nào cần ở gần nhau, khi nào cần yên tĩnh.