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

Tìm thấy 720 câu.

Câu 191 People
Phil is a scrum master at Project Corporation. After a recent planning session, Phil overheard two stakeholders complaining that they do not understand what a story point is. What should Phil do?
  1. A Assign a team member to train the stakeholders.
  2. B Briefly remind them and then follow up with additional material.
  3. C Do nothing. The product owner will fill them in.
  4. D Do nothing. Stakeholders do not need to worry about story points.
Xem giải thích

Đáp án

B — NHẮC NGẮN GỌN ngay lúc đó rồi THEO SAU bằng tài liệu bổ sung.

Vì sao đúng

⚠ Vì sao cách xử lý này đúng: | Lý do | Nội dung | |---|---| | ⚠ Scrum Master là NGƯỜI HUẤN LUYỆN — cho cả bên liên quan | ⚠ không chỉ huấn luyện đội | | ⚠ Xử lý NGAY khi nghe thấy | ⚠ hiểu lầm để lâu sẽ đông cứng lại | | ⚠ NGẮN GỌN vì đang giữa buổi khác | ⚠ không biến thành buổi đào tạo bất chợt | | ⚠ Gửi tài liệu SAU để họ tự đọc kỹ | ⚠ tôn trọng thời gian của họ | | ⚠ Cân bằng | ⚠ vừa giải quyết ngay, vừa không phá nhịp buổi họp |

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

  • D (không làm gì, bên liên quan không cần quan tâm story point) — ⚠ phương án gây nhiễu mạnh nhất vì có phần đúng: ⚠ story point ⚠ đúng là công cụ NỘI BỘ của đội; ⚠ nhưng bên liên quan ⚠ ĐỌC báo cáo có story point ⚠ và ⚠ đã nêu ra thắc mắc ⚠ — bỏ mặc thắc mắc đã nói ra là gạt bỏ người ta.

  • C (không làm gì, product owner sẽ nói lại) — ⚠ đẩy việc; ⚠ đây là trách nhiệm huấn luyện của Scrum Master, ⚠ và không có gì đảm bảo PO sẽ làm.

  • A (giao một thành viên đội đi đào tạo bên liên quan) — ⚠ đẩy việc xuống đội; ⚠ đội đang cần thời gian để làm sản phẩm.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25908 ở lô này (tổ chức mới dùng agile hiểu sai velocity), câu #25903 (biến động velocity), và câu #25905 (hướng phản hồi của bên liên quan vào backlog). ⚠ Cả nhóm cùng chủ đề Scrum Master huấn luyện tổ chức.

⚠ Story point là gì và không là gì: | LÀ | KHÔNG LÀ | |---|---| | ⚠ Ước lượng TƯƠNG ĐỐI về nỗ lực | ⚠ Không phải giờ công | | ⚠ Gộp cả độ phức tạp, khối lượng, bất định | ⚠ Không phải thước đo năng suất cá nhân | | ⚠ Do CẢ ĐỘI cùng ước lượng | ⚠ Không so sánh được giữa các đội | | ⚠ Dùng để đội tự dự báo sức chứa sprint | ⚠ Không phải cam kết với bên ngoài | | ⚠ Vì sao dùng số tương đối | ⚠ con người ước lượng SO SÁNH giỏi hơn ước lượng tuyệt đối |

Từ khoá nhận diện:

"bên liên quan không hiểu khái niệm agile" → ⚠ Scrum Master huấn luyện "không làm gì cả" → ⚠ gần như luôn là đáp án sai khi có người đã nêu thắc mắc "giao cho người khác" → ⚠ đẩy trách nhiệm "nhắc ngắn rồi gửi tài liệu" → ⚠ cân bằng đúng giữa kịp thời và không phá nhịp

⚠ Ba vai trò của Scrum Master Với ai
⚠ Với ĐỘI ⚠ huấn luyện tự tổ chức, gỡ vật cản, điều phối sự kiện
⚠ Với PRODUCT OWNER ⚠ giúp quản trị backlog, kỹ thuật xếp ưu tiên, làm rõ mục tiêu
⚠ Với TỔ CHỨC ⚠ dẫn dắt chuyển đổi agile, GIÁO DỤC bên liên quan — CÂU NÀY
⚠ Điểm hay bị quên ⚠ vai trò thứ ba là vai trò khó nhất và ít người làm đủ
⚠ Giải thích story point cho người ngoài thế nào Cách
⚠ Dùng phép so sánh đời thường ⚠ "leo đồi này khó gấp đôi leo đồi kia" — không nói mất bao nhiêu phút
⚠ Nhấn mạnh nó là công cụ DỰ BÁO của đội
⚠ Nói rõ vì sao KHÔNG quy ra giờ ⚠ quy ra giờ là mất hết ý nghĩa
⚠ Chỉ cho họ thứ họ THỰC SỰ quan tâm ⚠ giá trị đã giao, chứ không phải điểm
⚠ Tránh ⚠ giảng thuật ngữ Scrum — họ không cần biết từ vựng, họ cần hiểu ý nghĩa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo gửi bên liên quan có dùng thuật ngữ họ không hiểu không | | | Có ai từng hỏi mà bị bỏ qua chưa | | | Bên liên quan đo thành công của dự án bằng gì | ⚠ nếu là story point thì đang đo sai thứ |

Và dấu hiệu một Scrum Master làm tốt vai trò với tổ chức: những câu hỏi kiểu này ngày càng ít đi, chứ không phải càng ngày càng nhiều buổi đào tạo.

Câu 192 Process
Your team is in the design phase of a new door lock prototype controlled by a mobile app. Stakeholders want the lock to be secure and reliable and want to balance the cost of the materials for the best profit margin for the product. The team engineers identify which type of material will provide the most significant security strength at the lowest cost through a series of tests. From the options below, which is the most likely technique used to determine these variables?
  1. A Histogram
  2. B Design for X
  3. C Design of experiments
  4. D System flowchart
Xem giải thích

Đáp án

C — THIẾT KẾ THỰC NGHIỆM (Design of Experiments, DOE).

Vì sao đúng

⚠ Vì sao DOE là kỹ thuật đang được dùng: | Dấu hiệu trong đề | Ý nghĩa | |---|---| | ⚠ "qua một LOẠT THỬ NGHIỆM" | ⚠ chạy nhiều thí nghiệm có kế hoạch — đặc trưng DOE | | ⚠ Xác định loại VẬT LIỆU nào cho kết quả tốt nhất | ⚠ có biến độc lập cần thay đổi | | ⚠ Cân bằng ĐỘ BỀN AN NINH và CHI PHÍ | ⚠ tối ưu NHIỀU BIẾN cùng lúc — đúng mục đích DOE | | ⚠ Định nghĩa DOE | ⚠ phương pháp thống kê xác định yếu tố nào ảnh hưởng tới biến số cụ thể của sản phẩm hoặc quy trình | | ⚠ Lợi ích | ⚠ tìm điều kiện tối ưu với SỐ THÍ NGHIỆM ÍT NHẤT, thay vì thử từng yếu tố một |

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

  • B (Design for X) — ⚠ phương án gây nhiễu mạnh nhất vì cùng có chữ "Design" và cùng ở giai đoạn thiết kế: ⚠ nhưng DfX là ⚠ tập hợp NGUYÊN TẮC THIẾT KẾ ⚠ (thiết kế để dễ sản xuất, dễ lắp ráp, dễ bảo trì, giảm chi phí), ⚠ không phải phương pháp CHẠY THỬ NGHIỆM để tìm số liệu.

  • A (biểu đồ tần suất — histogram) — ⚠ công cụ HIỂN THỊ phân bố dữ liệu, ⚠ không phải cách thiết kế thí nghiệm.

  • D (lưu đồ hệ thống) — ⚠ mô tả luồng quy trình, ⚠ không liên quan tới việc chọn vật liệu.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25626/#25690/#25815/#25870 (biểu đồ Pareto — hỏi bốn lần), câu #25636 ở lô 178 (phòng ngừa và kiểm tra), và câu #25900 ở lô này (chất lượng ít bị ảnh hưởng nhất). ⚠ Nhóm công cụ chất lượng được hỏi rất dày.

⚠ Phân biệt bốn phương án: | Công cụ | Dùng để | |---|---| | ⚠ DOE | ⚠ thí nghiệm có kế hoạch tìm tổ hợp yếu tố tối ưu — CÂU NÀY | | ⚠ Design for X | ⚠ nguyên tắc thiết kế hướng tới một mục tiêu (dễ sản xuất, dễ bảo trì...) | | ⚠ Histogram | ⚠ xem phân bố tần suất của dữ liệu đã có | | ⚠ Lưu đồ | ⚠ mô tả các bước và điểm quyết định trong quy trình | | ⚠ Mẹo | ⚠ có chữ "thử nghiệm / thí nghiệm / nhiều biến" thì nghĩ ngay tới DOE |

Từ khoá nhận diện:

"một loạt thử nghiệm để tìm tổ hợp tốt nhất" → ⚠ DOE "thiết kế sao cho dễ sản xuất / dễ bảo trì" → ⚠ Design for X "phân bố, tần suất, cột" → ⚠ histogram "luồng, bước, điểm quyết định" → ⚠ lưu đồ

⚠ Bảy công cụ chất lượng cơ bản Công cụ
⚠ Biểu đồ nhân quả (Ishikawa) ⚠ tìm nguyên nhân gốc
⚠ Lưu đồ ⚠ mô tả quy trình
⚠ Phiếu kiểm tra ⚠ thu thập dữ liệu có tổ chức
⚠ Biểu đồ Pareto ⚠ 80/20 — tìm ít nguyên nhân gây nhiều lỗi nhất
⚠ Histogram ⚠ phân bố tần suất
⚠ Biểu đồ kiểm soát ⚠ quy trình có nằm trong tầm kiểm soát không
⚠ Biểu đồ phân tán ⚠ quan hệ giữa hai biến
⚠ Lưu ý ⚠ DOE KHÔNG nằm trong bảy công cụ này — nó là kỹ thuật thống kê riêng
⚠ DOE mạnh ở chỗ nào Điểm mạnh
⚠ Thay đổi NHIỀU yếu tố cùng lúc theo thiết kế ⚠ thay vì thử từng cái một
⚠ Phát hiện được TƯƠNG TÁC giữa các yếu tố ⚠ thứ mà thử lần lượt không bao giờ thấy
⚠ Giảm mạnh số lần thí nghiệm cần chạy ⚠ tiết kiệm tiền và thời gian
⚠ Kết quả có nền tảng thống kê ⚠ không phải phỏng đoán
⚠ Ở tình huống này ⚠ vật liệu × độ dày × cách gia công đều có thể tương tác với nhau

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội có đang thử từng yếu tố một không | ⚠ dấu hiệu chưa dùng DOE | | Có ghi lại thiết kế thí nghiệm trước khi chạy không | | | Kết quả có được dùng để chốt tiêu chuẩn vật liệu không | |

Và giá trị thật của DOE trong dự án: nó biến câu hỏi "chọn vật liệu nào" từ một cuộc tranh cãi giữa các kỹ sư thành một câu trả lời có số liệu.

Câu 193 People
Charles is part of the delivery team working together to figure out how to plan for the next iteration. The product owner is at the meeting and mutters to the scrum master that the team is not focused on what they should be. What is the most likely cause?
  1. A The product owner may not have recently prioritized the backlog or has not provided the goal for the iteration
  2. B The scrum master is likely talking too much during the session
  3. C The delivery team did not calculate the value for each item in their estimation
  4. D The delivery team is too focused on discussion of testing
Xem giải thích

Đáp án

A — Product owner có thể CHƯA XẾP ƯU TIÊN backlog gần đây, hoặc CHƯA NÊU MỤC TIÊU cho sprint.

Vì sao đúng

⚠ Vì sao đây là nguyên nhân có khả năng nhất: | Lý do | Nội dung | |---|---| | ⚠ Đội chỉ lấy việc từ ĐẦU backlog | ⚠ backlog chưa xếp thì đội không biết đâu là việc quan trọng nhất | | ⚠ MỤC TIÊU SPRINT là kim chỉ nam của cả buổi lập kế hoạch | ⚠ không có mục tiêu thì bàn gì cũng lan man | | ⚠ Cả hai việc này đều thuộc PRODUCT OWNER | ⚠ chính người đang phàn nàn | | ⚠ Đội "không tập trung đúng thứ" là TRIỆU CHỨNG, không phải nguyên nhân | | | ⚠ Mỉa mai của tình huống | ⚠ PO phàn nàn về hệ quả do chính mình gây ra |

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

  • C (đội không tính giá trị cho từng hạng mục khi ước lượng) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe hợp lý nhưng ⚠ tính GIÁ TRỊ không phải việc của đội phát triển ⚠ — đó là việc của product owner (xem câu #25912); ⚠ đội ước lượng NỖ LỰC, PO định GIÁ TRỊ.

  • B (Scrum Master nói quá nhiều trong buổi họp) — ⚠ có thể là vấn đề, ⚠ nhưng không giải thích vì sao đội chọn SAI VIỆC.

  • D (đội quá tập trung bàn về kiểm thử) — ⚠ bàn về kiểm thử là việc BÌNH THƯỜNG ⚠ trong lập kế hoạch sprint, ⚠ liên quan trực tiếp tới Định nghĩa Hoàn thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25912 ở lô này (PO xếp backlog theo rủi ro), câu #25889 (xếp theo giá trị kinh doanh), và câu #25921 cũng ở lô này (ba câu hỏi trong daily scrum). ⚠ Cả nhóm về trách nhiệm của từng vai trong Scrum.

⚠ Chuẩn bị cho một buổi lập kế hoạch sprint tốt: | Ai | Phải chuẩn bị gì | |---|---| | ⚠ PRODUCT OWNER | ⚠ backlog đã XẾP ƯU TIÊN, hạng mục đầu đã làm rõ, có ý tưởng MỤC TIÊU sprint | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ biết sức chứa của mình, nắm nợ kỹ thuật còn tồn | | ⚠ SCRUM MASTER | ⚠ chuẩn bị buổi họp, đảm bảo mọi người có mặt và có đủ thông tin | | ⚠ Thiếu chuẩn bị của PO | ⚠ buổi lập kế hoạch biến thành buổi làm rõ yêu cầu — sai mục đích |

Từ khoá nhận diện:

"đội không tập trung đúng thứ" → ⚠ thường do backlog chưa xếp hoặc thiếu mục tiêu sprint "backlog refinement" → ⚠ việc làm TRƯỚC buổi lập kế hoạch, không phải trong "đội tính giá trị" → ⚠ sai vai — giá trị là của PO "PO phàn nàn về đội" → ⚠ kiểm xem PO đã làm đủ phần của mình chưa

⚠ Mục tiêu sprint quan trọng thế nào Vai trò
⚠ Cho đội một ĐÍCH CHUNG thay vì một danh sách việc rời rạc
⚠ Giúp đội tự quyết khi gặp tình huống bất ngờ giữa sprint ⚠ "cái này có phục vụ mục tiêu không?"
⚠ Cho phép đội thương lượng phạm vi mà vẫn giữ được cam kết
⚠ Là thứ được trình bày ở sprint review
⚠ Không có mục tiêu ⚠ sprint chỉ còn là một hộp thời gian chứa việc vặt
⚠ Scrum Master nên làm gì trong tình huống này Việc
⚠ KHÔNG chỉ trích PO trước mặt đội
⚠ Gợi ý cả nhóm cùng chốt MỤC TIÊU SPRINT trước ⚠ việc chữa cháy ngay trong buổi
⚠ Sau buổi, trao đổi riêng với PO về việc chuẩn bị backlog
⚠ Đề xuất đưa buổi refinement vào nhịp làm việc đều đặn ⚠ giải pháp gốc
⚠ Nguyên tắc ⚠ Scrum Master phục vụ CẢ PO lẫn đội — không đứng về phe nào

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi lập kế hoạch sprint gần nhất có mục tiêu rõ không | | | Backlog có được refine đều đặn không | ⚠ khuyến nghị dành khoảng 10% thời gian sprint | | Đội có biết vì sao hạng mục A nằm trên hạng mục B không | |

Và nguyên tắc chẩn đoán đáng nhớ: khi đội "không tập trung", hãy hỏi trước xem có ai đã nói cho họ biết phải tập trung vào đâu chưa.

Câu 194 People
Fabian is a well-respected, outspoken project team member. His team members respect his technological experience, but if things are not done Fabian's way, there are problems. In the middle of a problem-solving team discussion, Eva, a project team member, throws up her hands and says, "Okay, Fabian, we'll do it your way!" Which of the following solutions is this an example of?
  1. A A win-win solution
  2. B A leave-lose solution
  3. C A yield-lose solution
  4. D A lose-lose solution
Xem giải thích

Đáp án

C — Giải pháp NHƯỜNG-THUA (yield-lose).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ Eva giơ tay đầu hàng và nói "thôi được, làm theo ý anh" | ⚠ cô NHƯỜNG — bỏ quan điểm của mình | | ⚠ Cô nhường không phải vì bị thuyết phục | ⚠ mà vì mệt mỏi với việc tranh cãi | | ⚠ Vấn đề gốc KHÔNG được giải quyết | ⚠ giải pháp tốt nhất có thể đã bị bỏ mất | | ⚠ NHƯỜNG (yield) + cả nhóm THUA (lose) | ⚠ đúng tên gọi yield-lose | | ⚠ Tương ứng với | ⚠ chiến lược XOA DỊU / NHƯỢNG BỘ (smoothing/accommodating) |

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

  • D (thua-thua) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ thua-thua tương ứng với ⚠ THOẢ HIỆP ⚠ — cả hai bên đều nhượng một phần và không ai đạt trọn; ⚠ ở đây ⚠ Fabian không nhượng gì cả, ⚠ chỉ có Eva nhường.

  • A (thắng-thắng) — ⚠ tương ứng với HỢP TÁC / GIẢI QUYẾT VẤN ĐỀ; ⚠ không ai thắng ở đây.

  • B (rời bỏ-thua, leave-lose) — ⚠ tương ứng với NÉ TRÁNH; ⚠ Eva không bỏ đi, ⚠ cô ở lại và chấp nhận ý của Fabian.

Ghi nhớ

⚠ Đối chiếu: ⚠ đây là câu thứ SÁU trong bộ xung đột: ⚠ câu #25672 ở lô 177 (ép buộc), #25775 ở lô 180 (né tránh), #25785 ở lô 181 (hợp tác), #25814 ở lô 181 (thoả hiệp), #25851 ở lô 182 (xoa dịu), và câu này. ⚠ Câu này đặc biệt ở chỗ dùng BỘ TỪ VỰNG THẮNG-THUA thay vì tên chiến lược — phải thuộc bảng đối chiếu mới trả lời được.

⚠ BẢNG ĐỐI CHIẾU hai bộ từ vựng: | Chiến lược | Từ vựng thắng-thua | Bản chất | |---|---|---| | ⚠ HỢP TÁC / GIẢI QUYẾT VẤN ĐỀ | ⚠ THẮNG-THẮNG (win-win) | ⚠ tìm giải pháp thoả mãn cả hai — TỐT NHẤT | | ⚠ THOẢ HIỆP | ⚠ THUA-THUA (lose-lose) | ⚠ cả hai nhượng một phần, không ai trọn vẹn | | ⚠ ÉP BUỘC | ⚠ THẮNG-THUA (win-lose) | ⚠ một bên áp đặt | | ⚠ XOA DỊU / NHƯỢNG BỘ | ⚠ NHƯỜNG-THUA (yield-lose) | ⚠ một bên nhường — CÂU NÀY | | ⚠ NÉ TRÁNH | ⚠ RỜI BỎ-THUA (leave-lose) | ⚠ rút lui khỏi xung đột | | ⚠ Bẫy lớn nhất | ⚠ thoả hiệp bị gọi là THUA-THUA vì không bên nào đạt trọn — rất phản trực giác |

Từ khoá nhận diện:

"thôi được, làm theo ý anh" → ⚠ nhường-thua / xoa dịu "chia đôi, mỗi bên nhượng một nửa" → ⚠ thua-thua / thoả hiệp "để sau, không bàn nữa" → ⚠ rời bỏ-thua / né tránh "tôi là sếp, làm theo tôi" → ⚠ thắng-thua / ép buộc "cùng tìm cách thoả mãn cả hai" → ⚠ thắng-thắng / hợp tác

⚠ Vấn đề thật của tình huống này Vấn đề
⚠ Fabian được nể vì chuyên môn nhưng ÁP ĐẶT ⚠ kiểu người "giỏi nhưng khó chịu"
⚠ Eva nhường vì MỆT, không vì bị thuyết phục ⚠ ức chế sẽ tích lại
⚠ Đội mất cơ hội có giải pháp tốt hơn
⚠ Lần sau sẽ ít người dám nêu ý kiến khác ⚠ hại lớn nhất, và lâu dài nhất
⚠ Quản lý dự án phải làm gì ⚠ can thiệp — đưa cuộc thảo luận về hợp tác dựa trên DỮ LIỆU chứ không dựa trên uy tín cá nhân
⚠ Khi nào nhượng bộ lại là ĐÚNG Trường hợp
⚠ Vấn đề nhỏ, quan hệ quan trọng hơn
⚠ Bạn nhận ra mình sai ⚠ khi đó là học hỏi, không phải đầu hàng
⚠ Cần tích luỹ thiện chí cho vấn đề lớn hơn sắp tới
⚠ Ở tình huống này ⚠ KHÔNG đúng — đang giữa buổi giải quyết vấn đề, đúng lúc cần tranh luận nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có ai luôn thắng mọi tranh luận không | ⚠ dấu hiệu đáng lo, không phải đáng mừng | | Ai đã ngừng nêu ý kiến gần đây | | | Tranh luận kết thúc bằng dữ liệu hay bằng ai nói to hơn | |

Và điều nguy hiểm nhất của một giải pháp nhường-thua: nhìn từ ngoài, nó trông y hệt một cuộc họp kết thúc êm đẹp.

Câu 195 People
You are a project manager for your organization and are working on assigning project team members to activities. You must complete an activity by a predetermined date. Currently, with four project team members assigned to the activity, the work will take 40 hours. You know that by adding eight project team members to the activity, the task will not necessarily be reduced to 20 hours. This is because of which one of the following?
  1. A Theory Z
  2. B Herzberg’s Theory of Motivation
  3. C The Law of diminishing returns
  4. D Parkinson’s Law
Xem giải thích

Đáp án

C — QUY LUẬT LỢI ÍCH GIẢM DẦN (Law of diminishing returns).

Vì sao đúng

⚠ Đọc tình huống: | Chi tiết | Ý nghĩa | |---|---| | ⚠ 4 người → 40 giờ | ⚠ hiện trạng | | ⚠ Thêm 8 người thành 12 người | ⚠ gấp ba nhân lực | | ⚠ Nhưng KHÔNG chắc rút xuống 20 giờ | ⚠ thậm chí gấp ba người cũng không rút được xuống 1/3 | | ⚠ Mỗi người thêm vào đóng góp NGÀY CÀNG ÍT | ⚠ đó chính là quy luật lợi ích giảm dần | | ⚠ Nguyên nhân | ⚠ thêm người thì thêm kênh giao tiếp, thêm thời gian đào tạo, thêm chồng chéo, và nhiều việc không chia nhỏ được |

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

  • D (Định luật Parkinson) — ⚠ phương án gây nhiễu mạnh nhất vì cũng là một "quy luật" về công việc và thời gian: ⚠ nhưng Parkinson nói ⚠ "công việc nở ra để lấp đầy thời gian được cấp" ⚠ — về hành vi trì hoãn, ⚠ không phải về hiệu suất của việc thêm người.

  • B (Thuyết động lực của Herzberg) — ⚠ hai nhóm yếu tố: duy trì và tạo động lực; ⚠ nói về động lực, không nói về năng suất theo số người.

  • A (Thuyết Z) — ⚠ của Ouchi, về quản trị kiểu Nhật, gắn bó lâu dài và ra quyết định đồng thuận; ⚠ không liên quan.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25645 ở lô 178 (độn thời gian) và các câu về thuyết động lực Maslow/Herzberg/McClelland/Vroom đã gặp ở lô 177–181. ⚠ Đề rất hay trộn các "quy luật" và "thuyết" vào cùng một bộ phương án.

⚠ Bốn "quy luật" hay bị trộn lẫn: | Tên | Nội dung | |---|---| | ⚠ LỢI ÍCH GIẢM DẦN | ⚠ thêm nguồn lực thì phần đóng góp thêm ngày càng nhỏ — CÂU NÀY | | ⚠ ĐỊNH LUẬT PARKINSON | ⚠ công việc nở ra lấp đầy thời gian được cấp | | ⚠ ĐỊNH LUẬT BROOKS | ⚠ thêm người vào dự án phần mềm đang trễ làm nó TRỄ THÊM | | ⚠ NGUYÊN LÝ PARETO | ⚠ 80% hệ quả đến từ 20% nguyên nhân | | ⚠ Mẹo phân biệt | ⚠ giảm dần nói về SỐ NGƯỜI, Parkinson nói về THỜI GIAN ĐƯỢC CẤP, Brooks nói riêng về dự án ĐANG TRỄ |

Từ khoá nhận diện:

"gấp đôi người không rút một nửa thời gian" → ⚠ lợi ích giảm dần "cho 10 ngày thì làm hết 10 ngày" → ⚠ Parkinson "thêm người vào dự án trễ" → ⚠ định luật Brooks "thuyết X/Y/Z, Herzberg, Maslow" → ⚠ về ĐỘNG LỰC, không về năng suất theo số người

⚠ Vì sao thêm người không tỉ lệ thuận với tốc độ Lý do
⚠ Kênh giao tiếp tăng theo n(n−1)/2 ⚠ 4 người có 6 kênh, 12 người có 66 kênh
⚠ Người mới cần thời gian làm quen ⚠ và người cũ phải bỏ thời gian ra hướng dẫn
⚠ Nhiều việc KHÔNG CHIA NHỎ ĐƯỢC ⚠ chín người không đẻ ra em bé trong một tháng
⚠ Tranh chấp tài nguyên dùng chung ⚠ thiết bị, môi trường, người rà soát
⚠ Chồng chéo và làm trùng việc
⚠ Hệ quả ⚠ có một điểm mà thêm người bắt đầu làm CHẬM LẠI, chứ không chỉ là ít nhanh hơn
⚠ Muốn rút ngắn thời gian thì làm gì Cách
⚠ CRASHING — thêm nguồn lực vào đường găng ⚠ tăng chi phí, và đúng câu này là chỗ quy luật giảm dần cắn
⚠ FAST TRACKING — làm song song các việc vốn nối tiếp ⚠ tăng rủi ro và làm lại
⚠ Giảm phạm vi ⚠ phải qua kiểm soát thay đổi
⚠ Cải thiện quy trình, gỡ vật cản ⚠ thường hiệu quả hơn thêm người
⚠ Nguyên tắc ⚠ crashing chỉ áp lên hoạt động trên ĐƯỜNG GĂNG mới rút được tổng thời gian — xem câu #25665

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Việc đang trễ có thực sự chia nhỏ được không | ⚠ hỏi trước khi xin thêm người | | Thêm người mất bao lâu mới đóng góp được | | | Vật cản thật nằm ở thiếu người hay ở chỗ khác | ⚠ rất thường là chỗ khác |

Và câu hỏi một quản lý dự án nên tự đặt trước khi xin thêm nhân sự: nếu bốn người đang mất 40 giờ, thì người thứ mười hai sẽ làm gì trong 40 giờ đó?

Câu 196 People
Shawn is a project manager for an information technology project, which is nearing completion. This project has replaced all of the older networking cables with a modern cabling infrastructure. The project has also established several WiFi hotspots throughout the organization's campus. The project steering committee has asked Shawn to verify which project objectives have been completed and which are still outstanding to plan the follow-up projects. What should Shawn do next?
  1. A Tell the steering committee to wait until the next meeting for an update.
  2. B Refer the steering committee to the project management information system.
  3. C Ask the project team to report back on which objectives are completed.
  4. D Review the project work information and compare progress to determine which objectives are completed.
Xem giải thích

Đáp án

D — RÀ SOÁT thông tin công việc của dự án và SO SÁNH với tiến độ để xác định mục tiêu nào đã hoàn thành.

Vì sao đúng

⚠ Vì sao đây là việc PM phải tự làm: | Lý do | Nội dung | |---|---| | ⚠ Uỷ ban chỉ đạo hỏi ĐÍCH DANH quản lý dự án | ⚠ đó là trách nhiệm của Shawn | | ⚠ PM là người có đủ dữ liệu để tổng hợp | ⚠ dữ liệu hiệu suất công việc + đường cơ sở | | ⚠ Phải PHÂN TÍCH chứ không chỉ chuyển tiếp dữ liệu thô | ⚠ giá trị của PM nằm ở đây | | ⚠ Có kết quả rồi mới lập được kế hoạch dự án tiếp theo | ⚠ mục đích uỷ ban nêu rõ | | ⚠ Quy trình tương ứng | ⚠ Giám sát và Kiểm soát công việc dự án — biến DỮ LIỆU thành THÔNG TIN rồi thành BÁO CÁO |

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

  • B (chỉ uỷ ban chỉ đạo sang hệ thống thông tin quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ PMIS ⚠ CÓ chứa dữ liệu, ⚠ nhưng đẩy lãnh đạo đi tự tra dữ liệu thô là ⚠ né trách nhiệm phân tích ⚠ — và dữ liệu thô không trả lời được câu hỏi "mục tiêu nào đã xong".

  • C (nhờ đội báo cáo lại xem mục tiêu nào xong) — ⚠ đội báo cáo tình trạng CÔNG VIỆC, không báo cáo tình trạng MỤC TIÊU; ⚠ ánh xạ công việc sang mục tiêu là việc của PM.

  • A (bảo uỷ ban đợi tới cuộc họp sau) — ⚠ trì hoãn không lý do; ⚠ dữ liệu đã có sẵn.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25911 ở lô này (họp tổng kết đóng dự án) và câu #25906 (vai trò nhà tài trợ — PM là người soạn báo cáo trạng thái). ⚠ Cả ba đều nhấn mạnh: tổng hợp và phân tích là việc của quản lý dự án, không đẩy được cho ai.

⚠ Chuỗi DỮ LIỆU → THÔNG TIN → BÁO CÁO: | Bậc | Nội dung | |---|---| | ⚠ DỮ LIỆU hiệu suất công việc | ⚠ quan sát thô: đã lắp 340 mét cáp, 12 điểm WiFi hoạt động | | ⚠ THÔNG TIN hiệu suất công việc | ⚠ đã phân tích và so với đường cơ sở: đạt 85% mục tiêu hạ tầng cáp | | ⚠ BÁO CÁO hiệu suất công việc | ⚠ bản trình bày cho bên liên quan — thứ uỷ ban chỉ đạo cần | | ⚠ Sai lầm của phương án B | ⚠ đưa DỮ LIỆU khi người ta cần BÁO CÁO |

Từ khoá nhận diện:

"lãnh đạo hỏi tình hình" → ⚠ PM phân tích rồi trả lời, không chuyển tiếp dữ liệu thô "chỉ sang hệ thống, sang người khác" → ⚠ né trách nhiệm "đợi cuộc họp sau" → ⚠ trì hoãn vô cớ, gần như luôn sai "so sánh với đường cơ sở" → ⚠ cốt lõi của giám sát và kiểm soát

⚠ Uỷ ban chỉ đạo là gì Nội dung
⚠ Nhóm lãnh đạo giám sát dự án hoặc danh mục dự án
⚠ Ra quyết định vượt thẩm quyền của PM
⚠ Duyệt thay đổi lớn, quyết tiếp tục hay dừng
⚠ Thường bao gồm nhà tài trợ và các lãnh đạo chức năng
⚠ Khác với CCB ⚠ CCB chỉ xét yêu cầu thay đổi; uỷ ban chỉ đạo có phạm vi rộng hơn
⚠ Vì sao câu hỏi này xuất hiện lúc dự án SẮP XONG Ý nghĩa
⚠ Chuẩn bị nghiệm thu — kiểm mục tiêu nào đạt
⚠ Lập kế hoạch cho các dự án tiếp nối ⚠ mục đích uỷ ban nêu ra
⚠ Mục tiêu chưa đạt sẽ thành phạm vi của dự án sau ⚠ hoặc thành nợ phải giải trình
⚠ Bài học ⚠ nếu tới cuối dự án mới biết mục tiêu nào đạt thì đã theo dõi quá thưa

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ánh xạ được công việc sang MỤC TIÊU không | ⚠ nhiều dự án chỉ theo dõi việc, không theo dõi mục tiêu | | Báo cáo của bạn là dữ liệu hay là thông tin | | | Lãnh đạo có phải tự đi tra số liệu không | ⚠ nếu có, PM đang chưa làm đủ |

Và điều phân biệt một quản lý dự án với một người ghi chép tiến độ: người thứ hai biết công việc nào đã xong, người thứ nhất biết điều đó có nghĩa gì với mục tiêu.

Câu 197 Process
Ike is a scrum master at Watchdog Corporation, which runs multiple successful agile projects. Recently Ike met with another scrum master, David, in the organization. David seemed overwhelmed with the project and he is struggling to make decisions. The development team needs to choose an architecture quickly – but they are fearful of making the wrong decision as it will have a long-term effect on the project. What should Ike advise David to do next?
  1. A Assign an agile champion.
  2. B Analyze the project information to make the best decision with the team.
  3. C Speak to their team's managers to get insight into the problem.
  4. D Replace the product owner with the project sponsor.
Xem giải thích

Đáp án

B — PHÂN TÍCH thông tin dự án để đưa ra quyết định tốt nhất CÙNG VỚI ĐỘI.

Vì sao đúng

⚠ Vì sao đây là lời khuyên đúng cho David: | Lý do | Nội dung | |---|---| | ⚠ Agile đề cao ĐỘI TỰ TỔ CHỨC | ⚠ quyết định kỹ thuật thuộc về đội phát triển | | ⚠ Quyết định dựa trên THÔNG TIN, không dựa trên cảm giác | ⚠ cách chữa nỗi sợ là dữ liệu | | ⚠ Quyết định CÙNG ĐỘI thì đội cùng chịu trách nhiệm | ⚠ giảm áp lực đè lên một mình David | | ⚠ Scrum Master ĐIỀU PHỐI, không QUYẾT THAY | | | ⚠ Nguyên tắc agile | ⚠ kiến trúc tốt nhất nổi lên từ ĐỘI TỰ TỔ CHỨC — nguyên tắc số 11 của Tuyên ngôn Agile |

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

  • C (hỏi quản lý của đội để hiểu vấn đề) — ⚠ phương án gây nhiễu mạnh nhất: ⚠ nghe như tìm lời khuyên có kinh nghiệm, ⚠ nhưng nó ⚠ đưa quyết định kỹ thuật ra NGOÀI đội ⚠ và ⚠ phá vỡ tính tự tổ chức; ⚠ quản lý chức năng cũng không nắm bối cảnh bằng đội.

  • A (chỉ định một agile champion) — ⚠ không giải quyết quyết định kiến trúc trước mắt; ⚠ champion là vai trò thúc đẩy chuyển đổi agile trong tổ chức, khác hẳn.

  • D (thay product owner bằng nhà tài trợ) — ⚠ hoàn toàn lạc đề; ⚠ vấn đề không nằm ở PO, ⚠ và thay người là phản ứng cực đoan.

Ghi nhớ

⚠ Ghi nhớ đối chiếu quan trọng — CÂU TRÙNG: ⚠ #27073 lô 206 TRÙNG NGUYÊN VĂN với câu này ⚠ — ⚠ cùng khoá đáp án về nội dung, nhưng THỨ TỰ CHỮ CÁI bị ĐẢO NGƯỢC HOÀN TOÀN (A↔D, B↔C), nên ở đó đáp án là phương án C chứ không phải B; ⚠ đây là bằng chứng rõ ràng rằng bộ đề xáo thứ tự phương án giữa các lần ra đề, nên phải nhớ NỘI DUNG chứ đừng nhớ chữ cái.

⚠ Đối chiếu: ⚠ câu #25913 ở lô này (Scrum Master huấn luyện bên liên quan), câu #25915 (Scrum Master xử lý khi PO phàn nàn), và câu #25901 ở lô này (phong cách lãnh đạo HỖ TRỢ). ⚠ Cùng nhóm: Scrum Master phục vụ chứ không chỉ huy.

⚠ Đội sợ quyết định sai thì làm gì: | Cách | Nội dung | |---|---| | ⚠ Thu thập THÔNG TIN để giảm bất định | ⚠ bước đầu tiên — CÂU NÀY | | ⚠ Chạy SPIKE — thử nghiệm nhỏ có hộp thời gian | ⚠ cách agile chuẩn để giảm rủi ro kỹ thuật | | ⚠ Ghi ADR — biên bản quyết định kiến trúc | ⚠ ghi lại lý do để sau này hiểu vì sao chọn | | ⚠ Chọn quyết định ĐẢO NGƯỢC ĐƯỢC nếu có | ⚠ quyết định một chiều mới cần cân nhắc kỹ | | ⚠ Trì hoãn tới THỜI ĐIỂM MUỘN NHẤT CÓ TRÁCH NHIỆM | ⚠ nguyên tắc của lean | | ⚠ Điều KHÔNG nên làm | ⚠ để nỗi sợ làm tê liệt — không quyết cũng là một quyết định, và thường là quyết định tệ nhất |

Từ khoá nhận diện:

"đội sợ quyết định sai" → ⚠ thu thập thông tin và quyết cùng đội "hỏi quản lý bên ngoài" → ⚠ phá tính tự tổ chức "thay người" → ⚠ gần như luôn là đáp án sai trong đề PMP "Scrum Master ra quyết định kỹ thuật thay đội" → ⚠ sai vai

⚠ Quyết định kiến trúc trong agile Nguyên tắc
⚠ Kiến trúc NỔI LÊN dần, không thiết kế hết từ đầu
⚠ Nhưng quyết định khó đảo ngược thì phải cân nhắc SỚM ⚠ đây là ngoại lệ quan trọng
⚠ Đủ kiến trúc để đi tiếp, không thừa ⚠ "just enough architecture"
⚠ Ghi lại LÝ DO chứ không chỉ ghi kết luận
⚠ Ở tình huống này ⚠ đề nói rõ "ảnh hưởng lâu dài" — đúng là loại quyết định cần phân tích cẩn thận
⚠ David đang gặp vấn đề gì Vấn đề
⚠ Quá tải — nhận về mình trách nhiệm không phải của mình
⚠ Hiểu sai vai Scrum Master thành người ra quyết định
⚠ Có thể thiếu kinh nghiệm với tổ chức tự quản
⚠ Ike nên làm gì thêm ⚠ ngoài lời khuyên, HUẤN LUYỆN David về ranh giới vai trò — đó là cách giúp lâu dài

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Quyết định kỹ thuật trong đội bạn do ai chốt | | | Có quyết định nào đang bị treo vì sợ sai không | | | Đội có ghi lại lý do của các quyết định lớn không | ⚠ sáu tháng sau sẽ rất cần |

Và điều một Scrum Master phải học sớm: cảm giác "mình phải quyết cái này" thường là dấu hiệu bạn đang làm sai vai, chứ không phải dấu hiệu bạn đang gánh trách nhiệm tốt.

Câu 198 Process
As the project manager for the Pine Project, Bonna is reviewing the project budget with senior management. The project's capital expenses are concerning to management, and they would like to know when Bonna will actually spend the project's budget. Of the following, which represents the vast majority of a projects' budget?
  1. A Labor
  2. B Project plan execution
  3. C Cost of goods and services
  4. D Project planning
Xem giải thích

Đáp án

B — THỰC HIỆN KẾ HOẠCH DỰ ÁN (project plan execution).

Vì sao đúng

⚠ Phân bố chi tiêu theo giai đoạn: | Giai đoạn | Tỷ trọng ngân sách | |---|---| | ⚠ Khởi tạo | ⚠ rất nhỏ — vài cuộc họp, viết điều lệ | | ⚠ Lập kế hoạch | ⚠ nhỏ — thời gian của đội lập kế hoạch | | ⚠ THỰC HIỆN | ⚠ PHẦN LỚN NHẤT — làm ra sản phẩm thật, mua sắm, thi công, nhân công | | ⚠ Giám sát và kiểm soát | ⚠ chạy song song, chi phí quản lý | | ⚠ Kết thúc | ⚠ nhỏ | | ⚠ Đường cong chữ S | ⚠ chi tiêu tích luỹ tăng chậm ở đầu, DỐC ĐỨNG ở giữa (thực hiện), rồi phẳng lại ở cuối |

⚠ Đây chính là câu trả lời cho câu hỏi của lãnh đạo: "khi nào Bonna thực sự tiêu tiền?" — trong giai đoạn THỰC HIỆN.

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

  • A (nhân công) — ⚠ phương án gây nhiễu mạnh nhất, và có phần đúng ở góc nhìn khác — xem mục ghi chú chất lượng bên dưới: ⚠ nhân công là ⚠ LOẠI CHI PHÍ, ⚠ không phải ⚠ GIAI ĐOẠN; ⚠ câu hỏi hỏi "khi nào tiêu", nên câu trả lời phải là một giai đoạn.

  • D (lập kế hoạch dự án) — ⚠ chiếm tỷ trọng nhỏ, ⚠ dù rất quan trọng.

  • C (chi phí hàng hoá và dịch vụ) — ⚠ cũng là loại chi phí, không phải giai đoạn; ⚠ và ở đa số dự án còn nhỏ hơn nhân công.

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

⚠ Bộ phương án của câu này TRỘN HAI CHIỀU PHÂN LOẠI khác nhau: | Phương án | Thuộc chiều nào | |---|---| | ⚠ A — Nhân công | ⚠ LOẠI chi phí | | ⚠ B — Thực hiện kế hoạch dự án | ⚠ GIAI ĐOẠN — khoá đáp án | | ⚠ C — Chi phí hàng hoá và dịch vụ | ⚠ LOẠI chi phí | | ⚠ D — Lập kế hoạch dự án | ⚠ GIAI ĐOẠN |

⚠ Nếu đọc câu hỏi theo chiều LOẠI CHI PHÍ thì "nhân công" là câu trả lời đúng ở phần lớn dự án — nhân công thường chiếm 60–80% ngân sách. ⚠ Khoá đáp án chỉ đứng vững khi hiểu câu hỏi theo chiều GIAI ĐOẠN, và đề nghiêng về chiều đó vì lãnh đạo hỏi "KHI NÀO Bonna sẽ tiêu tiền". ⚠ Giữ nguyên khoá B, nhưng nhớ rằng bẫy nằm ở chỗ đề trộn hai chiều — gặp lại kiểu này, hãy bám vào từ chỉ THỜI GIAN trong câu hỏi.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25907 ở lô này (make-or-buy và điểm hoà vốn), câu #25902 (độ trễ toàn phần), và họ hàng EVM ở lô 176–179 (#25581, #25685, #25708, #25718). ⚠ Cùng nhóm quản lý chi phí và lịch trình.

⚠ Đường cong chữ S của chi tiêu: | Đặc điểm | Nội dung | |---|---| | ⚠ Đầu dự án: chi ÍT, dốc thoải | ⚠ khởi tạo và lập kế hoạch | | ⚠ Giữa dự án: chi NHIỀU, dốc đứng | ⚠ thực hiện — CÂU NÀY | | ⚠ Cuối dự án: chi ít lại, dốc thoải | ⚠ nghiệm thu và đóng | | ⚠ Đường cơ sở chi phí chính là đường cong này | ⚠ PV theo thời gian | | ⚠ Dùng để | ⚠ so AC thực tế với PV kế hoạch — nền tảng của EVM |

Từ khoá nhận diện:

"khi nào tiêu tiền" → ⚠ hỏi về GIAI ĐOẠN → thực hiện "loại chi phí nào lớn nhất" → ⚠ hỏi về LOẠI → thường là nhân công "đường cong chữ S" → ⚠ đường cơ sở chi phí tích luỹ "dòng tiền dự án" → ⚠ cần cho lãnh đạo lập kế hoạch vốn

⚠ Vì sao lãnh đạo quan tâm THỜI ĐIỂM chi chứ không chỉ TỔNG chi Lý do
⚠ Tổ chức phải chuẩn bị DÒNG TIỀN ⚠ có tiền trên sổ khác với có tiền lúc cần
⚠ Chi phí vốn ảnh hưởng báo cáo tài chính từng quý ⚠ đề nói rõ "chi phí vốn khiến lãnh đạo lo ngại"
⚠ Nhiều dự án cùng rút vốn một lúc là vấn đề của danh mục
⚠ Bonna nên chuẩn bị gì ⚠ bảng dòng tiền theo tháng, không chỉ một con số tổng ngân sách

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có đường cơ sở chi phí theo THỜI GIAN không | ⚠ hay chỉ có một con số tổng | | Tháng nào dự án tiêu nhiều nhất | | | Tổ chức có biết trước đỉnh chi đó không | |

Và điều một quản lý dự án hay quên khi trình bày ngân sách: lãnh đạo tài chính ít khi hỏi "bao nhiêu" mà không kèm theo "khi nào".

Câu 199 People
As a scrum master, Betty ensures that her team understands and uses scrum effectively. Each team member is taught to answer three questions in their daily scrum meeting briefly. They are
  1. A What work they have done since the last meeting, what they plan to do today, and whether any roadblocks would prevent them from progressing on their work.
  2. B What work is ready to start, what they will do today, and what work has been completed in the project.
  3. C What work they have done since the last meeting, what new user stories are complete and ready for development, and whether any roadblocks would prevent them from progressing on their work.
  4. D What work they have done since the last meeting, what they plan to do today, and potential solutions for any roadblocks they face.
Xem giải thích

Đáp án

A — Đã làm gì từ buổi họp trước, hôm nay định làm gì, và có VẬT CẢN nào ngăn tiến độ không.

Vì sao đúng

⚠ Ba câu hỏi kinh điển của daily scrum: | Câu hỏi | Mục đích | |---|---| | ⚠ Hôm qua tôi đã làm gì để giúp đội đạt mục tiêu sprint? | ⚠ nhìn lại | | ⚠ Hôm nay tôi sẽ làm gì để giúp đội đạt mục tiêu sprint? | ⚠ nhìn tới | | ⚠ Tôi có thấy VẬT CẢN nào không? | ⚠ nêu vấn đề để được gỡ | | ⚠ Lưu ý quan trọng | ⚠ chỉ NÊU vật cản, KHÔNG giải quyết ngay trong buổi họp | | ⚠ Hộp thời gian | ⚠ 15 phút, đứng họp để giữ ngắn |

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

  • D (đã làm gì, hôm nay làm gì, và GIẢI PHÁP KHẢ DĨ cho các vật cản) — ⚠ phương án gây nhiễu mạnh nhất, ⚠ chỉ khác đáp án đúng ở vế thứ ba: ⚠ daily scrum là chỗ ⚠ NÊU vật cản, KHÔNG phải chỗ GIẢI QUYẾT; ⚠ bàn giải pháp ngay sẽ phá vỡ hộp thời gian 15 phút và lôi những người không liên quan vào cuộc. ⚠ Việc bàn giải pháp diễn ra SAU buổi họp, giữa những người thực sự cần.

  • C (…những user story mới nào đã sẵn sàng để phát triển…) — ⚠ đó là việc của BACKLOG REFINEMENT, ⚠ không phải daily scrum.

  • B (việc nào sẵn sàng bắt đầu, hôm nay làm gì, việc nào đã xong trong dự án) — ⚠ thiếu hẳn phần VẬT CẢN, ⚠ vế quan trọng nhất; ⚠ và "đã xong trong dự án" là góc nhìn quá rộng cho một buổi họp ngày.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25904 ở lô này (timeboxing), câu #25913 (giải thích story point), và câu #25915 (lập kế hoạch sprint). ⚠ Cả nhóm về các sự kiện Scrum.

⚠ Năm sự kiện của Scrum: | Sự kiện | Hộp thời gian (sprint 1 tháng) | Mục đích | |---|---|---| | ⚠ SPRINT | ⚠ tối đa 1 tháng | ⚠ khung chứa tất cả sự kiện khác | | ⚠ Lập kế hoạch sprint | ⚠ tối đa 8 giờ | ⚠ chọn việc và chốt mục tiêu sprint | | ⚠ DAILY SCRUM | ⚠ 15 phút | ⚠ đồng bộ và nêu vật cản — CÂU NÀY | | ⚠ Sprint review | ⚠ tối đa 4 giờ | ⚠ trình bày kết quả, thu phản hồi | | ⚠ Sprint retrospective | ⚠ tối đa 3 giờ | ⚠ cải tiến CÁCH LÀM VIỆC | | ⚠ Phân biệt | ⚠ review nói về SẢN PHẨM, retrospective nói về QUY TRÌNH |

Từ khoá nhận diện:

"ba câu hỏi mỗi ngày" → ⚠ đã làm / sẽ làm / vật cản "giải pháp cho vật cản" → ⚠ KHÔNG thuộc daily scrum "user story sẵn sàng phát triển" → ⚠ backlog refinement "15 phút, đứng" → ⚠ daily scrum

⚠ Daily scrum LÀ và KHÔNG LÀ Nội dung
⚠ LÀ buổi đồng bộ CỦA ĐỘI, cho đội ⚠ không phải báo cáo lên Scrum Master hay quản lý
⚠ LÀ nơi lập kế hoạch cho 24 giờ tới
⚠ KHÔNG phải buổi báo cáo tình trạng ⚠ sai lầm phổ biến nhất
⚠ KHÔNG phải nơi giải quyết vấn đề kỹ thuật
⚠ KHÔNG phải nơi quản lý phân việc
⚠ Dấu hiệu đang làm sai ⚠ mọi người nói với Scrum Master thay vì nói với nhau
⚠ Vì sao "nêu chứ không giải quyết" lại quan trọng Lý do
⚠ Giữ buổi họp trong 15 phút
⚠ Không bắt cả đội nghe cuộc bàn chỉ liên quan tới hai người
⚠ Vật cản được ghi nhận và giao người xử lý rõ ràng
⚠ Cách làm chuẩn ⚠ "chúng ta bàn tiếp sau buổi họp" — cụm từ Scrum Master dùng nhiều nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Daily scrum của đội bạn có quá 15 phút không | | | Mọi người nói với nhau hay nói với một người | | | Vật cản nêu ra có được gỡ trong ngày không | ⚠ nêu mà không gỡ thì đội sẽ ngừng nêu |

Và cách nhận ra một daily scrum đã biến chất: khi ai đó vắng mặt, buổi họp vẫn diễn ra bình thường vì thực chất chẳng ai nghe ai.

Câu 200 People
Which of the following is the best display of George's agile leadership practices?
  1. A Taking ten minutes before their daily standup to transparently discuss all upcoming project events.
  2. B Openly admitting to a mistake he made in the project.
  3. C Keeping an accurate project plan that he updates daily for reporting.
  4. D Taking the team's estimates and adding a 50% buffer before ever providing them to management.
Xem giải thích

Đáp án

B — CÔNG KHAI THỪA NHẬN một sai lầm mình đã phạm trong dự án.

Vì sao đúng

⚠ Vì sao đây là biểu hiện tốt nhất của lãnh đạo agile: | Lý do | Nội dung | |---|---| | ⚠ Tạo AN TOÀN TÂM LÝ cho cả đội | ⚠ lãnh đạo nhận sai thì thành viên mới dám nhận sai | | ⚠ Làm gương cho tính MINH BẠCH | ⚠ một trong ba trụ cột của Scrum | | ⚠ Xây dựng LÒNG TIN | ⚠ nền tảng của mọi đội hiệu quả | | ⚠ Thể hiện lãnh đạo phục vụ, không phải lãnh đạo quyền lực | | | ⚠ Kết quả | ⚠ sai lầm được phát hiện SỚM thay vì bị giấu tới lúc quá muộn |

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

  • A (dành mười phút trước standup để bàn minh bạch mọi sự kiện sắp tới) — ⚠ phương án gây nhiễu mạnh nhất vì có chữ "minh bạch": ⚠ nhưng nó ⚠ thêm việc vào một buổi họp vốn có hộp thời gian 15 phút ⚠ (xem câu #25921); ⚠ minh bạch không có nghĩa là họp nhiều hơn.

  • C (giữ một kế hoạch dự án chính xác, cập nhật hằng ngày để báo cáo) — ⚠ tư duy DỰ ĐOÁN; ⚠ agile ưu tiên phần mềm chạy được hơn tài liệu đầy đủ, ⚠ và cập nhật kế hoạch hằng ngày cho việc báo cáo là lãng phí.

  • D (lấy ước lượng của đội rồi cộng thêm 50% mới đưa lên quản lý) — ⚠ KHÔNG minh bạch, gần như là gian dối; ⚠ đó là ĐỘN thời gian (xem câu #25645), ⚠ phá huỷ lòng tin cả hai chiều.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #25901 ở lô này (phong cách lãnh đạo hỗ trợ), câu #25919 (Scrum Master quyết định cùng đội), và câu #25588/#25732/#25881 (lãnh đạo buông lỏng — hỏi ba lần). ⚠ Cả nhóm về phong cách lãnh đạo trong agile.

⚠ Đặc điểm của lãnh đạo phục vụ: | Đặc điểm | Nội dung | |---|---| | ⚠ GỠ VẬT CẢN cho đội | ⚠ thay vì giao thêm việc | | ⚠ MINH BẠCH — kể cả về sai lầm của mình | ⚠ CÂU NÀY | | ⚠ LẮNG NGHE nhiều hơn nói | | | ⚠ TIN đội và trao quyền quyết định | | | ⚠ PHÁT TRIỂN con người, không chỉ giao kết quả | | | ⚠ Bảo vệ đội trước nhiễu từ bên ngoài | | | ⚠ Câu hỏi tự kiểm | ⚠ "đội có làm việc tốt hơn nhờ có mình không, hay chỉ là báo cáo đẹp hơn?" |

Từ khoá nhận diện:

"thừa nhận sai lầm công khai" → ⚠ lãnh đạo agile, tạo an toàn tâm lý "cộng thêm buffer trước khi báo cáo" → ⚠ thiếu minh bạch, luôn sai "kế hoạch cập nhật hằng ngày để báo cáo" → ⚠ tư duy dự đoán, lãng phí "thêm mười phút vào standup" → ⚠ phá hộp thời gian

⚠ An toàn tâm lý là gì Nội dung
⚠ Thành viên tin rằng nói thật sẽ không bị trừng phạt
⚠ Dám nêu ý kiến trái chiều ⚠ liên hệ câu #25916 — Eva nhường vì không thấy an toàn để tranh luận tiếp
⚠ Dám báo tin xấu sớm ⚠ giá trị lớn nhất về mặt quản trị rủi ro
⚠ Dám thử và dám thất bại
⚠ Nghiên cứu Project Aristotle của Google ⚠ an toàn tâm lý là yếu tố số MỘT của đội hiệu quả
⚠ Xây bằng cách nào ⚠ lãnh đạo làm gương TRƯỚC — chính là hành động của George
⚠ Ba trụ cột của Scrum Trụ cột
⚠ MINH BẠCH ⚠ mọi người thấy cùng một sự thật — hành động của George thuộc trụ cột này
⚠ THANH TRA ⚠ thường xuyên kiểm tra tiến độ và sản phẩm
⚠ THÍCH NGHI ⚠ điều chỉnh khi phát hiện lệch
⚠ Quan hệ ⚠ không minh bạch thì thanh tra thấy sai, và thích nghi sẽ đi sai hướng

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Lần cuối lãnh đạo của bạn nhận sai công khai là khi nào | | | Đội có dám báo tin xấu sớm không | | | Ước lượng của đội có bị sửa trước khi lên trên không | ⚠ nếu có, cả hai chiều đều đang mất lòng tin |

Và lý do vì sao một lời nhận lỗi lại đáng giá hơn mọi bản kế hoạch cập nhật hằng ngày: nó là bằng chứng duy nhất, không thể làm giả, rằng nói thật ở đội này là an toàn.