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

Tìm thấy 720 câu.

Câu 41 Process
You have been very successful in project managing the design phase of one of the world's largest indoor aquariums. Given the technical complexity of this project and the number of contractors and vendors involved, the outcome has been extremely promising. The integration of third-party resources, contracts, and legal documentation collected will be used as an input to which of the following?
  1. A Close project or phase
  2. B Updated lessons learned
  3. C Contract administration
  4. D Control procurements
Xem giải thích

Đáp án

A — Close Project or Phase (kết thúc dự án hoặc giai đoạn).

Vì sao đúng

⚠ Vì sao hợp đồng và hồ sơ pháp lý là đầu vào của quy trình kết thúc: | Lý do | Nội dung | |---|---| | ⚠ Phải xác nhận MỌI hợp đồng đã hoàn thành và đóng đúng thủ tục | | | ⚠ Phải kiểm tra không còn khiếu nại hay tranh chấp nào | | | ⚠ Hồ sơ pháp lý được lưu trữ thành tài sản tổ chức | | | ⚠ Đề nói rõ: dự án đang KẾT THÚC GIAI ĐOẠN THIẾT KẾ | ⚠ "you have been very successful in managing the DESIGN PHASE" | | ⚠ PMBOK liệt kê | ⚠ agreements là đầu vào chính thức của Close Project or Phase |

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

  • D (Control Procurements) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ quy trình này ⚠ QUẢN LÝ hợp đồng trong lúc thực hiện và cũng có phần đóng hợp đồng; ⚠ nhưng đề hỏi về ⚠ TÍCH HỢP toàn bộ tài nguyên bên thứ ba, hợp đồng và hồ sơ pháp lý — ⚠ đó là hoạt động ở tầm KẾT THÚC GIAI ĐOẠN, không phải quản lý từng hợp đồng.

  • C (Contract administration) — ⚠ là tên CŨ của Control Procurements trong các ấn bản PMBOK trước; ⚠ không còn là tên quy trình chuẩn.

  • B (Updated lessons learned) — ⚠ là một ĐẦU RA, không phải quy trình; ⚠ nó là kết quả của Close Project or Phase chứ không phải nơi tiếp nhận đầu vào.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25711 ở lô 179 — ⚠ dự án bị huỷ vẫn phải viết báo cáo cuối cùng. ⚠ Hai câu cùng nói về quy trình Close Project or Phase, một câu ở tình huống huỷ, một câu ở tình huống thành công. ⚠ Và câu #25652 ở lô 178 về Control Procurements.

⚠ Close Project or Phase — đầu vào và đầu ra: | Loại | Nội dung | |---|---| | ⚠ Đầu vào: project charter | | | ⚠ Đầu vào: project management plan | | | ⚠ Đầu vào: tài liệu dự án | ⚠ sổ rủi ro, sổ vấn đề, bài học, tài liệu yêu cầu | | ⚠ Đầu vào: bàn giao ĐÃ ĐƯỢC CHẤP NHẬN | | | ⚠ Đầu vào: AGREEMENTS — hợp đồng | ⚠ ĐÚNG CÂU NÀY | | ⚠ Đầu vào: tài liệu mua sắm | | | ⚠ Đầu ra: bàn giao sản phẩm cuối cùng | | | ⚠ Đầu ra: FINAL REPORT — báo cáo cuối cùng | | | ⚠ Đầu ra: cập nhật tài sản quy trình tổ chức | ⚠ bao gồm lessons learned |

Từ khoá nhận diện:

"hợp đồng, hồ sơ pháp lý làm đầu vào" → ⚠ Close Project or Phase "quản lý quan hệ với nhà cung cấp đang thực hiện" → ⚠ Control Procurements "contract administration" → ⚠ tên CŨ, không còn dùng "kết thúc GIAI ĐOẠN, không phải cả dự án" → ⚠ vẫn là Close Project or PHASE

⚠ Vì sao PMBOK 6 gộp Close Procurements vào Control Procurements Lý do
⚠ Việc đóng hợp đồng là một phần của quản lý hợp đồng
⚠ Tránh trùng lặp giữa hai quy trình
⚠ Nhưng Close Project or Phase VẪN xác nhận mọi hợp đồng đã đóng ⚠ ở tầm tổng thể
⚠ Phân vai ⚠ Control Procurements đóng TỪNG hợp đồng; Close Project xác nhận TẤT CẢ đã đóng và kết thúc giai đoạn
⚠ Kết thúc GIAI ĐOẠN cần làm gì Việc
⚠ Xác nhận bàn giao của giai đoạn đã được chấp nhận
⚠ Đóng các hợp đồng thuộc giai đoạn đó
⚠ Thu thập bài học kinh nghiệm của giai đoạn
⚠ Chuẩn bị chuyển giao sang giai đoạn tiếp theo
⚠ Rà soát: có nên đi tiếp không ⚠ phase gate review
⚠ Với dự án thuỷ cung này ⚠ giai đoạn thiết kế xong, chuyển sang giai đoạn thi công — tài liệu pháp lý và hợp đồng là cầu nối giữa hai giai đoạn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mọi hợp đồng của giai đoạn đã đóng chưa | ⚠ hợp đồng mở là rủi ro pháp lý và tài chính | | Có khiếu nại nào chưa giải quyết không | | | Tài liệu đã được lưu trữ đúng chỗ chưa | |

Và điều dễ bị xem nhẹ khi dự án đang thuận lợi: kết thúc giai đoạn cẩn thận cũng quan trọng như bắt đầu. Một hợp đồng chưa đóng ở giai đoạn thiết kế có thể quay lại thành tranh chấp khi công trình đã xây xong.

Câu 42 Process
Aaron has written a statement that briefly discusses in his charter who the project is for, what their need is, what the product/service is, and the product category. He is most likely writing
  1. A A project planning statement
  2. B A standard project charter
  3. C An agile approach statement
  4. D A project elevator statement
Xem giải thích

Đáp án

D — A project elevator statement (câu tuyên bố thang máy).

Vì sao đúng

⚠ Elevator statement là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Câu tóm tắt NGẮN GỌN về dự án | ⚠ ngắn tới mức nói xong trong một chuyến thang máy | | ⚠ Nêu dự án dành cho AI | ⚠ đối tượng | | ⚠ Nêu NHU CẦU của họ là gì | ⚠ vấn đề cần giải quyết | | ⚠ Nêu SẢN PHẨM hoặc DỊCH VỤ là gì | | | ⚠ Nêu DANH MỤC sản phẩm | ⚠ nó thuộc loại gì | | ⚠ Đề liệt kê đúng bốn yếu tố này | ⚠ nên đáp án rất rõ ràng |

⚠ Khuôn mẫu elevator statement thường dùng:

⚠ "DÀNH CHO [đối tượng] LÀ NGƯỜI [có nhu cầu], [tên sản phẩm] LÀ MỘT [danh mục sản phẩm] MÀ [lợi ích chính]. KHÁC VỚI [phương án hiện tại], sản phẩm của chúng tôi [điểm khác biệt]."

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

  • B (một điều lệ dự án chuẩn) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ elevator statement ⚠ NẰM TRONG điều lệ, ⚠ nhưng nó chỉ là MỘT PHẦN — ⚠ điều lệ còn có mục tiêu, mốc, rủi ro, ngân sách, thẩm quyền PM và nhiều mục khác.

  • A (một tuyên bố lập kế hoạch dự án) và C (một tuyên bố về cách tiếp cận linh hoạt) — ⚠ không phải thuật ngữ chuẩn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25695 ở lô 179 về mục đích của điều lệ dự án. ⚠ Elevator statement là một thành phần bên trong điều lệ — đừng nhầm phần với toàn thể.

⚠ Vì sao elevator statement hữu ích: | Lý do | Nội dung | |---|---| | ⚠ Buộc phải LÀM RÕ dự án phục vụ ai và giải quyết gì | ⚠ không viết ngắn được nghĩa là chưa hiểu rõ | | ⚠ Ai trong đội cũng nói được cùng một câu chuyện | | | ⚠ Dùng để giới thiệu nhanh với lãnh đạo và bên liên quan | | | ⚠ Là mốc để kiểm tra dự án có đi chệch hướng không | ⚠ xem câu #25738 ở lô này | | ⚠ Khó nhất | ⚠ viết NGẮN — cắt được mọi thứ trừ điều cốt lõi |

Từ khoá nhận diện:

"câu ngắn nêu cho ai, nhu cầu gì, sản phẩm gì" → ⚠ elevator statement "cho phép dự án tồn tại, bổ nhiệm PM" → ⚠ project charter "vì sao dự án đáng làm, phân tích chi phí lợi ích" → ⚠ business case "đo và duy trì lợi ích" → ⚠ benefits management plan

⚠ Ví dụ một elevator statement Ví dụ
⚠ "Dành cho nhân viên văn phòng thường xuyên di chuyển," ⚠ đối tượng
⚠ "là những người cần truy cập email trên nhiều thiết bị," ⚠ nhu cầu
⚠ "hệ thống thư mới là một nền tảng đồng bộ đa nền tảng" ⚠ sản phẩm và danh mục
⚠ "cho phép đọc và gửi thư liền mạch giữa điện thoại và máy tính." ⚠ lợi ích chính
⚠ Các thành phần của điều lệ dự án — để so sánh Thành phần
⚠ Mục đích dự án ⚠ elevator statement thường nằm ở đây
⚠ Mục tiêu đo được và tiêu chí thành công
⚠ Yêu cầu mức cao
⚠ Mô tả, ranh giới, bàn giao chính
⚠ Rủi ro tổng thể
⚠ Lịch mốc tóm tắt
⚠ Ngân sách sơ bộ
⚠ Danh sách bên liên quan
⚠ Tiêu chí phê duyệt và kết thúc
⚠ Quản lý dự án và THẨM QUYỀN
⚠ Người ban hành

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có nói được dự án trong 30 giây không | ⚠ nếu không thì chưa đủ rõ | | Mọi người trong đội có nói giống nhau không | ⚠ phép thử tốt nhất | | Câu tuyên bố có nêu được NHU CẦU chứ không chỉ nêu sản phẩm không | |

Và phép thử đơn giản nhất cho độ rõ ràng của một dự án: thử giải thích nó cho người ngoài trong nửa phút. Không làm được thì vấn đề nằm ở dự án, không nằm ở kỹ năng nói.

Câu 43 Process
Nancy is the scrum master for the Kracken Project, which is five iterations into deployment and has a velocity of 23 story points. Recently a contractor finished some work and submitted an invoice to Nancy detailing the number of hours worked and the cost of the specific materials utilized. Which of the following choices best describes the type of contract this vendor uses?
  1. A Time and materials.
  2. B Cost-plus fixed fee.
  3. C Firm-fixed-price.
  4. D Cost-plus award fee.
Xem giải thích

Đáp án

A — Time and materials (thời gian và vật tư).

Vì sao đúng

⚠ Bằng chứng nằm ngay trong hoá đơn: | Chi tiết trên hoá đơn | Suy ra | |---|---| | ⚠ Ghi rõ SỐ GIỜ đã làm | ⚠ → phần "TIME" | | ⚠ Ghi rõ CHI PHÍ VẬT TƯ cụ thể đã dùng | ⚠ → phần "MATERIALS" | | ⚠ Thanh toán theo THỰC TẾ phát sinh | | | ⚠ Kết luận | ⚠ đúng cấu trúc hoá đơn của hợp đồng T&M |

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

  • C (Firm-fixed-price — giá cố định cứng) — ⚠ hoá đơn chỉ ghi MỘT con số đã thoả thuận trước, ⚠ không liệt kê giờ công và vật tư.

  • B (Cost-plus fixed fee) và D (Cost-plus award fee) — ⚠ hoá đơn sẽ có CHI PHÍ THỰC TẾ CỘNG một khoản PHÍ riêng; ⚠ đề không nhắc tới khoản phí cố định hay phí thưởng nào.

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 #25733 CÙNG LÔ ⚠ (Allen thuê nhà thầu xây dựng gấp trước mùa bão). ⚠ Hai câu ⚠ có CÙNG khoá đáp án "time and materials" ⚠ nhưng tiếp cận từ hai góc hoàn toàn khác: ⚠ #25733 hỏi NÊN CHỌN loại hợp đồng nào cho tình huống, câu này hỏi NHẬN DIỆN loại hợp đồng từ hoá đơn. ⚠ MD5 không bắt được vì lời văn khác hẳn. ⚠ Hai khoá KHÔNG mâu thuẫn — giữ nguyên cả hai. ⚠ Lưu ý chữ cái đã bị xáo: ở #25733 đáp án là D, ở câu này là A.

⚠ Ba loại hợp đồng — nhận diện qua HOÁ ĐƠN: | Loại | Hoá đơn trông thế nào | |---|---| | ⚠ Fixed Price | ⚠ MỘT con số theo hợp đồng, không phụ thuộc chi phí thực tế | | ⚠ Cost Reimbursable | ⚠ liệt kê CHI PHÍ THỰC TẾ + một khoản PHÍ (cố định, thưởng, hoặc theo tỷ lệ) | | ⚠ Time & Materials | ⚠ SỐ GIỜ × ĐƠN GIÁ + CHI PHÍ VẬT TƯ — CÂU NÀY |

⚠ Các biến thể cost-plus: | Ký hiệu | Cách tính phí | |---|---| | ⚠ CPFF — Cost Plus Fixed Fee | ⚠ chi phí thực tế + phí CỐ ĐỊNH đã thoả thuận | | ⚠ CPIF — Cost Plus Incentive Fee | ⚠ chi phí thực tế + phí THAY ĐỔI theo hiệu suất, có công thức chia sẻ | | ⚠ CPAF — Cost Plus Award Fee | ⚠ chi phí thực tế + phí THƯỞNG do người mua đánh giá chủ quan | | ⚠ CPPC — Cost Plus Percentage of Cost | ⚠ phí theo % chi phí — bị coi là RỦI RO NHẤT vì càng tiêu nhiều càng lời |

Từ khoá nhận diện:

"hoá đơn ghi số giờ và vật tư" → ⚠ T&M "một con số cố định" → ⚠ fixed price "chi phí thực tế cộng phí" → ⚠ cost reimbursable "càng làm lâu càng được trả nhiều" → ⚠ T&M — nên phải đặt trần

⚠ Điều Nancy cần kiểm tra trên hoá đơn T&M Kiểm tra
⚠ Số giờ có khớp với thực tế quan sát được không
⚠ Đơn giá có đúng như hợp đồng không
⚠ Vật tư có đúng loại và số lượng đã duyệt không
⚠ Tổng có vượt TRẦN hợp đồng chưa ⚠ not-to-exceed clause
⚠ Nếu hợp đồng không có trần ⚠ đó là lỗ hổng cần khắc phục ngay
⚠ Vì sao T&M hợp với dự án agile Lý do
⚠ Phạm vi trong agile CỐ Ý để mở
⚠ Hợp đồng giá cố định đòi phạm vi chốt — mâu thuẫn với agile
⚠ T&M cho phép điều chỉnh theo backlog thay đổi
⚠ Cách kiểm soát ⚠ đặt trần theo từng sprint hoặc theo từng đợt phát hành

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng T&M của bạn có trần chưa | | | Ai xác nhận số giờ nhà thầu khai | | | Đơn giá từng loại nhân công có ghi rõ trong hợp đồng không | |

Và điểm yếu cố hữu của T&M mà người mua phải bù bằng kiểm soát: nhà cung cấp không có động lực làm nhanh. Trần hợp đồng và việc xác nhận giờ công là hai lớp bảo vệ bắt buộc.

Câu 44 Process
Doreen's company makes bottled soft drinks marketed to an affluent market that prefers organic food. The soft drinks are made from fruit sourced from a local orchard, which Doreen occasionally visits. On one visit, she notices that the orchard is selling its fruit directly to consumers, who are willing to wait in long lines. After conferring with the orchard's owner, Doreen redesigns her soft drinks to include the orchard's name on the label. Shortly after, Doreen's customers begin visiting the orchard from distant locations, and she begins selling her soft drinks there. Which quality management practice does this entail?
  1. A Management responsibility
  2. B Continual improvement
  3. C Customer satisfaction
  4. D Mutually beneficial partnerships
Xem giải thích

Đáp án

D — Mutually beneficial partnerships (quan hệ đối tác đôi bên cùng có lợi).

Vì sao đúng

⚠ Vì sao đây là quan hệ đôi bên cùng lợi: | Bên | Được gì | |---|---| | ⚠ Doreen | ⚠ sản phẩm có uy tín từ tên nhà vườn, bán được thêm tại chỗ nhà vườn | | ⚠ Nhà vườn | ⚠ được quảng bá tên tuổi trên nhãn chai, khách từ xa tìm tới | | ⚠ Cả hai | ⚠ cùng tăng doanh thu nhờ hợp tác, không bên nào thiệt | | ⚠ Cách làm | ⚠ BÀN BẠC với chủ nhà vườn trước khi thay đổi nhãn — không tự ý dùng tên người khác | | ⚠ Kết luận | ⚠ đúng nguyên tắc "quan hệ đối tác đôi bên cùng có lợi với nhà cung cấp" |

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

  • C (Customer satisfaction) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ khách hàng ĐÚNG là hài lòng hơn, ⚠ nhưng đó là KẾT QUẢ; ⚠ hành động cốt lõi của Doreen là ⚠ xây dựng quan hệ với NHÀ CUNG CẤP.

  • B (Continual improvement) — ⚠ nói về cải tiến QUY TRÌNH nội bộ; ⚠ Doreen thay đổi nhãn và kênh bán, không cải tiến quy trình sản xuất.

  • A (Management responsibility) — ⚠ nói về việc lãnh đạo cung cấp nguồn lực cho nhân viên.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25744 ở lô này về management responsibility và câu #25758 về customer satisfaction. ⚠ Ba câu dùng chung bốn phương án về nguyên tắc quản lý chất lượng — đây là bộ ba nên học cùng lúc.

⚠ Ba câu cùng bộ phương án trong lô này: | Câu | Bối cảnh | Khoá | |---|---|---| | ⚠ #25744 | ⚠ giám đốc kiểm tra hằng tuần xem quản lý dự án có đủ tiền, người, công nghệ | ⚠ management responsibility | | ⚠ #25758 | ⚠ thuê công ty khảo sát cộng đồng game hằng tháng | ⚠ customer satisfaction | | ⚠ #25766 | ⚠ hợp tác với nhà vườn, ghi tên lên nhãn | ⚠ mutually beneficial partnerships | | ⚠ Cách phân biệt | ⚠ hướng NỘI BỘ với nhân viên → management responsibility; hướng RA khách hàng → customer satisfaction; hướng tới NHÀ CUNG CẤP → partnerships |

⚠ Năm nguyên tắc quản lý chất lượng: | Nguyên tắc | Đối tượng | |---|---| | ⚠ Customer satisfaction | ⚠ khách hàng | | ⚠ Prevention over inspection | ⚠ quy trình sản xuất | | ⚠ Continual improvement | ⚠ quy trình nội bộ | | ⚠ Management responsibility | ⚠ nhân viên và nguồn lực | | ⚠ Mutually beneficial partnerships | ⚠ NHÀ CUNG CẤP — CÂU NÀY |

Từ khoá nhận diện:

"hợp tác với nhà cung cấp, cả hai cùng lợi" → ⚠ mutually beneficial partnerships "khảo sát và đáp ứng kỳ vọng khách" → ⚠ customer satisfaction "cải tiến quy trình nội bộ" → ⚠ continual improvement "lãnh đạo cấp nguồn lực" → ⚠ management responsibility

⚠ Vì sao quan hệ nhà cung cấp lại thuộc quản lý CHẤT LƯỢNG Lý do
⚠ Chất lượng đầu vào quyết định chất lượng đầu ra ⚠ trái cây kém thì nước ép không thể ngon
⚠ Quan hệ LÂU DÀI cho chất lượng ổn định hơn ép giá từng lô
⚠ Nhà cung cấp tin cậy sẽ ưu tiên bạn khi khan hàng
⚠ Chia sẻ thông tin giúp cả hai cải tiến
⚠ Nguyên tắc Deming ⚠ "chấm dứt việc chọn nhà cung cấp chỉ dựa trên giá thấp nhất"
⚠ Điều Doreen làm ĐÚNG về mặt nghiệp vụ Điểm
⚠ BÀN BẠC trước với chủ nhà vườn ⚠ không tự ý dùng tên người khác — vừa đúng luật vừa đúng đạo đức
⚠ Tạo giá trị cho CẢ HAI bên
⚠ Quan sát thị trường rồi mới hành động ⚠ thấy khách xếp hàng dài ở nhà vườn
⚠ Mở thêm kênh bán tại chỗ nhà vườn ⚠ tận dụng lưu lượng khách có sẵn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quan hệ nhà cung cấp của bạn là đối tác hay chỉ mua bán | | | Bạn có chia sẻ dự báo nhu cầu với họ không | ⚠ giúp họ chuẩn bị, giảm rủi ro thiếu hàng | | Chọn nhà cung cấp có chỉ dựa vào giá không | |

Và điểm khác biệt giữa "mua hàng" và "đối tác": mua hàng là tối ưu từng giao dịch, đối tác là tối ưu cả chuỗi giá trị. Doreen đã chuyển từ vế đầu sang vế sau, và cả hai bên đều lời.

Câu 45 Business Environment
Paulina is the project manager for Project Beehive, which is nearing its final week of implementation and is getting ready to deploy multiple deliverables across several departments. A few stakeholders are concerned they will receive the wrong deliverables because they work in more than one department. How can Paulina handle these concerns?
  1. A Thoroughly document and share the delivery process with stakeholders.
  2. B Ask the stakeholders to come and get their deliverables personally.
  3. C Hire a third party to assist.
  4. D Assign a team member to deliver everything.
Xem giải thích

Đáp án

A — GHI RÕ và CHIA SẺ quy trình bàn giao với các bên liên quan.

Vì sao đúng

⚠ Vấn đề và giải pháp: | Vấn đề | Giải pháp | |---|---| | ⚠ Bên liên quan làm việc ở NHIỀU phòng ban | ⚠ dễ nhầm ai nhận bàn giao nào | | ⚠ Họ LO nhận nhầm | ⚠ nỗi lo đến từ việc KHÔNG BIẾT quy trình | | ⚠ Nhiều bàn giao, nhiều phòng ban, cùng lúc | ⚠ độ phức tạp cao | | ⚠ Giải pháp đúng | ⚠ làm rõ bằng VĂN BẢN: bàn giao nào, cho phòng ban nào, ai nhận, khi nào, xác nhận thế nào |

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

  • D (giao một thành viên đội chuyển giao tất cả) — ⚠ tạo NÚT THẮT CỔ CHAI và ⚠ vẫn không giải quyết nỗi lo: ⚠ bên liên quan vẫn không biết mình sẽ nhận gì.

  • B (bảo bên liên quan tự tới lấy) — ⚠ đẩy gánh nặng sang họ và ⚠ càng tăng khả năng nhầm lẫn.

  • C (thuê bên thứ ba hỗ trợ) — ⚠ tốn kém không cần thiết; ⚠ vấn đề là THÔNG TIN, không phải thiếu nhân lực.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25736 ở lô này về truyền đạt trạng thái để bên liên quan không bị bất ngờ và câu #25726 ở lô 179. ⚠ Ba câu cùng một gốc: phần lớn nỗi lo của bên liên quan được giải quyết bằng THÔNG TIN RÕ RÀNG, không phải bằng nguồn lực thêm.

⚠ Tài liệu bàn giao nên có gì: | Mục | Nội dung | |---|---| | ⚠ Danh sách TỪNG bàn giao | ⚠ mã, tên, mô tả | | ⚠ Phòng ban NHẬN | | | ⚠ NGƯỜI NHẬN cụ thể và người dự phòng | ⚠ giải quyết trực tiếp vấn đề người làm nhiều phòng ban | | ⚠ NGÀY GIỜ bàn giao | | | ⚠ CÁCH XÁC NHẬN đã nhận | ⚠ ký nhận, email xác nhận | | ⚠ Người liên hệ khi có vấn đề | | | ⚠ Quy trình xử lý khi nhận sai | | | ⚠ Chia sẻ TRƯỚC ngày bàn giao | ⚠ để bên liên quan có thời gian kiểm tra và phản hồi |

Từ khoá nhận diện:

"bên liên quan lo lắng vì không rõ quy trình" → ⚠ làm rõ bằng văn bản và chia sẻ "giao một người làm hết" → ⚠ tạo nút thắt, thường là đáp án sai "thuê bên thứ ba" → ⚠ tốn kém, thường không cần thiết "để họ tự lo" → ⚠ đẩy trách nhiệm, luôn sai

⚠ Vì sao nỗi lo này CHÍNH ĐÁNG Lý do
⚠ Nhận nhầm bàn giao gây gián đoạn công việc
⚠ Một người ở nhiều phòng ban thì dễ bị bỏ sót hoặc trùng lặp
⚠ Dự án đang ở TUẦN CUỐI — không còn thời gian sửa sai
⚠ Bài học ⚠ bàn giao là giai đoạn rủi ro cao mà hay bị lập kế hoạch sơ sài nhất
⚠ Paulina nên làm thêm gì Việc
⚠ Xác nhận lại danh sách người nhận với từng phòng ban
⚠ Làm thử một đợt bàn giao nhỏ trước ⚠ pilot
⚠ Chuẩn bị kênh hỗ trợ trong ngày bàn giao
⚠ Có kế hoạch xử lý nếu ai đó nhận sai
⚠ Ghi nhận và xác nhận đã nhận đủ ⚠ đây cũng là bước hướng tới Validate Scope

⚠ Đối chiếu: ⚠ câu #25666 ở lô 178 về Control Quality rồi Validate Scope. ⚠ Bàn giao thành công và được xác nhận chính là đầu vào của việc nghiệm thu chính thức.

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Danh sách người nhận đã được xác nhận chưa | | | Bên liên quan có biết mình sẽ nhận gì không | | | Có cách xác nhận đã nhận không | ⚠ thiếu là sau này không ai chứng minh được |

Và nguyên tắc cho mọi đợt bàn giao lớn: không ai được bất ngờ vào ngày bàn giao. Tài liệu gửi trước vài ngày rẻ hơn nhiều so với một tuần dọn hậu quả.

Câu 46 Process
Diane wants to ensure that her team at Bronn’s Ponds is on the same page regarding the look and feel of their software project. She wants to show what each screen looks like and how they flow between each other. Her best agile tool is
  1. A A process flow diagram
  2. B A wireframe
  3. C A persona
  4. D A data model
Xem giải thích

Đáp án

B — A wireframe (khung giao diện).

Vì sao đúng

⚠ Wireframe là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Bản phác THÔ của từng MÀN HÌNH | ⚠ bố cục, vị trí các phần tử | | ⚠ Cho thấy LUỒNG CHUYỂN giữa các màn hình | ⚠ đúng điều Diane cần | | ⚠ KHÔNG đi vào màu sắc và chi tiết thẩm mỹ | ⚠ tập trung vào cấu trúc và luồng | | ⚠ Nhanh, rẻ, dễ sửa | | | ⚠ Mục đích | ⚠ để cả đội thống nhất về "hình dáng" sản phẩm trước khi lập trình |

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

  • A (Process flow diagram — sơ đồ luồng quy trình) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nó vẽ ⚠ LUỒNG CÔNG VIỆC hoặc luồng nghiệp vụ, ⚠ không vẽ ⚠ hình dáng từng MÀN HÌNH; ⚠ Diane muốn thấy cả hai: màn hình trông thế nào VÀ chuyển qua lại ra sao.

  • C (Persona — chân dung người dùng) — ⚠ mô tả một NGƯỜI DÙNG điển hình: ⚠ tên, tuổi, mục tiêu, khó khăn; ⚠ giúp hiểu người dùng chứ không mô tả giao diện.

  • D (Data model — mô hình dữ liệu) — ⚠ mô tả CẤU TRÚC DỮ LIỆU và quan hệ giữa các thực thể, ⚠ không liên quan tới giao diện.

Ghi nhớ

⚠ Các công cụ trực quan trong dự án agile: | Công cụ | Cho thấy điều gì | |---|---| | ⚠ Wireframe | ⚠ BỐ CỤC màn hình và luồng chuyển — CÂU NÀY | | ⚠ Mockup | ⚠ giao diện chi tiết hơn, có màu sắc và kiểu chữ | | ⚠ Prototype | ⚠ bản chạy được, bấm được, tương tác được | | ⚠ Persona | ⚠ chân dung người dùng điển hình | | ⚠ User story map | ⚠ hành trình người dùng, sắp xếp backlog theo hành trình đó | | ⚠ Process flow diagram | ⚠ luồng nghiệp vụ hoặc luồng công việc | | ⚠ Data model | ⚠ cấu trúc dữ liệu |

Từ khoá nhận diện:

"từng màn hình trông thế nào, chuyển qua lại ra sao" → ⚠ wireframe "bản chạy được để thử" → ⚠ prototype "người dùng của chúng ta là ai" → ⚠ persona "quy trình nghiệp vụ chạy thế nào" → ⚠ process flow diagram "dữ liệu lưu ra sao" → ⚠ data model

⚠ Thang độ chi tiết của bản thiết kế giao diện: | Mức | Tên | Đặc điểm | |---|---|---| | ⚠ 1 — thô nhất | ⚠ Sketch trên giấy | ⚠ vài phút, dùng để bàn nhanh | | ⚠ 2 | ⚠ Wireframe | ⚠ bố cục và luồng, thường đen trắng | | ⚠ 3 | ⚠ Mockup | ⚠ có màu, có kiểu chữ, gần giống thật | | ⚠ 4 — chi tiết nhất | ⚠ Prototype | ⚠ bấm được, mô phỏng tương tác thật | | ⚠ Nguyên tắc | ⚠ dùng mức THÔ NHẤT đủ để trả lời câu hỏi đang có — chi tiết sớm là lãng phí |

⚠ Vì sao wireframe hợp với nhu cầu của Diane Lý do
⚠ Cô ấy muốn cả đội THỐNG NHẤT về hình dung ⚠ không cần bản đẹp
⚠ Cần thấy LUỒNG giữa các màn hình ⚠ wireframe nối bằng mũi tên là đủ
⚠ Ở giai đoạn còn dễ sửa ⚠ sửa wireframe mất vài phút, sửa mã mất vài ngày
⚠ Là công cụ GIAO TIẾP, không phải sản phẩm
⚠ Lợi ích lớn nhất ⚠ phát hiện hiểu lầm về yêu cầu TRƯỚC khi viết dòng mã nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn cần trả lời câu hỏi gì | ⚠ chọn mức chi tiết vừa đủ | | Wireframe có được người dùng thật xem chưa | ⚠ đội đồng ý chưa chắc người dùng đồng ý | | Có nguy cơ tranh cãi về màu sắc thay vì về luồng không | ⚠ đó là lý do wireframe cố ý để đen trắng |

Và lý do wireframe cố tình vẽ xấu: bản vẽ càng đẹp thì người xem càng bàn về thẩm mỹ thay vì bàn về cấu trúc. Giai đoạn này Diane cần đội thống nhất về luồng, không cần họ tranh luận về màu nút bấm.

Câu 47 Process
Mary is the project manager for her organization and she is working with her project team to identify the project's business value. Several risks affecting the business value need to be addressed, and Mary wants to be certain that these risks are mitigated early in the project. Which of the following is true of the Pareto Principle (the 80/20 principle)?
  1. A 80 percent of a project's problems are due to 20 percent of the root causes.
  2. B 20 percent of the project schedule is allocated to 80 percent of the scope.
  3. C 20percent of a project's problems are due to 80 percent of resources.
  4. D 80 percent of the project budget is allocated to 20 percent of the scope. 
Xem giải thích

Đáp án

A — 80% vấn đề của dự án đến từ 20% NGUYÊN NHÂN GỐC.

Vì sao đúng

⚠ Nguyên lý Pareto: | Nội dung | Ý nghĩa | |---|---| | ⚠ PHẦN LỚN hậu quả đến từ MỘT PHẦN NHỎ nguyên nhân | | | ⚠ Tỷ lệ 80/20 là con số MINH HOẠ, không phải luật chính xác | | | ⚠ Áp dụng trong quản lý chất lượng | ⚠ 80% khuyết tật từ 20% nguyên nhân | | ⚠ Ứng dụng thực tế | ⚠ sửa đúng 20% nguyên nhân đó là giải quyết phần lớn vấn đề | | ⚠ Với Mary | ⚠ tập trung xử lý một số ít rủi ro trọng yếu sẽ bảo vệ được phần lớn giá trị kinh doanh |

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

  • B (20% lịch trình dành cho 80% phạm vi) — ⚠ không phải nội dung của nguyên lý Pareto; ⚠ đây là phát biểu bịa về lịch trình.

  • D (80% ngân sách dành cho 20% phạm vi) — ⚠ cũng là phát biểu bịa; ⚠ Pareto nói về quan hệ NGUYÊN NHÂN – HẬU QUẢ, không nói về phân bổ ngân sách.

  • C (20% vấn đề đến từ 80% nguồn lực) — ⚠ ĐẢO NGƯỢC tỷ lệ và sai cả đối tượng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25626 ở lô 177 và câu #25690 ở lô 179 — ⚠ cả hai đều về biểu đồ Pareto. ⚠ Hai câu kia hỏi CÔNG CỤ, câu này hỏi NGUYÊN LÝ đằng sau công cụ đó.

⚠ Từ nguyên lý tới công cụ: | Bước | Nội dung | |---|---| | ⚠ NGUYÊN LÝ Pareto | ⚠ ít nguyên nhân gây phần lớn hậu quả — CÂU NÀY | | ⚠ CÔNG CỤ: biểu đồ Pareto | ⚠ xếp hạng nguyên nhân theo tần suất, có đường luỹ kế | | ⚠ HÀNH ĐỘNG | ⚠ dồn sức vào vài cột cao nhất | | ⚠ KIỂM CHỨNG | ⚠ vẽ lại sau một vòng cải tiến |

Từ khoá nhận diện:

"80/20" → ⚠ nguyên lý Pareto: ít nguyên nhân, nhiều hậu quả "xếp hạng từ lớn tới nhỏ" → ⚠ biểu đồ Pareto "vital few and trivial many" → ⚠ cách nói khác của cùng nguyên lý "tập trung vào cái quan trọng nhất trước" → ⚠ ứng dụng của Pareto

⚠ Ứng dụng Pareto trong quản lý RỦI RO Ứng dụng
⚠ Ít rủi ro trọng yếu gây phần lớn thiệt hại tiềm tàng
⚠ Xếp hạng rủi ro theo EMV hoặc theo ma trận xác suất – tác động
⚠ Dồn nguồn lực ứng phó vào nhóm trên cùng ⚠ đúng điều Mary muốn làm
⚠ Nhóm còn lại: theo dõi trong danh sách quan sát ⚠ watch list
⚠ Lợi ích ⚠ nguồn lực ứng phó luôn hữu hạn — phải chọn
⚠ Các lĩnh vực khác áp dụng được nguyên lý này Lĩnh vực
⚠ Chất lượng ⚠ ít loại khuyết tật gây phần lớn số lỗi
⚠ Rủi ro ⚠ ít rủi ro gây phần lớn thiệt hại
⚠ Bên liên quan ⚠ ít người có ảnh hưởng quyết định nhất
⚠ Chi phí ⚠ ít hạng mục chiếm phần lớn ngân sách
⚠ Yêu cầu ⚠ ít tính năng tạo phần lớn giá trị — cơ sở của việc xếp ưu tiên backlog
⚠ Lưu ý khi dùng nguyên lý này Lưu ý
⚠ 80/20 là ƯỚC LỆ, không phải con số cứng ⚠ có khi là 70/30 hoặc 90/10
⚠ Phải có DỮ LIỆU mới biết 20% đó là cái nào
⚠ Đừng bỏ hoàn toàn 80% còn lại ⚠ chỉ là ưu tiên sau
⚠ Sai lầm ⚠ dùng nguyên lý để biện minh cho việc bỏ qua mọi thứ khác

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có dữ liệu để biết 20% quan trọng là cái nào không | | | Nguồn lực có đang dồn vào nhóm đó không | | | Nhóm còn lại có được theo dõi không | |

Và cách phát biểu gốc của Juran cho nguyên lý này: "vital few and trivial many" — một số ít then chốt và rất nhiều thứ vặt vãnh. Việc của quản lý dự án là phân biệt được hai nhóm đó.

Câu 48 Process
Management has asked you, the project manager of the KJU Project, to provide an estimate of the project costs. Their decision to move forward with the project will be based on your initial estimate. You have just started the project, so what estimate type will you likely provide?
  1. A Bottom-up
  2. B Rough order of magnitude
  3. C Definitive
  4. D Budget
Xem giải thích

Đáp án

B — Rough order of magnitude (ước lượng thô — ROM).

Vì sao đúng

⚠ Dấu hiệu trong đề: | Chi tiết | Suy ra | |---|---| | ⚠ "Bạn VỪA MỚI bắt đầu dự án" | ⚠ → thông tin còn RẤT ÍT | | ⚠ Lãnh đạo cần con số để QUYẾT ĐỊNH có làm hay không | ⚠ → đây là giai đoạn khởi tạo, chưa cam kết | | ⚠ "ước lượng BAN ĐẦU" | ⚠ → initial estimate | | ⚠ Kết luận | ⚠ chỉ ROM là phù hợp — dải sai số −25% đến +75% |

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

  • C (Definitive — ước lượng dứt khoát) — ⚠ đòi WBS đầy đủ và ước lượng bottom-up; ⚠ chưa thể có ở thời điểm này.

  • A (Bottom-up) — ⚠ là PHƯƠNG PHÁP tạo ra ước lượng dứt khoát, ⚠ cũng đòi WBS chi tiết.

  • D (Budget estimate) — ⚠ chính xác hơn ROM (⚠ khoảng −10% đến +25%), ⚠ đòi ít nhất phải có tuyên bố phạm vi; ⚠ đây là phương án gây nhiễu mạnh nhất vì nghe hợp lý với việc "ra quyết định về ngân sách".

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25613 ở lô 177 (ROM ngoài hành lang), câu #25647 ở lô 178 (ước lượng dứt khoát cần WBS) và câu #25717 ở lô 179 (điều lệ chứa ngân sách tóm tắt). ⚠ Bốn câu tạo thành bộ đầy đủ về thang độ chính xác ước lượng — chủ đề được hỏi nhiều nhất trong nhóm quản lý chi phí.

⚠ Thang độ chính xác ước lượng: | Loại | Dải sai số | Cần gì | Khi nào | |---|---|---|---| | ⚠ ROM | ⚠ −25% đến +75% | ⚠ rất ít thông tin | ⚠ KHỞI TẠO — CÂU NÀY | | ⚠ Budget / Preliminary | ⚠ −10% đến +25% | ⚠ tuyên bố phạm vi | ⚠ đầu giai đoạn lập kế hoạch | | ⚠ Definitive | ⚠ −5% đến +10% | ⚠ WBS chi tiết | ⚠ cuối giai đoạn lập kế hoạch |

Từ khoá nhận diện:

"vừa bắt đầu, ước lượng ban đầu" → ⚠ ROM "cần ngân sách đáng tin cậy" → ⚠ definitive, cần WBS "cộng từ từng gói công việc" → ⚠ bottom-up "quyết định có làm dự án không" → ⚠ giai đoạn khởi tạo, nên là ROM

⚠ Cách trình bày ROM cho đúng chuẩn nghề Cách
⚠ LUÔN nêu DẢI SAI SỐ kèm con số ⚠ "khoảng 500 triệu, dao động từ 375 tới 875 triệu"
⚠ LUÔN nêu rõ GIẢ ĐỊNH
⚠ Nói rõ đây là ROM, không phải cam kết
⚠ Hẹn thời điểm có con số chính xác hơn
⚠ Ghi lại bằng văn bản ⚠ con số nói miệng rất dễ biến thành ngân sách chính thức
⚠ Rủi ro nghề nghiệp ⚠ đưa một con số trần trụi ở giai đoạn này là tự đặt bẫy cho chính mình
⚠ Hình nón bất định — cone of uncertainty Nội dung
⚠ Đầu dự án: dải sai số RỘNG nhất
⚠ Càng về sau dải càng HẸP
⚠ Ước lượng lại ở mỗi cột mốc quan trọng
⚠ Sai lầm phổ biến nhất ⚠ giữ nguyên con số ban đầu suốt dự án rồi bị đánh giá là "vượt ngân sách"
⚠ Vì sao lãnh đạo vẫn chấp nhận ROM Lý do
⚠ Họ cần quyết định NHANH có đầu tư hay không
⚠ Chi phí làm ước lượng chi tiết cho một dự án CHƯA được duyệt là lãng phí
⚠ Dải rộng vẫn đủ để loại các dự án rõ ràng không khả thi
⚠ Điều kiện ⚠ họ phải HIỂU đó là dải rộng — nhiệm vụ của PM là nói rõ điều này

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn đã nêu dải sai số chưa | | | Lãnh đạo có hiểu đây là con số thô không | | | Con số này có bị dùng làm ngân sách chính thức không | ⚠ nếu có thì phải ước lượng lại trước khi chốt |

Và bài học tự bảo vệ của nghề quản lý dự án: ước lượng thô không kèm dải sai số sẽ được nhớ như một cam kết. Nói rõ "cộng trừ bao nhiêu" ngay từ đầu là cách rẻ nhất để tránh rắc rối về sau.

Câu 49 People
Cathy is the scrum master for Project M, which is in its planning stage and has a budget of $75,000. Cathy notices that a stakeholder has asked for time to send the project team to assess their personalities. When asked why, how is the stakeholder likely to respond?
  1. A The stakeholder owns a personality assessment company.
  2. B Understanding how everyone on the team works will help them work better together.
  3. C The stakeholder has an extra budget they want to spend.
  4. D This is standard practice in agile.
Xem giải thích

Đáp án

B — Hiểu được cách làm việc của từng người sẽ giúp cả đội phối hợp tốt hơn.

Vì sao đúng

⚠ Mục đích của đánh giá tính cách trong đội dự án: | Mục đích | Nội dung | |---|---| | ⚠ Hiểu PHONG CÁCH LÀM VIỆC của từng người | ⚠ ai thích chi tiết, ai thích tổng thể, ai cần thời gian suy nghĩ | | ⚠ Hiểu cách mỗi người GIAO TIẾP và tiếp nhận phản hồi | | | ⚠ Giảm hiểu lầm và xung đột không cần thiết | | | ⚠ Phân công công việc phù hợp hơn | | | ⚠ Rút ngắn giai đoạn Storming | ⚠ hiểu nhau sớm thì cãi nhau ít hơn | | ⚠ Thời điểm | ⚠ dự án đang ở giai đoạn LẬP KẾ HOẠCH — đúng lúc để làm việc này |

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

  • D (đây là thực hành chuẩn trong agile) — ⚠ KHÔNG đúng: ⚠ agile không bắt buộc đánh giá tính cách; ⚠ đây là công cụ hữu ích nhưng không phải nghi thức chuẩn.

  • A (bên liên quan sở hữu công ty đánh giá tính cách) — ⚠ cáo buộc xung đột lợi ích không có căn cứ trong đề.

  • C (bên liên quan có ngân sách thừa muốn tiêu) — ⚠ diễn giải tiêu cực và vô căn cứ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25700 ở lô 179 về giai đoạn Storming và câu #25743 ở lô này về xây dựng đội. ⚠ Ba câu cùng chủ đề phát triển đội dự án.

⚠ Individual and team assessments — công cụ của Develop Team: | Công cụ | Đo gì | |---|---| | ⚠ Khảo sát thái độ | ⚠ mức hài lòng và gắn kết | | ⚠ Đánh giá chuyên biệt | ⚠ đánh giá cụ thể theo tiêu chí công việc | | ⚠ Phỏng vấn có cấu trúc | | | ⚠ Bài kiểm tra năng lực | | | ⚠ Nhóm tập trung | | | ⚠ ĐÁNH GIÁ TÍNH CÁCH | ⚠ CÂU NÀY — hiểu phong cách làm việc và giao tiếp | | ⚠ Mục đích chung | ⚠ giúp PM và đội hiểu điểm mạnh, điểm yếu, và cách phối hợp |

Từ khoá nhận diện:

"đánh giá tính cách đội" → ⚠ hiểu nhau để phối hợp tốt hơn "đội cãi nhau về vai trò" → ⚠ Storming, cần làm rõ vai trò "người mới ngần ngại" → ⚠ team building "đo mức hài lòng" → ⚠ khảo sát thái độ

⚠ Lợi ích cụ thể trong dự án Lợi ích
⚠ Biết ai cần thông tin CHI TIẾT, ai chỉ cần TỔNG QUAN ⚠ điều chỉnh cách báo cáo
⚠ Biết ai cần thời gian suy nghĩ trước khi phát biểu ⚠ gửi tài liệu trước buổi họp — chính là brainwriting
⚠ Biết ai nhận phản hồi trực tiếp được, ai cần nói riêng
⚠ Ghép cặp làm việc hiệu quả hơn
⚠ Với ngân sách 75.000 ⚠ chi phí đánh giá thường nhỏ so với chi phí một cuộc xung đột kéo dài
⚠ Cảnh báo khi dùng đánh giá tính cách Cảnh báo
⚠ ĐỪNG dùng để dán nhãn hoặc loại người ⚠ mục đích là hiểu nhau, không phải phân loại để sàng lọc
⚠ Kết quả là XU HƯỚNG, không phải định mệnh
⚠ Tham gia nên trên tinh thần TỰ NGUYỆN
⚠ Chia sẻ kết quả cần được người đó đồng ý
⚠ Dùng sai ⚠ có thể phản tác dụng, tạo định kiến trong đội

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có biết phong cách làm việc của từng thành viên không | | | Cách bạn giao tiếp có điều chỉnh theo từng người không | | | Kết quả đánh giá có được dùng đúng mục đích không | |

Và giá trị thật của việc này ở giai đoạn lập kế hoạch: hiểu nhau trước khi áp lực ập tới. Khi dự án căng thẳng, đội đã hiểu nhau sẽ tranh luận về vấn đề — đội chưa hiểu nhau sẽ tranh luận về con người.

Câu 50 Business Environment
At Consumer Recreation Services, a highly successful agile organization, their primary measure of progress is
  1. A How much of the solution has been approved by the product owner, which they track on a Gantt chart.
  2. B The development of working software, rather than fully comprehensive documentation.
  3. C The percentage of time spent on bugs vs. the original development work, which they track on a team analysis report each cycle.
  4. D How much of the solution is designed, which they track on a burndown chart.
Xem giải thích

Đáp án

B — Việc phát triển PHẦN MỀM CHẠY ĐƯỢC, thay vì tài liệu đầy đủ toàn diện.

Vì sao đúng

⚠ Nguyên tắc gốc của Tuyên ngôn Agile:

⚠ "Working software is the primary measure of progress." — ⚠ phần mềm chạy được là thước đo tiến độ CHÍNH.

Lý do Nội dung
⚠ Tài liệu KHÔNG chứng minh được điều gì hoạt động
⚠ Phần trăm hoàn thành do người ta TỰ BÁO có thể sai
⚠ Phần mềm chạy được thì AI CŨNG KIỂM CHỨNG ĐƯỢC
⚠ Loại bỏ tình trạng "90% xong" kéo dài mãi
⚠ Đây cũng là ⚠ một trong bốn giá trị của Tuyên ngôn Agile: phần mềm chạy được hơn tài liệu đầy đủ

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

  • A (phần giải pháp được product owner phê duyệt, theo dõi trên biểu đồ Gantt) — ⚠ SAI ở công cụ: ⚠ biểu đồ Gantt là công cụ của cách tiếp cận DỰ ĐOÁN, ⚠ không phải thước đo tiến độ chính của agile.

  • D (phần giải pháp đã được THIẾT KẾ, theo dõi trên burndown) — ⚠ SAI ở đối tượng đo: ⚠ "đã thiết kế" KHÔNG phải "chạy được"; ⚠ thiết kế xong mà chưa chạy thì chưa có giá trị nào được giao.

  • C (tỷ lệ thời gian sửa lỗi so với phát triển mới) — ⚠ là một CHỈ SỐ CHẤT LƯỢNG hữu ích, ⚠ nhưng không phải thước đo TIẾN ĐỘ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25750 ở lô này về sprint review và câu #25738 về giao nhanh nhưng lệch mục tiêu. ⚠ Ba câu bổ sung nhau: phần mềm chạy được là thước đo, sprint review là nơi chứng minh, nhưng vẫn phải kiểm tra nó có mang lại GIÁ TRỊ đúng không.

⚠ Bốn giá trị của Tuyên ngôn Agile: | Coi trọng hơn | So với | |---|---| | ⚠ CÁ NHÂN và TƯƠNG TÁC | ⚠ quy trình và công cụ | | ⚠ PHẦN MỀM CHẠY ĐƯỢC | ⚠ tài liệu đầy đủ toàn diện — CÂU NÀY | | ⚠ HỢP TÁC với khách hàng | ⚠ đàm phán hợp đồng | | ⚠ ỨNG PHÓ với thay đổi | ⚠ bám theo kế hoạch | | ⚠ Lưu ý quan trọng | ⚠ vế bên phải VẪN CÓ GIÁ TRỊ — chỉ là vế bên trái được coi trọng HƠN; agile không có nghĩa là không viết tài liệu |

Từ khoá nhận diện:

"thước đo tiến độ chính của agile" → ⚠ phần mềm chạy được "biểu đồ Gantt" → ⚠ công cụ của cách tiếp cận dự đoán "đã thiết kế xong" → ⚠ chưa phải chạy được "tỷ lệ sửa lỗi" → ⚠ chỉ số chất lượng, không phải tiến độ

⚠ Vì sao "phần mềm chạy được" là thước đo tốt nhất Lý do
⚠ KHÁCH QUAN — chạy hoặc không chạy
⚠ KIỂM CHỨNG được bởi bất kỳ ai
⚠ Tạo ra GIÁ TRỊ thật, không chỉ tạo ra công việc
⚠ Ép đội hoàn thiện HẾT một tính năng thay vì làm dở nhiều tính năng
⚠ Điều kiện ⚠ phải có ĐỊNH NGHĨA DONE rõ ràng — nếu không thì "chạy được" cũng thành khái niệm mơ hồ
⚠ Các chỉ số đo tiến độ trong agile Chỉ số
⚠ Số hạng mục backlog ĐÃ DONE ⚠ thước đo chính
⚠ Velocity ⚠ điểm story hoàn thành mỗi vòng lặp
⚠ Burndown / burnup chart ⚠ công việc còn lại hoặc đã làm
⚠ Cumulative flow diagram ⚠ phát hiện nút thắt
⚠ Lead time và cycle time ⚠ thời gian từ khi yêu cầu tới khi giao
⚠ Điểm chung ⚠ mọi chỉ số đều dựa trên thứ ĐÃ HOÀN THÀNH, không dựa trên thứ đang làm dở
⚠ 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 tài liệu VỪA ĐỦ, không viết tài liệu thừa
⚠ "Không cần thiết kế" ⚠ SAI — thiết kế vẫn cần, chỉ là không đo tiến độ bằng nó
⚠ "Chạy được là xong" ⚠ SAI — phải đạt Definition of Done, gồm cả kiểm thử

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Định nghĩa DONE của đội có gồm kiểm thử không | | | Bạn báo cáo tiến độ bằng thứ đã chạy hay bằng phần trăm ước lượng | | | Tài liệu bạn viết có ai đọc không | ⚠ không ai đọc thì đó là tài liệu thừa |

Và câu tổng kết của nguyên tắc này: thứ chạy được không cãi được. Mọi báo cáo phần trăm đều là ước lượng, còn phần mềm demo trước mặt bên liên quan là bằng chứng.