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

Tìm thấy 720 câu.

Câu 111 Process
Koji is hosting a retrospective meeting for his team and is reviewing the outcomes of their first and second sprints. He quickly notices that the team performs sprint goals, communicates effectively, but the sprint review meetings take much longer to get through, and the team struggles to hand off the product increment on time. He is surprised by this as the project team, stakeholders, and sponsors met at the project's launch and created a comprehensive and extensive list for Definition of Done (DoD). There should be no room for misunderstandings. The primary source for the cause of the delay is attributed to which of the following?
  1. A DoD list is missing critical components.
  2. B DoD list is too long.
  3. C DoD list is incomplete.
  4. D DoD list was not authorized.
Xem giải thích

Đáp án

B — Danh sách Definition of Done QUÁ DÀI.

Vì sao đúng

⚠ Bóc tách triệu chứng: | Triệu chứng | Suy ra | |---|---| | ⚠ Đội ĐẠT được mục tiêu sprint | ⚠ năng lực không phải vấn đề | | ⚠ Giao tiếp HIỆU QUẢ | ⚠ giao tiếp không phải vấn đề | | ⚠ Buổi sprint review kéo dài LÂU HƠN nhiều | ⚠ có quá nhiều thứ phải rà soát | | ⚠ Chậm bàn giao product increment | | | ⚠ DoD được lập "TOÀN DIỆN và RẤT ĐẦY ĐỦ" | ⚠ manh mối quyết định | | ⚠ Kết luận | ⚠ danh sách quá dài nên mỗi lần kiểm tra tốn quá nhiều thời gian |

⚠ Vì sao DoD quá dài lại gây hại: | Hại | Nội dung | |---|---| | ⚠ Mỗi hạng mục phải kiểm quá nhiều tiêu chí | | | ⚠ Buổi review biến thành buổi ĐỐI CHIẾU DANH SÁCH | ⚠ thay vì bàn về giá trị sản phẩm | | ⚠ Nhiều tiêu chí KHÔNG áp dụng được cho mọi hạng mục | | | ⚠ Đội mất thời gian vào thủ tục thay vì vào sản phẩm | | | ⚠ Nghịch lý | ⚠ DoD sinh ra để đảm bảo chất lượng, nhưng quá dài thì lại cản trở việc giao hàng |

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

  • A (thiếu thành phần quan trọng) và C (chưa đầy đủ) — ⚠ NGƯỢC với dữ kiện: ⚠ đề nói rõ danh sách ⚠ "toàn diện và rất đầy đủ"; ⚠ thiếu sót sẽ gây LỖI LỌT LƯỚI, không gây CHẬM REVIEW.

  • D (chưa được phê duyệt) — ⚠ SAI: ⚠ đề nói đội, bên liên quan và nhà tài trợ ⚠ cùng lập danh sách ở buổi khởi động — tức là đã có sự đồng thuận.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25832 ở lô 181 (DoD ở mức "được chấp nhận"), câu #25790 (story done-done), và câu #25786 ở lô 181 (DoD quá thấp gây lãng phí). ⚠ Bốn câu cho thấy DoD phải ở mức VỪA PHẢI — quá thấp thì lọt lỗi, quá cao thì tắc nghẽn.

⚠ Một DoD tốt trông thế nào: | Đặc điểm | Nội dung | |---|---| | ⚠ NGẮN GỌN, thường 5–10 mục | | | ⚠ Mỗi mục ÁP DỤNG ĐƯỢC cho mọi hạng mục | | | ⚠ Kiểm tra được NHANH, có/không rõ ràng | | | ⚠ Tập trung vào thứ THẬT SỰ quan trọng | | | ⚠ Được RÀ SOÁT và điều chỉnh định kỳ | ⚠ trong retrospective | | ⚠ Ví dụ mục hợp lý | ⚠ mã đã rà soát, kiểm thử đơn vị đạt, đã tích hợp, không lỗi nghiêm trọng, product owner chấp nhận |

Từ khoá nhận diện:

"review kéo dài, chậm bàn giao, DoD rất đầy đủ" → ⚠ DoD quá dài "lỗi lọt ra vận hành" → ⚠ DoD quá ngắn hoặc thiếu mục quan trọng "mỗi người hiểu xong khác nhau" → ⚠ DoD chưa rõ ràng "đánh dấu hoàn thành trước khi kiểm thử" → ⚠ DoD quá thấp

⚠ Koji nên làm gì Bước
⚠ Đưa vấn đề ra RETROSPECTIVE để đội cùng bàn ⚠ DoD do đội sở hữu, đội phải cùng sửa
⚠ Rà từng mục: mục nào THẬT SỰ cần cho mọi hạng mục
⚠ Tách mục chỉ áp dụng cho một số loại việc ra khỏi DoD chung
⚠ Tự động hoá việc kiểm tra những mục kiểm được bằng máy ⚠ kiểm thử tự động, phân tích mã tĩnh
⚠ Kiểm DoD LIÊN TỤC trong sprint, không dồn vào buổi review ⚠ giải pháp hiệu quả nhất
⚠ Đừng ⚠ tự ý cắt DoD mà không có sự đồng thuận — bên liên quan đã tham gia lập nó
⚠ Nguyên tắc cân bằng của DoD Nguyên tắc
⚠ Đủ CHẶT để increment thật sự bàn giao được
⚠ Đủ NGẮN để không cản trở dòng chảy công việc
⚠ Nâng dần khi đội trưởng thành và có công cụ tự động
⚠ Dấu hiệu cần xem lại ⚠ kiểm tra DoD tốn nhiều thời gian hơn làm việc

Ba việc kiểm chứng: | Việc | Cách | |---|---| | DoD của đội bạn có bao nhiêu mục | | | Có mục nào không áp dụng được cho mọi hạng mục không | | | Việc kiểm DoD diễn ra liên tục hay dồn vào cuối sprint | ⚠ dồn vào cuối là nguyên nhân chính gây tắc |

Và bài học ngược đời từ tình huống này: thứ được lập ra để bảo đảm chất lượng lại đang cản trở việc giao hàng. Toàn diện không phải lúc nào cũng tốt — vừa đủ mới là tốt.

Câu 112 People
Twila is the scrum master for Project D, which is 6 iterations into deployment and has a velocity of 65 story points. During a recent retrospective, her team discovered they are missing critical skills to complete Project D and would like to call in a vendor for support. What should Twila do next?
  1. A Draft a statement of work.
  2. B Determine exactly what work would be contracted out.
  3. C Escalate the issue to the steering committee.
  4. D Hold a bidders conference.
Xem giải thích

Đáp án

B — XÁC ĐỊNH CHÍNH XÁC phần việc nào sẽ được thuê ngoài.

Vì sao đúng

⚠ Vì sao phải xác định phạm vi trước: | Lý do | Nội dung | |---|---| | ⚠ KHÔNG biết thuê cái gì thì không viết được SOW | | | ⚠ Không biết thuê cái gì thì không mời thầu được | | | ⚠ Phạm vi mơ hồ dẫn tới hợp đồng mơ hồ và tranh chấp | | | ⚠ Đây là bước ĐẦU TIÊN của Plan Procurement Management | | | ⚠ Kết luận | ⚠ quyết định LÀM HAY MUA và xác định ranh giới phần thuê ngoài phải có trước mọi bước khác |

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

  • A (soạn tuyên bố công việc — SOW) — ⚠ phương án gây nhiễu MẠNH NHẤT: ⚠ SOW là bước ĐÚNG nhưng ⚠ PHẢI SAU khi đã xác định rõ thuê phần nào; ⚠ không có phạm vi thì SOW viết gì?

  • D (tổ chức hội nghị nhà thầu) — ⚠ bước MUỘN HƠN NHIỀU: ⚠ diễn ra sau khi đã phát hành tài liệu mời thầu.

  • C (leo thang lên ban chỉ đạo) — ⚠ quá sớm: ⚠ đội mới xác định nhu cầu, chưa có phương án cụ thể để trình.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25677 ở lô 178 (IFB và SOW), câu #25679 (hội nghị nhà thầu), và câu #25733 ở lô 180 (chọn loại hợp đồng). ⚠ Bốn câu vẽ đủ chuỗi mua sắm — câu này là bước ĐẦU TIÊN của chuỗi đó.

⚠ Chuỗi mua sắm theo đúng thứ tự: | Bước | Việc | |---|---| | ⚠ 1. Phân tích LÀM HAY MUA | ⚠ make-or-buy analysis | | ⚠ 2. XÁC ĐỊNH chính xác phần việc thuê ngoài | ⚠ BƯỚC CỦA CÂU NÀY | | ⚠ 3. Soạn PROCUREMENT SOW | ⚠ phương án A là bước này | | ⚠ 4. Chọn LOẠI HỢP ĐỒNG phù hợp | | | ⚠ 5. Xác định TIÊU CHÍ chọn nhà cung cấp | | | ⚠ 6. Phát hành tài liệu mời thầu | ⚠ IFB, RFP hoặc RFQ | | ⚠ 7. Tổ chức HỘI NGHỊ NHÀ THẦU | ⚠ phương án D là bước này | | ⚠ 8. Nhận và chấm hồ sơ | | | ⚠ 9. Đàm phán và ký hợp đồng | |

Từ khoá nhận diện:

"bước TIẾP THEO khi mới nhận ra cần thuê ngoài" → ⚠ xác định phạm vi thuê ngoài "soạn SOW" → ⚠ bước sau khi đã biết thuê gì "hội nghị nhà thầu" → ⚠ bước rất muộn trong chuỗi "leo thang" → ⚠ chỉ khi vượt thẩm quyền và đã có phương án

⚠ Xác định phạm vi thuê ngoài gồm những gì Nội dung
⚠ Chính xác KỸ NĂNG nào đội đang thiếu
⚠ Phần việc nào cần kỹ năng đó
⚠ RANH GIỚI: đâu là việc của nhà cung cấp, đâu là việc của đội
⚠ Điểm giao tiếp và bàn giao giữa hai bên
⚠ Thời lượng và khối lượng dự kiến
⚠ Tiêu chí nghiệm thu
⚠ Với dự án agile ⚠ nên xác định theo hạng mục backlog cụ thể để dễ đo
⚠ Lưu ý riêng khi thuê ngoài trong dự án agile Lưu ý
⚠ Phạm vi trong agile CỐ Ý để mở ⚠ khó ký hợp đồng giá cố định
⚠ T&M thường phù hợp hơn ⚠ xem câu #25765 ở lô 180
⚠ Nhà cung cấp phải hoà nhập vào đội ⚠ phổ biến quy tắc nền — xem câu #25809 ở lô 181
⚠ Velocity sẽ giảm tạm thời khi có người mới
⚠ Twila cần lưu ý ⚠ đội đang chạy ổn định ở 65 điểm — thêm người ngoài sẽ làm xáo trộn trong ngắn hạn
⚠ Trước khi thuê ngoài, cân nhắc thêm Phương án
⚠ ĐÀO TẠO đội hiện tại ⚠ nếu còn đủ thời gian — xem câu #25776 ở lô 180
⚠ Mượn người từ đội khác trong tổ chức
⚠ Điều chỉnh phạm vi để tránh phần cần kỹ năng đó
⚠ Thuê ngoài ⚠ là một trong nhiều phương án, không phải phương án duy nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có mô tả được chính xác phần việc cần thuê không | ⚠ không mô tả được thì chưa sẵn sàng viết SOW | | Ranh giới trách nhiệm giữa đội và nhà cung cấp có rõ không | | | Đã cân nhắc phương án thay thế chưa | |

Và nguyên tắc mua sắm gọn nhất: biết mình cần gì trước khi hỏi người khác giá bao nhiêu. Mọi bước sau đều đứng trên câu trả lời của bước này.

Câu 113 People
Russell has managed a project from beginning to end. As he is close to closing the project, he looks at the business case, project charter and other plan documents. He is amazed at how smoothly the project went and how the project team met every expectation laid out in the project documents. Those close to the project view it as a huge success. Yet company shareholders and many in the public view the project as a failure or letdown. What is the culprit with these disparate viewpoints on the project?
  1. A The project did not deliver the expected quality.
  2. B Russell misread the plan documents.
  3. C A misunderstanding about what the project was.
  4. D Russell is overestimating his performance.
Xem giải thích

Đáp án

C — Có sự HIỂU NHẦM về việc dự án THẬT SỰ LÀ GÌ.

Vì sao đúng

⚠ Bóc tách nghịch lý: | Nhóm | Đánh giá | Căn cứ | |---|---|---| | ⚠ Đội dự án và người trong cuộc | ⚠ THÀNH CÔNG lớn | ⚠ đạt mọi kỳ vọng trong business case, điều lệ, kế hoạch | | ⚠ Cổ đông và công chúng | ⚠ THẤT BẠI hoặc đáng thất vọng | ⚠ kỳ vọng của họ khác với những gì tài liệu ghi | | ⚠ Nguyên nhân | ⚠ hai nhóm hiểu KHÁC NHAU về mục tiêu và phạm vi của dự án |

⚠ Vì sao sự hiểu nhầm này xảy ra: | Nguyên nhân | Nội dung | |---|---| | ⚠ Cổ đông và công chúng KHÔNG tham gia lập kế hoạch | | | ⚠ Họ hình thành KỲ VỌNG RIÊNG từ tin đồn, truyền thông, suy đoán | | | ⚠ Không ai chủ động truyền đạt phạm vi thật cho họ | | | ⚠ Có thể tổ chức đã hứa hẹn quá mức bên ngoài | | | ⚠ Kết luận | ⚠ đây là thất bại về QUẢN LÝ BÊN LIÊN QUAN và GIAO TIẾP, không phải về thực thi |

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

  • A (dự án không đạt chất lượng mong đợi) — ⚠ NGƯỢC với dữ kiện: ⚠ đội đạt MỌI kỳ vọng ghi trong tài liệu.

  • B (Russell đọc nhầm tài liệu kế hoạch) — ⚠ không có căn cứ: ⚠ dự án chạy đúng theo tài liệu.

  • D (Russell đánh giá quá cao bản thân) — ⚠ không phải nguyên nhân: ⚠ ⚠ những người khác gần dự án cũng coi đây là thành công lớn, không riêng Russell.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25738 ở lô 180 (giao nhanh nhưng có thể lệch lợi ích đã hứa), câu #25777 (sự hài lòng khách hàng không định lượng được), và câu #25726 ở lô 179 (bên liên quan bực dù dự án đúng tiến độ). ⚠ Bốn câu cùng một bài học: thành công của dự án được ĐÁNH GIÁ bởi bên liên quan, không chỉ bởi tài liệu.

⚠ Ba mức "thành công" của một dự án: | Mức | Đo bằng gì | Ai đánh giá | |---|---|---| | ⚠ Thành công về THỰC THI | ⚠ đúng phạm vi, đúng hạn, đúng ngân sách, đạt chất lượng | ⚠ đội và PM | | ⚠ Thành công về SẢN PHẨM | ⚠ sản phẩm dùng được và được chấp nhận | ⚠ khách hàng và người dùng | | ⚠ Thành công về LỢI ÍCH KINH DOANH | ⚠ mang lại giá trị đã hứa cho tổ chức | ⚠ nhà tài trợ, CỔ ĐÔNG, công chúng | | ⚠ Dự án của Russell | ⚠ thành công ở mức 1, nhưng thất bại ở mức 3 trong mắt cổ đông |

Từ khoá nhận diện:

"đội thấy thành công, bên ngoài thấy thất bại" → ⚠ hiểu nhầm về mục tiêu và phạm vi "đạt mọi tiêu chí trong tài liệu" → ⚠ thành công về thực thi "cổ đông và công chúng thất vọng" → ⚠ kỳ vọng chưa được quản lý "bên liên quan không tham gia lập kế hoạch" → ⚠ nguồn gốc của hiểu nhầm

⚠ Lẽ ra Russell nên làm gì từ đầu Việc
⚠ NHẬN DIỆN đầy đủ bên liên quan, kể cả cổ đông và công chúng ⚠ họ là bên liên quan BÊN NGOÀI
⚠ Ghi kỳ vọng của họ vào sổ đăng ký bên liên quan
⚠ Lập kế hoạch giao tiếp cho nhóm bên ngoài
⚠ Truyền đạt rõ dự án LÀM GÌ và KHÔNG LÀM GÌ ⚠ đặc biệt quan trọng khi có kỳ vọng công chúng
⚠ Điều chỉnh kỳ vọng SỚM khi phát hiện lệch
⚠ Liên hệ ⚠ xem câu #25689 ở lô 179 về hướng ảnh hưởng OUTWARD — nhóm bên ngoài dự án
⚠ Vì sao "phạm vi KHÔNG làm" lại quan trọng Lý do
⚠ Kỳ vọng thường hình thành từ khoảng TRỐNG thông tin
⚠ Nói rõ cái KHÔNG làm cũng quan trọng như nói cái sẽ làm ⚠ exclusions trong scope statement
⚠ Nhóm "WON'T have" trong MoSCoW phục vụ đúng mục đích này ⚠ xem câu #25762 ở lô 180
⚠ Bài học ⚠ im lặng về giới hạn là để mặc người khác tự tưởng tượng
⚠ Russell nên làm gì BÂY GIỜ Việc
⚠ Ghi bài học kinh nghiệm về việc quản lý kỳ vọng bên ngoài
⚠ Trong báo cáo cuối, nêu rõ dự án đạt gì so với mục tiêu ban đầu
⚠ Phối hợp với truyền thông để làm rõ với công chúng
⚠ Đừng ⚠ coi phản hồi tiêu cực là không đáng quan tâm chỉ vì "chúng ta làm đúng tài liệu"

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Sổ bên liên quan của bạn có nhóm BÊN NGOÀI không | ⚠ cổ đông, công chúng, cơ quan quản lý | | Họ có biết dự án làm gì và không làm gì không | | | Có ai theo dõi kỳ vọng của họ suốt dự án không | |

Và điều đau nhất của tình huống này: dự án làm đúng mọi thứ được ghi ra, nhưng thất bại ở thứ không ai ghi. Kỳ vọng chưa được viết xuống vẫn là kỳ vọng thật.

Câu 114 Process
As a project manager for her organization Raquel is leading a technical installation project. In this strong matrix structure, her organization is using decentralized contracting. The project management office has instructed Raquel only to arrange contracts with vendors that pose a low risk for her firm. What type of contract should Raquel use?
  1. A Time and materials contract
  2. B Fixed-price contract
  3. C Cost contract
  4. D Cost-reimbursable contract
Xem giải thích

Đáp án

B — Fixed-price contract (hợp đồng giá cố định).

Vì sao đúng

⚠ Vì sao giá cố định là rủi ro thấp cho người mua: | Lý do | Nội dung | |---|---| | ⚠ GIÁ ĐÃ CHỐT — biết trước phải trả bao nhiêu | | | ⚠ Rủi ro CHI PHÍ VƯỢT thuộc về NHÀ CUNG CẤP | ⚠ họ làm tốn hơn dự tính thì họ chịu | | ⚠ Người mua không phải theo dõi chi phí thực tế của nhà thầu | | | ⚠ Đơn giản về mặt quản trị hợp đồng | | | ⚠ Bối cảnh phù hợp | ⚠ "lắp đặt kỹ thuật" — phạm vi rõ ràng, đủ điều kiện để chốt giá |

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

  • D (Cost-reimbursable) và C (Cost contract) — ⚠ rủi ro chi phí thuộc về NGƯỜI MUA: ⚠ nhà cung cấp chi bao nhiêu thì được hoàn bấy nhiêu, ⚠ tổng chi phí không biết trước.

  • A (Time and materials) — ⚠ cũng đặt rủi ro chi phí lên NGƯỜI MUA: ⚠ càng lâu càng tốn; ⚠ phù hợp với việc nhỏ và gấp, không phù hợp khi mục tiêu là giảm rủi ro.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25733 ở lô 180 (chọn T&M vì việc gấp và ngắn) và câu #25765 ở lô 180 (nhận diện T&M từ hoá đơn). ⚠ Ba câu cùng chủ đề chọn loại hợp đồng — và cho thấy KHÔNG có loại nào luôn đúng: tuỳ mục tiêu ưu tiên.

⚠ Ba loại hợp đồng — ai chịu rủi ro chi phí: | Loại | Rủi ro chi phí thuộc về | Dùng khi | |---|---|---| | ⚠ Fixed Price (FP) | ⚠ NHÀ CUNG CẤP | ⚠ phạm vi rõ, muốn RỦI RO THẤP cho mình — CÂU NÀY | | ⚠ Cost Reimbursable (CR) | ⚠ NGƯỜI MUA | ⚠ phạm vi chưa rõ, nghiên cứu phát triển | | ⚠ Time & Material (T&M) | ⚠ NGƯỜI MUA | ⚠ việc nhỏ, gấp, bổ sung nhân lực | | ⚠ Nguyên tắc | ⚠ rủi ro và giá đi cùng nhau — nhà cung cấp gánh rủi ro thì họ tính giá cao hơn |

⚠ So sánh với câu #25733: | Câu | Mục tiêu ưu tiên | Khoá | |---|---|---| | ⚠ #25733 (lô 180) | ⚠ TỐC ĐỘ — phải bắt đầu ngay trước mùa bão | ⚠ T&M | | ⚠ #25836 (câu này) | ⚠ RỦI RO THẤP cho công ty | ⚠ Fixed Price | | ⚠ Bài học | ⚠ loại hợp đồng chọn theo MỤC TIÊU ƯU TIÊN, không có loại nào tốt nhất tuyệt đối |

Từ khoá nhận diện:

"rủi ro thấp cho tổ chức mình" → ⚠ fixed price "cần bắt đầu ngay, việc nhỏ" → ⚠ T&M "phạm vi chưa rõ, nghiên cứu" → ⚠ cost reimbursable "phạm vi rất rõ, chỉ so giá" → ⚠ fixed price, mời thầu bằng IFB

⚠ Điều kiện để dùng được hợp đồng giá cố định Điều kiện
⚠ PHẠM VI phải RẤT RÕ RÀNG ⚠ điều kiện quan trọng nhất
⚠ Đặc tả kỹ thuật đầy đủ và không mơ hồ
⚠ Ít khả năng thay đổi giữa chừng
⚠ Có thời gian để đàm phán và mời thầu
⚠ Nếu phạm vi chưa rõ mà vẫn ký giá cố định ⚠ nhà thầu sẽ tính giá rất cao để phòng rủi ro, hoặc sẽ tranh chấp liên tục về phạm vi
⚠ Mặt trái của hợp đồng giá cố định Mặt trái
⚠ Nhà cung cấp cộng thêm PHÍ RỦI RO vào giá ⚠ rủi ro thấp không đồng nghĩa với chi phí thấp
⚠ Mọi thay đổi phạm vi đều ĐẮT ⚠ nhà thầu có đòn bẩy đàm phán
⚠ Nhà thầu có động cơ cắt góc để tăng lợi nhuận ⚠ phải kiểm soát chất lượng chặt
⚠ Liên hệ ⚠ xem câu #25739 ở lô 180 — hợp đồng giá cố định thúc đẩy value engineering nhưng cũng dễ trượt sang cắt chất lượng
⚠ Bối cảnh "hợp đồng phi tập trung" nghĩa là gì Nghĩa
⚠ Quản lý dự án TỰ đàm phán và ký hợp đồng
⚠ Không qua một bộ phận mua sắm tập trung
⚠ Nhanh hơn nhưng đòi PM phải hiểu về hợp đồng
⚠ Vì thế ⚠ hướng dẫn của PMO về việc chỉ ký hợp đồng rủi ro thấp là biện pháp kiểm soát hợp lý

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Phạm vi có đủ rõ để chốt giá không | | | Bạn ưu tiên điều gì: chi phí chắc chắn, tốc độ, hay linh hoạt | | | Nếu phạm vi đổi thì chi phí thay đổi ra sao | |

Và nguyên tắc chọn hợp đồng: ai chịu rủi ro thì người đó tính tiền cho rủi ro đó. Muốn rủi ro thấp thì phải chấp nhận trả giá cao hơn — đó là đánh đổi, không phải bữa trưa miễn phí.

Câu 115 People
Bonsai Kitten's Business Analyst, Jessica, primarily utilizes the most efficient and effective means of communication with her collaborative development team, which is
  1. A A daily 15-minute standup phone meeting
  2. B She has regular face-to-face conversations regarding questions and issues the developers face.
  3. C Regularly updates relevant documentation as minimal as possible to get the job done and just in time for the developers' needs.
  4. D Regularly using an award-winning team collaboration tool.
Xem giải thích

Đáp án

B — Cô ấy thường xuyên TRÒ CHUYỆN TRỰC TIẾP về các câu hỏi và vấn đề mà lập trình viên gặp phải.

Vì sao đúng

⚠ Nguyên tắc thứ sáu của Tuyên ngôn Agile:

⚠ "Phương pháp truyền đạt thông tin HIỆU QUẢ và HIỆU SUẤT nhất tới và trong nội bộ đội phát triển là TRÒ CHUYỆN TRỰC TIẾP."

Lý do Nội dung
⚠ Phản hồi TỨC THÌ — hỏi và đáp ngay
⚠ Có đủ NGÔN NGỮ CƠ THỂ và ngữ điệu
⚠ Làm rõ hiểu nhầm NGAY tại chỗ
⚠ Không tốn công viết và không bị hiểu lệch
⚠ Đề nói rõ ⚠ "hiệu quả và hiệu suất nhất" — đúng cách diễn đạt của tuyên ngôn

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

  • A (họp đứng 15 phút hằng ngày qua ĐIỆN THOẠI) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ standup là thực hành tốt, ⚠ nhưng qua điện thoại thì mất hình ảnh; ⚠ và standup là để ĐỒNG BỘ, không phải để giải quyết mọi câu hỏi kỹ thuật.

  • C (cập nhật tài liệu ở mức tối thiểu, vừa đủ và đúng lúc) — ⚠ thực hành TỐT của agile (tài liệu vừa đủ), ⚠ nhưng tài liệu vẫn là giao tiếp một chiều — không phải cách hiệu quả nhất.

  • D (dùng công cụ cộng tác đoạt giải) — ⚠ công cụ là phương tiện, ⚠ và tuyên ngôn nói rõ ⚠ "cá nhân và tương tác HƠN quy trình và công cụ".

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25784 ở lô 181 (hội nghị truyền hình là công cụ tốt nhất cho đội ẢO) và câu #25821 (sắp xếp gặp mặt trực tiếp ở thời điểm then chốt). ⚠ Ba câu nhất quán: gặp trực tiếp là tốt nhất; khi không gặp được thì video là lựa chọn gần nhất.

⚠ Mười hai nguyên tắc của Tuyên ngôn Agile — vài nguyên tắc hay ra thi: | Nguyên tắc | Nội dung | |---|---| | ⚠ Ưu tiên cao nhất | ⚠ làm hài lòng khách hàng qua việc giao phần mềm có giá trị sớm và liên tục | | ⚠ Đón nhận thay đổi | ⚠ kể cả muộn trong quá trình phát triển | | ⚠ Giao hàng thường xuyên | ⚠ vài tuần tới vài tháng, càng ngắn càng tốt | | ⚠ TRÒ CHUYỆN TRỰC TIẾP | ⚠ cách truyền đạt hiệu quả nhất — CÂU NÀY | | ⚠ Phần mềm chạy được là thước đo tiến độ chính | ⚠ xem câu #25772 ở lô 180 | | ⚠ Nhịp làm việc bền vững | ⚠ xem câu #25612 ở lô 177 | | ⚠ Đội tự tổ chức | | | ⚠ Nhìn lại và điều chỉnh định kỳ | ⚠ retrospective |

Từ khoá nhận diện:

"cách giao tiếp hiệu quả nhất" → ⚠ trò chuyện trực tiếp "đội ảo, không gặp được" → ⚠ hội nghị truyền hình là lựa chọn tốt nhất còn lại "tài liệu vừa đủ" → ⚠ đúng nhưng không phải cách hiệu quả nhất "công cụ tốt" → ⚠ phương tiện, không thay thế được tương tác

⚠ Vì sao trò chuyện trực tiếp hiệu quả hơn tài liệu Cơ chế
⚠ Băng thông thông tin CAO hơn nhiều ⚠ lời nói + nét mặt + cử chỉ + ngữ điệu
⚠ Vòng phản hồi NGẮN nhất ⚠ hiểu nhầm được sửa trong vài giây
⚠ Có thể VẼ, chỉ trỏ, thử ngay
⚠ Đặt câu hỏi làm rõ mà không tốn công viết
⚠ Tài liệu vẫn cần ⚠ cho những gì phải LƯU LẠI và cho người không có mặt
⚠ Vai trò của Jessica — nhà phân tích nghiệp vụ Vai trò
⚠ Cầu nối giữa nghiệp vụ và đội phát triển
⚠ Làm rõ yêu cầu khi lập trình viên có thắc mắc ⚠ đúng việc cô ấy đang làm
⚠ Trong agile, BA thường ngồi cùng đội
⚠ Liên hệ ⚠ xem câu #25714 ở lô 179 về ranh giới giữa PM và BA
⚠ Hiểu SAI thường gặp về nguyên tắc này Đính chính
⚠ "Agile nghĩa là không viết tài liệu" ⚠ SAI — viết VỪA ĐỦ, không viết thừa
⚠ "Không cần công cụ cộng tác" ⚠ SAI — công cụ hỗ trợ, chỉ không thay thế được tương tác
⚠ "Mọi thứ phải nói miệng" ⚠ SAI — quyết định quan trọng vẫn phải ghi lại

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn giải quyết thắc mắc bằng cách nào | ⚠ email qua lại nhiều ngày hay hỏi trực tiếp trong vài phút | | Có ai ngại hỏi trực tiếp không | | | Quyết định quan trọng có được ghi lại sau khi bàn miệng không | |

Và cách tính đơn giản cho thấy vì sao nguyên tắc này đúng: một câu hỏi giải quyết trong 30 giây khi hỏi trực tiếp, có thể mất hai ngày qua email. Với hàng chục câu hỏi mỗi tuần, khoản chênh lệch đó là rất lớn.

Câu 116 People
ACE Corporation has several projects running concurrently. A few of them are part of a large project. If all the teams were to meet simultaneously, there would not be enough space at ACE Corporation headquarters. There would also not be enough time to hear the team members’ collective voices within the meeting. This situation could create unforeseen impediments that could block the team’s progress. Sam, the lead project manager, must find a way to hold a daily scrum meeting that effectively addresses these issues. What is his best course of action?
  1. A He could have the teams email each other with updates, allowing documentation of progress to be reviewed as needed.
  2. B He could schedule an off-site weekly meeting that would allow all the teams to discuss the project’s overall progress.
  3. C He could set up a daily meeting, known as the scrum of scrums, where each team member could be chosen as a representative to report on their team projects’ progress.
  4. D He could submit to management the need for larger conference rooms to allow for larger capacity for daily standups.
Xem giải thích

Đáp án

C — Tổ chức một cuộc họp hằng ngày gọi là SCRUM OF SCRUMS, trong đó mỗi đội cử một ĐẠI DIỆN báo cáo tiến độ của đội mình.

Vì sao đúng

⚠ Scrum of Scrums là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Cơ chế ĐỒNG BỘ giữa NHIỀU đội Scrum | | | ⚠ Mỗi đội cử MỘT ĐẠI DIỆN tham dự | ⚠ thường là người nắm rõ nhất tình hình đội | | ⚠ Giải quyết đúng hai vấn đề của đề | ⚠ không đủ CHỖ và không đủ THỜI GIAN cho tất cả | | ⚠ Vẫn giữ nhịp HẰNG NGÀY | | | ⚠ Tập trung vào PHỤ THUỘC và TRỞ NGẠI giữa các đội | | | ⚠ Kết luận | ⚠ giải pháp chuẩn của Scrum khi mở rộng ra nhiều đội |

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

  • B (họp hằng TUẦN ngoài văn phòng cho tất cả các đội) — ⚠ MẤT nhịp hằng ngày: ⚠ trở ngại phát sinh sẽ nằm chờ tới một tuần; ⚠ và họp ngoài văn phòng tốn kém.

  • D (xin ban lãnh đạo phòng họp lớn hơn) — ⚠ giải quyết vấn đề CHỖ nhưng KHÔNG giải quyết vấn đề THỜI GIAN; ⚠ đề nói rõ ⚠ không đủ thời gian để nghe hết tiếng nói của mọi người.

  • A (các đội gửi email cập nhật cho nhau) — ⚠ biến giao tiếp TƯƠNG TÁC thành giao tiếp ĐẨY một chiều; ⚠ mất khả năng hỏi đáp và gỡ trở ngại ngay.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25773 ở lô 180 (nhiều đội Scrum cần công cụ chung để minh bạch artifact) và câu #25837 ở lô này (trò chuyện trực tiếp hiệu quả nhất). ⚠ Ba câu cùng chủ đề agile ở quy mô lớn.

⚠ Scrum of Scrums — cách vận hành: | Mục | Nội dung | |---|---| | ⚠ Tần suất | ⚠ hằng ngày hoặc vài lần một tuần, tuỳ mức phụ thuộc | | ⚠ Thời lượng | ⚠ ngắn, thường 15–30 phút | | ⚠ Ai dự | ⚠ một đại diện mỗi đội | | ⚠ Nội dung | ⚠ đội tôi đã làm gì ảnh hưởng tới đội khác, sắp làm gì, có trở ngại gì liên đội | | ⚠ Trọng tâm | ⚠ PHỤ THUỘC và TÍCH HỢP giữa các đội | | ⚠ Khác với daily standup thường | ⚠ standup lo trong nội bộ đội; scrum of scrums lo GIỮA các đội |

Từ khoá nhận diện:

"nhiều đội cần đồng bộ hằng ngày" → ⚠ scrum of scrums "đại diện mỗi đội" → ⚠ đặc trưng của scrum of scrums "họp tuần thay vì ngày" → ⚠ mất nhịp phản hồi nhanh "gửi email cho nhau" → ⚠ mất tính tương tác

⚠ Các khung mở rộng agile cho nhiều đội: | Khung | Đặc điểm | |---|---| | ⚠ Scrum of Scrums | ⚠ cơ chế đơn giản nhất — đại diện các đội họp với nhau | | ⚠ Nexus | ⚠ khung chính thức của Scrum.org cho 3–9 đội, có Nexus Integration Team | | ⚠ LeSS — Large-Scale Scrum | ⚠ giữ Scrum gọn nhẹ, một product backlog cho nhiều đội | | ⚠ SAFe — Scaled Agile Framework | ⚠ khung lớn nhất, nhiều tầng, phù hợp tổ chức lớn | | ⚠ Điểm chung | ⚠ đều phải giải quyết bài toán ĐỒNG BỘ và PHỤ THUỘC giữa các đội |

⚠ Ai nên là đại diện của đội Tiêu chí
⚠ Người nắm rõ tình hình kỹ thuật và trở ngại của đội
⚠ Có thể là Scrum Master, hoặc một thành viên đội
⚠ Nên LUÂN PHIÊN để nhiều người có góc nhìn toàn cảnh
⚠ Đại diện phải ⚠ mang thông tin về LẠI cho đội mình, không giữ riêng
⚠ Rủi ro của scrum of scrums nếu làm sai Rủi ro
⚠ Biến thành buổi BÁO CÁO TÌNH TRẠNG cho quản lý ⚠ sai mục đích — nó là buổi đồng bộ giữa các đội
⚠ Đại diện không mang thông tin về lại đội
⚠ Kéo dài quá lâu
⚠ Bàn chi tiết kỹ thuật thay vì bàn phụ thuộc
⚠ Giữ đúng trọng tâm ⚠ chỉ bàn thứ ẢNH HƯỞNG tới đội khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Các đội có biết phụ thuộc chéo của mình không | | | Đại diện có mang thông tin về lại đội không | | | Buổi họp có giữ được dưới 30 phút không | |

Và nguyên tắc mở rộng agile: giữ nguyên nhịp nhanh, chỉ giảm số người trong mỗi cuộc trò chuyện. Sam làm đúng khi giữ nhịp hằng ngày thay vì đổi sang họp tuần cho tiện.

Câu 117 People
Nikki is working with her project team on reviewing the project schedule to determine how closely the project is to meet the expected milestones. With the team, Nikki evaluates the network diagram and compares it with the project schedule. She is worried about falling behind schedule, so she decides to bring on some extra staff to ensure that the project is not late. This is an example of
  1. A Resource smoothing
  2. B Fast-tracking 
  3. C Crashing
  4. D Resource leveling
Xem giải thích

Đáp án

C — Crashing (nén lịch bằng cách thêm nguồn lực).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ Lo bị CHẬM tiến độ | ⚠ cần nén lịch | | ⚠ Quyết định BỔ SUNG THÊM NHÂN SỰ | ⚠ thêm nguồn lực = crashing | | ⚠ Mục tiêu: dự án không bị trễ | | | ⚠ Kết luận | ⚠ đúng định nghĩa crashing — thêm nguồn lực để rút ngắn thời lượng |

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

  • B (Fast-tracking) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ fast-tracking là ⚠ chạy SONG SONG các việc vốn nối tiếp, ⚠ KHÔNG thêm nguồn lực; ⚠ Nikki thêm người nên không phải fast-tracking.

  • A (Resource smoothing) và D (Resource levelling) — ⚠ là kỹ thuật TỐI ƯU HOÁ NGUỒN LỰC, ⚠ mục đích là ⚠ cân bằng mức sử dụng nguồn lực, ⚠ KHÔNG phải để rút ngắn lịch; ⚠ thực tế levelling thường LÀM DÀI thêm lịch.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Đây là câu THỨ BA trong bộ đề về nén lịch trình. ⚠ Bảng đối chiếu: | Câu | Lô | Tình huống | Khoá | |---|---|---|---| | ⚠ #25665 | ⚠ 179 | ⚠ điều kiện để crashing có tác dụng | ⚠ công việc phụ thuộc CÔNG SỨC | | ⚠ #25774 | ⚠ 180 | ⚠ ngân sách cạn, có việc đổi thứ tự được | ⚠ FAST-TRACKING | | ⚠ #25839 | ⚠ 182 | ⚠ thêm nhân sự để không bị trễ | ⚠ CRASHING | ⚠ Ba khoá đều đúng và không mâu thuẫn. ⚠ Cách phân biệt tuyệt đối chắc chắn: THÊM NGUỒN LỰC là crashing; CHẠY SONG SONG là fast-tracking.

⚠ Bốn kỹ thuật liên quan tới lịch trình — đừng lẫn: | Kỹ thuật | Mục đích | Cách làm | Tác động lên lịch | |---|---|---|---| | ⚠ CRASHING | ⚠ RÚT NGẮN lịch | ⚠ thêm nguồn lực | ⚠ ngắn lại, CHI PHÍ tăng | | ⚠ FAST TRACKING | ⚠ RÚT NGẮN lịch | ⚠ chạy song song | ⚠ ngắn lại, RỦI RO tăng | | ⚠ RESOURCE LEVELLING | ⚠ cân bằng nguồn lực | ⚠ điều chỉnh ngày làm theo giới hạn nguồn lực | ⚠ CÓ THỂ DÀI RA | | ⚠ RESOURCE SMOOTHING | ⚠ cân bằng nguồn lực | ⚠ chỉ dùng phần float sẵn có | ⚠ KHÔNG đổi |

Từ khoá nhận diện:

"thêm người, thêm ca, thêm thiết bị" → ⚠ CRASHING "chạy song song việc vốn nối tiếp" → ⚠ FAST TRACKING "cân bằng mức sử dụng nguồn lực, có thể trễ hơn" → ⚠ LEVELLING "chỉ dùng float, không trễ" → ⚠ SMOOTHING

⚠ Điều Nikki cần cân nhắc trước khi thêm người Cân nhắc
⚠ Việc đó có nằm trên ĐƯỜNG GĂNG không ⚠ thêm người vào việc ngoài đường găng KHÔNG rút ngắn dự án
⚠ Việc đó có PHỤ THUỘC CÔNG SỨC không ⚠ xem câu #25665
⚠ Có ngân sách cho phần chi phí tăng thêm không
⚠ Người mới cần bao lâu để làm quen ⚠ định luật Brooks — thêm người vào dự án chậm có thể làm nó chậm hơn
⚠ Có đủ người có kỹ năng phù hợp không
⚠ Nikki đã làm đúng một việc ⚠ cô ấy đã rà soát SƠ ĐỒ MẠNG trước — tức là đã xem đường găng
⚠ Sau khi crashing phải làm gì Việc
⚠ TÍNH LẠI đường găng ⚠ đường khác có thể trở thành găng
⚠ Cập nhật đường cơ sở chi phí nếu vượt ⚠ qua kiểm soát thay đổi
⚠ Cập nhật sổ rủi ro ⚠ thêm người sinh rủi ro giao tiếp và chất lượng
⚠ Theo dõi xem có thật sự rút ngắn được không
⚠ Vì sao levelling và smoothing KHÔNG dùng để rút ngắn lịch Lý do
⚠ Mục đích của chúng là GIẢI QUYẾT XUNG ĐỘT nguồn lực ⚠ một người bị phân cho hai việc cùng lúc
⚠ Levelling ưu tiên giới hạn nguồn lực hơn ngày kết thúc ⚠ nên có thể làm dự án DÀI ra
⚠ Smoothing giữ nguyên ngày kết thúc nhưng chỉ điều chỉnh trong phạm vi float
⚠ Mẹo nhớ ⚠ levelling có thể trễ, smoothing thì không, và không cái nào rút ngắn được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc bạn định crash có nằm trên đường găng không | | | Chi phí tăng thêm đã được duyệt chưa | | | Người mới có làm chậm đội trong ngắn hạn không | |

Và cách phân biệt gọn nhất giữa hai kỹ thuật nén lịch: crashing trả bằng TIỀN, fast-tracking trả bằng RỦI RO. Nikki chọn trả bằng tiền.

Câu 118 Process
Alise is the project manager of a project constructing a nursing home facility. She must report on the effectiveness of managing project artifacts and providing suggestions to improve them at the end of each project phase. Which of the following guidelines should Alise not use when assessing the effectiveness of project artifacts?
  1. A Follow any organizational procedures regarding project management documentation.
  2. B Implement version control of documents to reconstruct changes and revert to an earlier version if necessary.
  3. C Develop an archive management system that is of appropriate size and complexity for the project.
  4. D Use the maximum degree of configuration management for the project.
Xem giải thích

Đáp án

D — Dùng MỨC ĐỘ TỐI ĐA của quản lý cấu hình cho dự án. ⚠ Đây KHÔNG phải hướng dẫn nên dùng.

Vì sao đúng

⚠ Vì sao "tối đa" là sai: | Lý do | Nội dung | |---|---| | ⚠ Quản lý cấu hình phải TƯƠNG XỨNG với quy mô và độ phức tạp dự án | | | ⚠ Tối đa hoá quy trình = tối đa hoá THỦ TỤC HÀNH CHÍNH | | | ⚠ Thủ tục quá nặng khiến người ta LÁCH hoặc bỏ qua | ⚠ và lúc đó mất kiểm soát thật | | ⚠ Tốn thời gian và chi phí không tạo giá trị | | | ⚠ Nguyên tắc đúng | ⚠ mức độ VỪA ĐỦ — appropriate, không phải maximum |

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

⚠ Cả ba phương án còn lại ĐỀU là hướng dẫn hợp lý:

  • A (tuân theo quy trình tài liệu của tổ chức) — ⚠ ĐÚNG: ⚠ tận dụng tài sản quy trình tổ chức, đảm bảo nhất quán.

  • B (kiểm soát phiên bản để dựng lại thay đổi và quay về bản cũ khi cần) — ⚠ ĐÚNG: ⚠ đây là chức năng cốt lõi của quản lý cấu hình.

  • C (xây hệ thống lưu trữ có QUY MÔ và ĐỘ PHỨC TẠP PHÙ HỢP với dự án) — ⚠ ĐÚNG, ⚠ và ⚠ chính là điều ngược lại với phương án D — ⚠ đây là manh mối mạnh nhất để loại D.

Ghi nhớ

Ghi nhớ về chất lượng câu hỏi: ⚠ Câu này GẦN TRÙNG VỀ KHÁI NIỆM với câu #25824 ở lô 181 ⚠ (đặc điểm nào KHÔNG thuộc hệ thống lưu trữ hiệu quả). ⚠ Hai câu ⚠ cùng chủ đề quản lý hiện vật dự án và cùng dạng "tất cả TRỪ": | Câu | Lô | Phương án SAI | Vì sao sai | |---|---|---|---| | ⚠ #25824 | ⚠ 181 | ⚠ quy trình duyệt tài liệu LINH HOẠT | ⚠ duyệt phải NHẤT QUÁN | | ⚠ #25840 | ⚠ 182 | ⚠ quản lý cấu hình mức TỐI ĐA | ⚠ phải VỪA ĐỦ | ⚠ Hai khoá KHÔNG mâu thuẫn — chúng bổ sung nhau và cùng chỉ ra một nguyên tắc: CHẶT về kiểm soát, NHẸ về thủ tục, VỪA ĐỦ về quy mô.

⚠ Quản lý cấu hình — configuration management: | Điều | Nội dung | |---|---| | ⚠ Là hệ thống KIỂM SOÁT các phiên bản của sản phẩm và tài liệu | | | ⚠ Xác định cái gì được đưa vào kiểm soát | ⚠ configuration items | | ⚠ Ghi nhận và báo cáo trạng thái từng phiên bản | | | ⚠ Kiểm tra xác nhận tính toàn vẹn | | | ⚠ Khác với kiểm soát thay đổi | ⚠ quản lý cấu hình lo SẢN PHẨM và TÀI LIỆU; kiểm soát thay đổi lo QUYẾT ĐỊNH có duyệt thay đổi hay không |

Từ khoá nhận diện:

"mức tối đa, càng nhiều càng tốt" → ⚠ hầu như luôn SAI trong quản lý dự án "phù hợp với quy mô và độ phức tạp" → ⚠ nguyên tắc TAILORING — luôn đúng "kiểm soát phiên bản" → ⚠ chức năng cốt lõi, luôn cần "tuân theo quy trình tổ chức" → ⚠ luôn đúng

⚠ Nguyên tắc TAILORING — điều chỉnh cho phù hợp: | Nguyên tắc | Nội dung | |---|---| | ⚠ Không có quy trình nào phù hợp cho MỌI dự án | | | ⚠ Điều chỉnh theo quy mô, độ phức tạp, rủi ro, tầm quan trọng | | | ⚠ Dự án nhỏ cần quy trình nhẹ | | | ⚠ Dự án lớn và rủi ro cao cần quy trình chặt hơn | | | ⚠ PMBOK nhấn mạnh | ⚠ tailoring là TRÁCH NHIỆM của quản lý dự án, không phải tuỳ tiện bỏ quy trình |

⚠ Dấu hiệu quản lý cấu hình quá nặng Dấu hiệu
⚠ Người ta giữ bản riêng trên máy để làm việc cho nhanh ⚠ dấu hiệu nguy hiểm nhất
⚠ Thời gian làm thủ tục nhiều hơn thời gian làm việc
⚠ Có quy trình nhưng ai cũng lách
⚠ Tài liệu được duyệt xong đã lỗi thời
⚠ Cách chữa ⚠ giảm số hạng mục đưa vào kiểm soát, tự động hoá, đơn giản hoá bước duyệt
⚠ Với dự án xây viện dưỡng lão của Alise Lưu ý
⚠ Bản vẽ và đặc tả kỹ thuật CẦN kiểm soát chặt ⚠ dùng nhầm bản vẽ cũ gây hậu quả vật lý
⚠ Hồ sơ pháp lý và kiểm định phải lưu lâu dài
⚠ Nhưng biên bản họp nội bộ không cần quy trình duyệt nặng nề
⚠ Nguyên tắc ⚠ phân loại hạng mục theo mức quan trọng, áp mức kiểm soát tương ứng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Có ai đang lách quy trình tài liệu không | ⚠ nếu có thì quy trình đang quá nặng | | Mức kiểm soát có tương xứng với rủi ro của từng loại tài liệu không | | | Bạn có đang áp cùng một mức cho mọi thứ không | |

Và nguyên tắc chung của mọi quy trình quản lý dự án: vừa đủ luôn tốt hơn tối đa. Một quy trình quá nặng bị lách hoàn toàn còn tệ hơn một quy trình nhẹ được tuân thủ nghiêm túc.

Câu 119 Process
A project plan gives a baseline for several factors. The project plan does not provide a baseline for which of the following?
  1. A Cost
  2. B Control
  3. C Schedule
  4. D Scope
Xem giải thích

Đáp án

B — Control (kiểm soát). ⚠ Không có đường cơ sở nào tên là "kiểm soát".

Vì sao đúng

⚠ Ba đường cơ sở của kế hoạch quản lý dự án: | Đường cơ sở | Nội dung | |---|---| | ⚠ SCOPE baseline | ⚠ scope statement + WBS + WBS dictionary | | ⚠ SCHEDULE baseline | ⚠ phiên bản lịch trình đã được phê duyệt | | ⚠ COST baseline | ⚠ đường cong chi phí đã được phê duyệt, chứa BAC | | ⚠ Gộp cả ba | ⚠ PERFORMANCE MEASUREMENT BASELINE — đường cơ sở đo hiệu suất | | ⚠ "Control baseline" | ⚠ KHÔNG tồn tại — kiểm soát là HOẠT ĐỘNG, không phải đường cơ sở |

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

  • A (Cost), C (Schedule), D (Scope) — ⚠ cả ba ĐỀU là đường cơ sở chính thức.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25746 ở lô 180 (kế hoạch dự án là kim chỉ nam), câu #25705 ở lô 179 (đường cơ sở chỉ đổi qua kiểm soát thay đổi), và câu #25804 ở lô 181 (kế hoạch quản lý chi phí không có quyền đổi BAC). ⚠ Bốn câu cùng làm rõ vai trò của đường cơ sở.

⚠ Đường cơ sở là gì và vì sao quan trọng: | Điều | Nội dung | |---|---| | ⚠ Là phiên bản ĐÃ ĐƯỢC PHÊ DUYỆT của một kế hoạch | | | ⚠ Chỉ đổi được qua KIỂM SOÁT THAY ĐỔI CHÍNH THỨC | | | ⚠ Là chuẩn để ĐO hiệu suất thực tế | ⚠ không có đường cơ sở thì không tính được CV, SV, CPI, SPI | | ⚠ Cho phép so sánh "kế hoạch" với "thực tế" | | | ⚠ Không có đường cơ sở | ⚠ mọi báo cáo tiến độ đều là cảm nhận |

⚠ Thành phần đầy đủ của kế hoạch quản lý dự án: | Nhóm | Thành phần | |---|---| | ⚠ Các KẾ HOẠCH CON | ⚠ phạm vi, yêu cầu, lịch, chi phí, chất lượng, nguồn lực, giao tiếp, rủi ro, mua sắm, bên liên quan | | ⚠ Ba ĐƯỜNG CƠ SỞ | ⚠ phạm vi, lịch trình, chi phí | | ⚠ Thành phần BỔ SUNG | ⚠ change management plan, configuration management plan, performance measurement baseline, project life cycle, development approach, management reviews |

Từ khoá nhận diện:

"ba đường cơ sở" → ⚠ phạm vi, lịch trình, chi phí "đường cơ sở đo hiệu suất" → ⚠ gộp cả ba lại "kiểm soát" → ⚠ là HOẠT ĐỘNG, không phải đường cơ sở "chỉ đổi qua kiểm soát thay đổi" → ⚠ đặc trưng của đường cơ sở

⚠ Phân biệt các khái niệm dễ lẫn Phân biệt
⚠ Cost baseline ⚠ đường cong chi phí được duyệt, KHÔNG gồm management reserve
⚠ Project budget ⚠ cost baseline + MANAGEMENT RESERVE
⚠ BAC ⚠ tổng của cost baseline — dùng trong công thức EVM
⚠ Mẹo nhớ ⚠ cost baseline + management reserve = project budget
⚠ Vì sao management reserve nằm NGOÀI đường cơ sở Lý do
⚠ Dành cho rủi ro CHƯA BIẾT ⚠ unknown-unknowns
⚠ PM phải XIN PHÉP mới được dùng
⚠ Không tính vào phép đo hiệu suất EVM ⚠ nếu tính vào thì CPI bị bóp méo
⚠ Contingency reserve thì ngược lại ⚠ nằm TRONG đường cơ sở, dành cho rủi ro ĐÃ BIẾT, PM tiêu được

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Dự án của bạn có đủ ba đường cơ sở được phê duyệt chưa | | | Đường cơ sở có được cập nhật khi có thay đổi được duyệt không | ⚠ không cập nhật thì mọi chỉ số EVM đều sai | | Bạn có phân biệt được cost baseline với project budget không | |

Và mẹo làm bài cho dạng câu này: PMBOK có ĐÚNG BA đường cơ sở. Mọi phương án khác — kiểm soát, chất lượng, rủi ro, nguồn lực — đều là kế hoạch con, không phải đường cơ sở.

Câu 120 Process
Which of the following trends are expected in agile development?
  1. A Adaptability increases over time.
  2. B Risk decreases more quickly than in traditional development.
  3. C Business value experiences a significant increase at the end of the project.
  4. D Visibility increases in a linear way over time.
Xem giải thích

Đáp án

B — RỦI RO GIẢM NHANH HƠN so với phát triển truyền thống.

Vì sao đúng

⚠ Vì sao agile giảm rủi ro nhanh hơn: | Cơ chế | Nội dung | |---|---| | ⚠ Giao phần chạy được SỚM và THƯỜNG XUYÊN | ⚠ rủi ro kỹ thuật lộ ra ngay từ vòng lặp đầu | | ⚠ Phản hồi khách hàng SỚM | ⚠ rủi ro làm sai thứ khách cần được loại bỏ sớm | | ⚠ Tích hợp liên tục | ⚠ không dồn rủi ro tích hợp về cuối | | ⚠ Ưu tiên hạng mục RỦI RO CAO lên trước | ⚠ risk-adjusted backlog | | ⚠ Trong cách truyền thống | ⚠ phần lớn rủi ro chỉ lộ ra ở giai đoạn tích hợp và kiểm thử — gần cuối dự án |

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

  • A (khả năng thích ứng TĂNG theo thời gian) — ⚠ NGƯỢC: ⚠ khả năng thích ứng ⚠ GIẢM dần khi dự án tiến triển, ⚠ vì càng về sau càng nhiều thứ đã xây và chi phí thay đổi càng cao; ⚠ agile chỉ khiến đường cong này ⚠ thoải hơn, không đảo ngược nó.

  • C (giá trị kinh doanh tăng mạnh ở CUỐI dự án) — ⚠ đó là đặc trưng của cách TRUYỀN THỐNG; ⚠ agile giao giá trị ⚠ DẦN DẦN từ sớm.

  • D (khả năng nhìn thấy tăng TUYẾN TÍNH theo thời gian) — ⚠ trong agile, khả năng nhìn thấy CAO NGAY TỪ ĐẦU ⚠ nhờ increment chạy được và các bảng thông tin; ⚠ không phải tăng dần đều.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25748 ở lô 180 (rủi ro phải đánh giá liên tục trong agile), câu #25799 ở lô 181 (MVP để học nhanh), và câu #25781 ở lô 180 (vòng đời tăng dần). ⚠ Bốn câu cùng làm rõ cơ chế giảm rủi ro của agile.

⚠ Bốn đường cong so sánh agile với truyền thống: | Yếu tố | Truyền thống | Agile | |---|---|---| | ⚠ RỦI RO | ⚠ giảm CHẬM, phần lớn dồn về cuối | ⚠ giảm NHANH ngay từ đầu — CÂU NÀY | | ⚠ GIÁ TRỊ kinh doanh | ⚠ tăng vọt ở CUỐI khi giao hàng | ⚠ tăng DẦN từ vòng lặp đầu | | ⚠ Khả năng NHÌN THẤY | ⚠ thấp cho tới khi có sản phẩm | ⚠ CAO ngay từ đầu nhờ increment chạy được | | ⚠ Khả năng THÍCH ỨNG | ⚠ giảm nhanh, thay đổi muộn rất đắt | ⚠ giảm CHẬM hơn, nhưng VẪN GIẢM |

Từ khoá nhận diện:

"rủi ro giảm nhanh hơn" → ⚠ đặc trưng agile "giá trị dồn về cuối" → ⚠ đặc trưng truyền thống "thích ứng tăng theo thời gian" → ⚠ SAI với mọi cách tiếp cận "nhìn thấy cao ngay từ đầu" → ⚠ agile

⚠ Vì sao khả năng THÍCH ỨNG luôn giảm theo thời gian Lý do
⚠ Càng về sau càng nhiều thứ đã được xây
⚠ Thay đổi phải sửa cả những gì đã làm
⚠ Ràng buộc tích luỹ: hợp đồng, kiến trúc, cam kết
⚠ Agile làm được gì ⚠ giữ khả năng thích ứng CAO HƠN lâu HƠN, chứ không làm nó tăng lên
⚠ Bài học ⚠ thay đổi sớm vẫn luôn rẻ hơn thay đổi muộn, kể cả trong agile
⚠ Cách agile chủ động giảm rủi ro Cách
⚠ Ưu tiên hạng mục RỦI RO CAO lên đầu backlog ⚠ risk-adjusted backlog
⚠ Dùng SPIKE để nghiên cứu giảm bất định kỹ thuật
⚠ Giao MVP để kiểm chứng giả định thị trường
⚠ Tích hợp liên tục và kiểm thử tự động
⚠ Rà soát rủi ro trong retrospective
⚠ Nguyên tắc ⚠ học sớm nhất có thể về thứ mình chưa chắc chắn nhất
⚠ Cạm bẫy: agile KHÔNG tự động loại bỏ rủi ro Cạm bẫy
⚠ Vẫn cần quản lý rủi ro TƯỜNG MINH ⚠ xem câu #25748
⚠ Rủi ro tổ chức và bên ngoài không giảm nhờ vòng lặp
⚠ Nếu backlog xếp theo dễ trước khó sau thì rủi ro lại dồn về cuối ⚠ sai lầm phổ biến
⚠ Vì thế ⚠ thứ tự ưu tiên backlog quyết định đường cong rủi ro thật sự

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hạng mục rủi ro cao có nằm ở đầu backlog không | | | Bạn học được gì mới sau mỗi vòng lặp | | | Rủi ro có được rà soát định kỳ không | |

Và cơ chế giải thích toàn bộ lợi thế của agile: mỗi vòng lặp là một lần kiểm chứng giả định. Càng kiểm chứng sớm thì càng ít thứ không chắc chắn — và đó chính là định nghĩa của việc giảm rủi ro.