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

Tìm thấy 720 câu.

Câu 491 People
The primary reason that Gregory's team has chosen to use paired programming in their agile project is
  1. A To allow for the quickest feedback cycle possible for Gregory's work to resolve issues almost immediately.
  2. B To make sure that Gregory is coding the right way based on company standards.
  3. C To ensure that any feature delivered has zero defects.
  4. D To ensure that someone else is supervising all of Gregory's development work.
Xem giải thích

Đáp án

A — Để có VÒNG PHẢN HỒI NHANH NHẤT CÓ THỂ, giúp xử lý vấn đề gần như tức thì.

Vì sao đúng

⚠ Lập trình cặp mang lại gì: | Lợi ích | Nội dung | |---|---| | ⚠ PHẢN HỒI TỨC THÌ — sai được chỉ ra ngay khi vừa gõ | ⚠ không chờ tới lúc rà soát mã | | ⚠ Vấn đề phát hiện SỚM thì sửa RẺ | ⚠ liên hệ #26062 lô 186 — hai đường cong | | ⚠ Hai người cùng nghĩ thì giải pháp thường tốt hơn | | | ⚠ Kiến thức LAN TOẢ trong đội, giảm rủi ro một người biết | | | ⚠ Vì sao "phản hồi nhanh" là lý do CHÍNH | ⚠ agile xây trên vòng phản hồi ngắn — lập trình cặp là vòng phản hồi NGẮN NHẤT có thể, tính bằng giây |

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

  • B (bảo đảm Gregory viết mã đúng chuẩn công ty) — ⚠ phương án gây nhiễu mạnh nhất vì lập trình cặp ⚠ quả thật giúp giữ chuẩn mã: ⚠ nhưng đó là ⚠ HỆ QUẢ PHỤ, không phải mục đích chính; ⚠ và cách nói này biến bạn cặp thành ⚠ người kiểm tra, ⚠ sai tinh thần.

  • D (bảo đảm có người GIÁM SÁT toàn bộ công việc của Gregory) — ⚠ SAI TINH THẦN NGHIÊM TRỌNG: ⚠ lập trình cặp là ⚠ HỢP TÁC giữa hai người ngang hàng, ⚠ không phải giám sát ⚠ (liên hệ #26214 cùng lô — quản lý vi mô).

  • C (bảo đảm mọi tính năng bàn giao KHÔNG CÓ lỗi nào) — ⚠ hứa hẹn bất khả thi; ⚠ lập trình cặp GIẢM lỗi, ⚠ không loại bỏ hết.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26214 ở lô này (công cụ KHÔNG phải để quản lý vi mô) — ⚠ hai câu cùng lô, cùng một thông điệp: thực hành agile phục vụ ĐỘI, không phải phục vụ việc kiểm soát đội. ⚠ Xem thêm #26197 cùng lô (phong cách hợp tác), #26030 lô 185 (tin tưởng đội tự tổ chức).

⚠ Lập trình cặp hoạt động thế nào: | Vai | Việc | |---|---| | ⚠ NGƯỜI LÁI (driver) | ⚠ gõ mã, tập trung vào chi tiết chiến thuật | | ⚠ NGƯỜI DẪN ĐƯỜNG (navigator) | ⚠ nghĩ về hướng đi, phát hiện vấn đề, đặt câu hỏi | | ⚠ ĐỔI VAI thường xuyên | ⚠ 15–30 phút một lần | | ⚠ Cả hai đều ĐÓNG GÓP, không ai chỉ ngồi xem | ⚠ đây là chỗ phân biệt với "giám sát" | | ⚠ Vòng phản hồi | ⚠ tính bằng GIÂY — nhanh hơn mọi hình thức rà soát mã khác |

Từ khoá nhận diện:

"vòng phản hồi nhanh nhất" → ⚠ mục đích chính của lập trình cặp "bảo đảm đúng chuẩn" → ⚠ hệ quả phụ "giám sát công việc" → ⚠ sai tinh thần hoàn toàn "không còn lỗi nào" → ⚠ hứa hẹn không thực tế

⚠ Các vòng phản hồi trong agile, từ NGẮN tới DÀI Vòng
⚠ LẬP TRÌNH CẶP — vài giây ⚠ CÂU NÀY
⚠ Kiểm thử đơn vị tự động — vài phút
⚠ Tích hợp liên tục — vài chục phút
⚠ HỌP ĐỨNG hằng ngày — một ngày ⚠ liên hệ #26093 lô 187
⚠ RÀ SOÁT SPRINT — một tới bốn tuần
⚠ NHÌN LẠI — mỗi sprint ⚠ phản hồi về CÁCH LÀM VIỆC
⚠ Phản hồi từ người dùng thật — sau khi phát hành ⚠ dài nhất nhưng quan trọng nhất
⚠ Nguyên tắc ⚠ vòng càng ngắn, sai sót càng rẻ — đó là lý do agile đầu tư mạnh vào phản hồi nhanh
⚠ Phản đối thường gặp và câu trả lời Phản đối
⚠ "Hai người làm một việc thì mất gấp đôi công" ⚠ nghiên cứu cho thấy tăng khoảng 15% công sức nhưng giảm lỗi đáng kể
⚠ "Không phải lúc nào cũng cần" ⚠ ĐÚNG — dùng cho phần khó, phần rủi ro cao, hoặc khi cần truyền kiến thức
⚠ "Đội không hợp nhau" ⚠ vấn đề của đội, không phải của kỹ thuật này
⚠ Khi nào KHÔNG nên cặp ⚠ việc đơn giản, lặp lại, hoặc khi cả hai đều mệt

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có cặp cho phần khó nhất không | | | Bạn cặp để hợp tác hay để kiểm tra nhau | ⚠ người trong cuộc cảm nhận được ngay | | Vòng phản hồi ngắn nhất trong quy trình của bạn dài bao lâu | |

Và điều phân biệt lập trình cặp thật với lập trình cặp hình thức: trong cặp thật, cả hai người đều có lúc nói "khoan đã, chỗ này không ổn" — nếu chỉ có một người nói suốt buổi thì đó là giám sát, không phải cặp.

Câu 492 People
You have been assigned to lead a team that will create a virtual game using agile project methodologies. Your team had been using a web application to assign tasks, but many of those assignments would get lost in the application as more tasks were added. For this reason, your team decides to use a task tracker tool website that uses a Kanban-style methodology. Which of the following options are not a benefit of using tools that create and track tasks?
  1. A Task trackers are an effective way for team members to view their assignments clearly.
  2. B Team leaders can follow and monitor their team member's workload and provide an up-to-date list of tasks.
  3. C Team leaders can more easily micromanage their teams using these task tracker tools.
  4. D Team leaders can achieve better coordination using task trackers in virtual teams.
Xem giải thích

Đáp án

C — "Người dẫn dắt đội có thể QUẢN LÝ VI MÔ đội mình dễ dàng hơn" — đây là thứ KHÔNG phải lợi ích.

Vì sao đúng

⚠ Vì sao quản lý vi mô không bao giờ là lợi ích: | Lý do | Nội dung | |---|---| | ⚠ Đi NGƯỢC nguyên tắc đội TỰ TỔ CHỨC của agile | ⚠ liên hệ #26030 lô 185 | | ⚠ Phá huỷ NIỀM TIN — nền của mọi đội hiệu quả | | | ⚠ Giảm động lực và tinh thần trách nhiệm | | | ⚠ Làm người ta tối ưu cho việc BÁO CÁO ĐẸP thay vì làm tốt | | | ⚠ Cùng một công cụ, hai cách dùng | ⚠ bảng Kanban để đội TỰ ĐIỀU PHỐI là tốt; để quản lý ĐẾM giờ từng người là biến nó thành công cụ kiểm soát |

Vì sao các phương án khác sai — ba phương án còn lại ĐỀU là lợi ích thật

  • A (thành viên xem rõ việc được giao) — ⚠ LỢI ÍCH THẬT: ⚠ đây chính là vấn đề đội đang gặp — ⚠ việc bị lẫn mất trong ứng dụng cũ.
  • B (người dẫn dắt theo dõi khối lượng công việc, có danh sách việc cập nhật) — ⚠ LỢI ÍCH THẬT: ⚠ theo dõi để CÂN BẰNG TẢI khác hoàn toàn với quản lý vi mô.
  • D (phối hợp tốt hơn trong đội ảo) — ⚠ LỢI ÍCH THẬT và đặc biệt quan trọng ⚠ khi đội không ngồi cùng chỗ.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26213 ở lô này (lập trình cặp KHÔNG phải để giám sát) — ⚠ cặp câu cùng thông điệp trong một lô. ⚠ Xem thêm #26158 lô 188 (Kanban hiển thị ưu tiên và trạng thái), #26197 cùng lô (lãnh đạo hợp tác), #26179 lô 188 (vật cản có người phụ trách — không phải giám sát người).

⚠ Ranh giới giữa THEO DÕI và QUẢN LÝ VI MÔ: | Theo dõi lành mạnh | Quản lý vi mô | |---|---| | ⚠ Nhìn LUỒNG CÔNG VIỆC | ⚠ nhìn từng THAO TÁC của từng người | | ⚠ Hỏi "chỗ nào đang tắc" | ⚠ hỏi "sao việc này lâu thế" | | ⚠ Dữ liệu dùng để GỠ VẬT CẢN | ⚠ dữ liệu dùng để ĐÁNH GIÁ cá nhân | | ⚠ Đội tự cập nhật bảng | ⚠ quản lý bắt cập nhật để báo cáo lên trên | | ⚠ Đo TỐC ĐỘ CỦA ĐỘI | ⚠ đo NĂNG SUẤT TỪNG NGƯỜI — liên hệ #26220 cùng lô | | ⚠ Câu hỏi phân biệt | ⚠ dữ liệu này dùng để GIÚP đội hay để CHẤM ĐIỂM đội? |

Từ khoá nhận diện:

"quản lý vi mô dễ hơn" → ⚠ không bao giờ là lợi ích "thành viên thấy rõ việc của mình" → ⚠ lợi ích thật "cân bằng khối lượng công việc" → ⚠ lợi ích thật "phối hợp đội ảo" → ⚠ lợi ích thật, đặc biệt quan trọng

⚠ Vì sao đội ảo cần công cụ theo dõi việc hơn đội ngồi cùng chỗ Lý do
⚠ Không có bảng vật lý trên tường để nhìn ⚠ liên hệ #26208 cùng lô — bảng thông tin
⚠ Không tình cờ gặp nhau ở hành lang
⚠ Múi giờ khác nhau — trao đổi bất đồng bộ
⚠ Trạng thái công việc phải TỰ NÓI LÊN, không cần hỏi ⚠ đây là giá trị lớn nhất
⚠ Nhưng cẩn thận ⚠ công cụ càng cho nhiều dữ liệu thì cám dỗ quản lý vi mô càng lớn — nhất là khi quản lý không nhìn thấy người
⚠ Vấn đề mà đội đang gặp và cách công cụ mới giải quyết Vấn đề
⚠ Việc bị LẪN MẤT khi thêm nhiều việc mới ⚠ vấn đề trong đề
⚠ Kanban hiển thị mọi việc theo cột trạng thái ⚠ không việc nào biến mất
⚠ Giới hạn việc đang làm (WIP) ngăn nhận quá nhiều ⚠ gốc rễ của việc bị lẫn
⚠ Thấy ngay chỗ tắc nghẽn ⚠ liên hệ #26162 lô 188 — Lý thuyết ràng buộc
⚠ Lưu ý cho đội của bạn ⚠ đổi công cụ không tự sửa được vấn đề — phải kèm giới hạn việc đang làm, nếu không thì bảng mới cũng đầy như ứng dụng cũ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng công việc của bạn dùng để giúp đội hay để báo cáo lên trên | | | Đội có tự cập nhật hay bị nhắc mới cập nhật | ⚠ dấu hiệu rõ nhất của công cụ áp đặt | | Bạn có giới hạn việc đang làm không | |

Và cách nhận biết một công cụ đang bị dùng sai: khi đội cập nhật bảng vì sợ bị hỏi, chứ không phải vì bảng giúp họ làm việc.

Câu 493 Process
Deborah is a project manager at Creative Corporation. Rob, a junior project manager, approaches Deborah and asks for her help. Rob's project has multiple stakeholders, and Rob cannot keep track of which ones he should keep tabs on and which ones he should actively engage with. How is Deborah likely to respond to Rob's situation?
  1. A Rob should confer with his steering committee.
  2. B Rob should analyze his stakeholders and categorize them by influence and power.
  3. C Rob should call a meeting with all his stakeholders to discuss the project.
  4. D Rob should assign each of his project team members to monitor one specific stakeholder.
Xem giải thích

Đáp án

B — Rob nên PHÂN TÍCH bên liên quan và PHÂN LOẠI họ theo ẢNH HƯỞNG và QUYỀN LỰC.

Vì sao đúng

⚠ Vấn đề của Rob và cách phân loại giải quyết nó: | Vấn đề | Cách giải | |---|---| | ⚠ Quá nhiều bên liên quan, không biết ai quan trọng hơn ai | ⚠ phân loại là bước xử lý đúng | | ⚠ Không biết ai chỉ cần THEO DÕI, ai cần GẮN KẾT CHỦ ĐỘNG | ⚠ đây chính xác là đầu ra của lưới quyền lực–ảnh hưởng | | ⚠ Nguồn lực của Rob hữu hạn | ⚠ phải dồn vào nhóm quan trọng nhất | | ⚠ Phân loại cho ra CHIẾN LƯỢC khác nhau cho từng ô | | | ⚠ Kết quả | ⚠ Rob biết ngay ai cần gặp hằng tuần, ai chỉ cần gửi báo cáo |

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

  • C (họp với TẤT CẢ bên liên quan để bàn về dự án) — ⚠ phương án gây nhiễu mạnh nhất vì gặp bên liên quan luôn là việc tốt: ⚠ nhưng ⚠ họp tất cả cùng lúc KHÔNG giải quyết vấn đề PHÂN LOẠI ⚠ — sau buổi họp Rob vẫn không biết dồn sức cho ai; ⚠ và với dự án nhiều bên liên quan, ⚠ một buổi họp chung khổng lồ thường vô hiệu.

  • D (giao mỗi thành viên đội theo dõi một bên liên quan) — ⚠ phân tán trách nhiệm mà chưa có tiêu chí; ⚠ và gắn kết bên liên quan chính là việc của quản lý dự án.

  • A (hỏi ban chỉ đạo) — ⚠ đẩy việc; ⚠ đây là kỹ năng cơ bản Rob cần tự làm được.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26185 ở lô này (ba bước phân tích bên liên quan: nhận diện → XẾP ƯU TIÊN → dự đoán phản ứng) — ⚠ câu này chính là chi tiết của BƯỚC HAI trong câu đó; ⚠ câu #26139 lô 188 (quyền cao quan tâm thấp → giữ hài lòng), ⚠ câu #26183 ở lô này (thống nhất kỳ vọng).

⚠ LƯỚI QUYỀN LỰC – QUAN TÂM (và biến thể quyền lực – ảnh hưởng): | Ô | Chiến lược | Ví dụ | |---|---|---| | ⚠ QUYỀN CAO – QUAN TÂM CAO | ⚠ QUẢN LÝ CHẶT CHẼ | ⚠ nhà tài trợ — gặp thường xuyên | | ⚠ QUYỀN CAO – QUAN TÂM THẤP | ⚠ GIỮ HÀI LÒNG | ⚠ liên hệ #26139 lô 188 — đừng làm phiền quá mức | | ⚠ QUYỀN THẤP – QUAN TÂM CAO | ⚠ GIỮ THÔNG TIN ĐẦY ĐỦ | ⚠ người dùng cuối — họ quan tâm và có thể thành đồng minh | | ⚠ QUYỀN THẤP – QUAN TÂM THẤP | ⚠ THEO DÕI, ít công sức | ⚠ đúng cụm từ trong câu hỏi của Rob | | ⚠ Lưu ý | ⚠ vị trí trên lưới THAY ĐỔI trong vòng đời dự án — phải rà lại định kỳ | | ⚠ Cảnh báo | ⚠ lưới này chứa thông tin nhạy cảm; đừng dán lên tường |

Từ khoá nhận diện:

"không biết theo dõi ai, gắn kết ai" → ⚠ phân loại theo quyền lực và ảnh hưởng "họp với tất cả" → ⚠ không giải quyết vấn đề phân loại "giao đội theo dõi từng người" → ⚠ phân tán mà chưa có tiêu chí "hỏi ban chỉ đạo" → ⚠ đẩy việc

⚠ Deborah nên hướng dẫn Rob làm theo thứ tự nào Bước
⚠ 1. Lập danh sách ĐẦY ĐỦ bên liên quan ⚠ kể cả người phản đối
⚠ 2. Chấm điểm quyền lực và ảnh hưởng cho từng người ⚠ CÂU NÀY
⚠ 3. Xếp vào bốn ô
⚠ 4. Chọn chiến lược gắn kết cho từng ô
⚠ 5. Ghi vào kế hoạch gắn kết và kế hoạch truyền thông ⚠ liên hệ #26203 cùng lô
⚠ 6. Rà lại mỗi giai đoạn
⚠ Sai lầm của người mới như Rob ⚠ cố gắng gắn kết mọi người NHƯ NHAU, rồi kiệt sức mà vẫn bỏ sót người quan trọng nhất

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có phân loại bên liên quan hay đối xử đều với tất cả | | | Ba người quan trọng nhất của dự án bạn là ai | ⚠ trả lời được ngay không | | Lần cuối bạn rà lại danh sách đó là bao giờ | |

Và điều Deborah thật sự đang dạy Rob: quản lý bên liên quan không phải là làm hài lòng tất cả mọi người — nó là biết ai cần bao nhiêu sự chú ý, rồi phân bổ đúng như thế.

Câu 494 People
Scheduled to last 22 months and affect 243 of his organization’s stakeholders, Bernie is the project manager for the Lighthouse Project. There is sensitive project information that only certain stakeholders should receive access to, so Bernie has come up with a plan to deliver this information to the correct people throughout the project: special e-mail bulletins. A secure e-mail is considered to be what type of communication?
  1. A Push
  2. B Sensitive
  3. C Passive
  4. D Interactive
Xem giải thích

Đáp án

A — Truyền thông ĐẨY (push).

Vì sao đúng

⚠ Ba dạng truyền thông: | Dạng | Đặc điểm | Ví dụ | |---|---|---| | ⚠ ĐẨY (push) | ⚠ GỬI tới người nhận cụ thể | ⚠ email, thư, báo cáo, bản tin — CÂU NÀY | | ⚠ KÉO (pull) | ⚠ người nhận TỰ VÀO LẤY | ⚠ kho tài liệu, mạng nội bộ, bảng thông tin | | ⚠ TƯƠNG TÁC (interactive) | ⚠ trao đổi HAI CHIỀU thời gian thực | ⚠ họp, gọi điện, họp trực tuyến | | ⚠ Email bảo mật gửi cho người cụ thể | ⚠ rõ ràng là ĐẨY | | | ⚠ Đặc điểm chung của đẩy | ⚠ bảo đảm ĐÃ GỬI, KHÔNG bảo đảm đã đọc hay đã hiểu |

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

  • D (tương tác) — ⚠ phương án gây nhiễu mạnh nhất vì email ⚠ có thể trả lời qua lại: ⚠ nhưng ⚠ tương tác đòi hỏi trao đổi ĐỒNG THỜI, thời gian thực; ⚠ email là ⚠ BẤT ĐỒNG BỘ ⚠ — gửi xong người nhận đọc lúc nào tuỳ họ.

  • C (thụ động) — ⚠ KHÔNG phải một trong ba dạng chuẩn; ⚠ dễ nhầm với "kéo".

  • B (nhạy cảm) — ⚠ mô tả NỘI DUNG, không phải PHƯƠNG THỨC; ⚠ đây là bẫy chọn từ có trong đề bài.

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

⚠ CÂU NÀY GẦN TRÙNG với câu #26264 ở lô 190 ⚠ (Damien — email hàng loạt gửi quản lý cấp trung). ⚠ Hai đề khác nhân vật và phương tiện cụ thể, ⚠ nhưng ⚠ hỏi cùng một điều và có CÙNG KHOÁ: truyền thông ĐẨY — ⚠ hai khoá NHẤT QUÁN. ⚠ Bảng đối chiếu đầy đủ nằm ở #26264.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26192 ở lô này (ba yếu tố cơ bản của truyền thông), ⚠ câu #26203 ở lô này (kế hoạch quản lý truyền thông), ⚠ câu #26208 ở lô này (bảng thông tin — dạng KÉO), ⚠ câu #26057/#26070 lô 186 (đếm kênh truyền thông).

⚠ Chọn dạng nào cho tình huống nào: | Tình huống | Dạng nên dùng | |---|---| | ⚠ Thông tin cần đến ĐÚNG người, có bằng chứng đã gửi | ⚠ ĐẨY — trường hợp của Bernie | | ⚠ Thông tin nhiều, ai cần thì tra | ⚠ KÉO | | ⚠ Cần thống nhất, cần thuyết phục, cần hiểu nhau | ⚠ TƯƠNG TÁC | | ⚠ Tin xấu hoặc tin phức tạp | ⚠ TƯƠNG TÁC — đừng gửi email | | ⚠ Thông tin nhạy cảm chỉ cho một nhóm | ⚠ ĐẨY có kiểm soát truy cập — đúng cách Bernie chọn | | ⚠ Sai lầm phổ biến nhất | ⚠ dùng ĐẨY cho việc cần TƯƠNG TÁC — gửi email dài về một thay đổi lớn rồi tưởng mọi người đã đồng ý |

Từ khoá nhận diện:

"email, báo cáo, bản tin gửi đi" → ⚠ đẩy "kho tài liệu, mạng nội bộ, bảng thông tin" → ⚠ kéo "họp, gọi điện, trao đổi thời gian thực" → ⚠ tương tác "nhạy cảm" → ⚠ mô tả nội dung, không phải phương thức — bẫy dùng lại từ trong đề

⚠ Bối cảnh của Bernie — vì sao đẩy là lựa chọn đúng Phân tích
⚠ 243 bên liên quan ⚠ quá đông để tương tác với tất cả
⚠ Thông tin NHẠY CẢM chỉ một số người được xem ⚠ cần kiểm soát người nhận — kéo không làm được điều này tốt
⚠ Dự án kéo dài 22 tháng ⚠ cần cơ chế bền, lặp lại được
⚠ Email bảo mật có DẤU VẾT gửi nhận ⚠ quan trọng với thông tin nhạy cảm
⚠ Nhưng Bernie nên bổ sung ⚠ cơ chế XÁC NHẬN ĐÃ ĐỌC — đẩy không bảo đảm người ta đọc, và với tin nhạy cảm thì điều đó quan trọng
⚠ Ba câu hỏi trước khi chọn phương thức Câu hỏi
⚠ Người nhận có CẦN PHẢN HỒI ngay không ⚠ có → tương tác
⚠ Có cần biết CHẮC ai đã nhận không ⚠ có → đẩy
⚠ Thông tin có nhiều và ít khẩn không ⚠ có → kéo
⚠ Ghi ở đâu ⚠ kế hoạch quản lý truyền thông — liên hệ #26203 cùng lô

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có dùng email cho việc lẽ ra cần họp không | | | Thông tin nhạy cảm của bạn có kiểm soát người nhận không | | | Bạn có biết ai đã đọc thông tin quan trọng gần nhất không | |

Và giới hạn cốt lõi của truyền thông đẩy: nó chứng minh được bạn đã gửi, nhưng không chứng minh được ai đó đã hiểu — và trong dự án, chỉ vế thứ hai mới có giá trị.

Câu 495 People
As an agile team leader, it is Marco's job to keep stakeholders engaged. Of the following choices, how should he do this?
  1. A Anyone who is not staying engaged will be reported to their manager.
  2. B Anyone who is not staying engaged will not be invited to future meetings.
  3. C To set precedence, the first person who is not staying engaged will be replaced.
  4. D In status reports, explain benefits or problems with specific stakeholder involvement.
Xem giải thích

Đáp án

D — Trong BÁO CÁO TRẠNG THÁI, nêu rõ lợi ích hoặc vấn đề gắn với sự tham gia của từng bên liên quan cụ thể.

Vì sao đúng

⚠ Vì sao cách này hiệu quả: | Lý do | Nội dung | |---|---| | ⚠ MINH BẠCH — ai cũng thấy tình hình tham gia | ⚠ giá trị cốt lõi của agile | | ⚠ Nêu CỤ THỂ từng bên liên quan, không nói chung chung | ⚠ "cụ thể" là từ khoá trong phương án | | ⚠ Nêu cả LỢI ÍCH lẫn VẤN ĐỀ | ⚠ ghi nhận người tham gia tốt, không chỉ nêu người chậm | | ⚠ Tạo áp lực TÍCH CỰC, không đối đầu cá nhân | | | ⚠ Ba phương án còn lại | ⚠ đều là TRỪNG PHẠT — báo lên sếp, loại khỏi họp, thay người làm gương |

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

  • A (báo lên quản lý của người không tham gia) — ⚠ phương án gây nhiễu mạnh nhất vì leo thang đúng là ⚠ một công cụ hợp lệ: ⚠ nhưng dùng nó ⚠ NGAY và với MỌI người ⚠ là quá tay, phá quan hệ và làm người ta phòng thủ.

  • B (không mời dự các buổi họp sau) — ⚠ PHẢN TÁC DỤNG HOÀN TOÀN: ⚠ mục tiêu là TĂNG tham gia, ⚠ loại họ ra là cắt đứt hẳn.

  • C (thay người đầu tiên không tham gia để làm gương) — ⚠ trừng phạt để răn đe; ⚠ tạo văn hoá sợ hãi, ⚠ và quản lý dự án thường không có quyền thay bên liên quan.

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

⚠ CÂU NÀY GẦN TRÙNG với câu #26205 CÙNG LÔ. ⚠ Hai đề khác nhau về nhân vật ⚠ (Jerry ở Tarth's Tarps ↔ Marco) ⚠ và cách diễn đạt phương án, ⚠ nhưng ⚠ hỏi CÙNG một điều và có CÙNG một khoá đáp án:

#26205 #26217 — câu này
⚠ Nhân vật ⚠ Jerry ⚠ Marco
⚠ Câu hỏi ⚠ cách tốt để bảo đảm mức tham gia của bên liên quan ⚠ cách giữ bên liên quan gắn kết
⚠ Khoá ⚠ đưa vào báo cáo dự án và báo cáo lãnh đạo ⚠ nêu trong báo cáo trạng thái
⚠ Kết luận ⚠ HAI KHOÁ NHẤT QUÁN — không mâu thuẫn
⚠ Điểm khác duy nhất đáng chú ý ⚠ #26205 có phương án nhiễu "vẽ biểu đồ số giờ trên tường"; câu này có ba phương án đều mang tính TRỪNG PHẠT
⚠ Bài học ⚠ hash MD5 KHÔNG bắt được cặp này vì chữ nghĩa khác nhau — chỉ đọc đề mới nhận ra

Ghi nhớ

⚠ Đối chiếu thêm: ⚠ câu #26170 lô 188 (gắn kết bên liên quan là then chốt), ⚠ câu #26203 ở lô này (kế hoạch truyền thông), ⚠ câu #26215 ở lô này (phân loại bên liên quan), ⚠ câu #26218 ở lô này (giải phóng thời gian cho bên liên quan bận).

⚠ Thang can thiệp khi bên liên quan không tham gia: | Mức | Cách làm | Khi nào | |---|---|---| | ⚠ 1. Hỏi họ VÌ SAO | ⚠ thường là do quá bận — liên hệ #26218 cùng lô | ⚠ luôn làm trước tiên | | ⚠ 2. Điều chỉnh cách gắn kết | ⚠ đổi giờ họp, rút ngắn, gửi tóm tắt | | | ⚠ 3. Đưa vào BÁO CÁO minh bạch | ⚠ CÂU NÀY | ⚠ khi vấn đề kéo dài | | ⚠ 4. Nhờ nhà tài trợ tác động | ⚠ có ảnh hưởng ngang cấp | | | ⚠ 5. LEO THANG lên quản lý của họ | ⚠ phương án A | ⚠ cuối cùng, khi đã thử hết | | ⚠ Sai lầm | ⚠ nhảy thẳng lên mức 5, hoặc dừng mãi ở mức 1 mà không bao giờ đưa vào báo cáo |

Từ khoá nhận diện:

"nêu trong báo cáo trạng thái, cụ thể từng người" → ⚠ cách bền vững nhất "báo lên sếp của họ" → ⚠ biện pháp cuối, không phải đầu "không mời họp nữa" → ⚠ phản tác dụng hoàn toàn "thay người làm gương" → ⚠ văn hoá sợ hãi, và thường vượt quyền PM

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Báo cáo của bạn có nêu tên cụ thể khi khen và khi nêu vấn đề không | | | Bạn đã hỏi người ít tham gia vì sao chưa | | | Bạn có leo thang trước khi thử các mức nhẹ hơn không | |

Và điều cả hai câu gần trùng này cùng dạy: minh bạch có sức mạnh hơn trừng phạt — một dòng sự thật trong báo cáo hằng tuần làm được nhiều hơn một lá thư gửi cấp trên.

Câu 496 People
Jessica is a new stakeholder who has recently joined your team. Her daily responsibilities are taking up a lot of her time already and she is having difficulty trying to really engage with the team. You have discussed this issue with Jessica's manager, but no solution has been found. To help alleviate this problem, what can the team do?
  1. A Give Jessica so much to do that she cannot work on her daily tasks until the weekend.
  2. B Explain to Jessica's boss how this is becoming problematic for the team.
  3. C To free Jessica from her daily work commitments, hire a temp or contractor to do this work for her.
  4. D The team can pitch in with Jessica's daily work.
Xem giải thích

Đáp án

C — THUÊ NGƯỜI TẠM hoặc NHÀ THẦU làm công việc hằng ngày để giải phóng Jessica.

Vì sao đúng

⚠ Vì sao đây là giải pháp thật: | Lý do | Nội dung | |---|---| | ⚠ GỠ ĐÚNG NGUYÊN NHÂN GỐC: Jessica không có thời gian | ⚠ không phải cô ấy thiếu thiện chí | | ⚠ Đã nói chuyện với quản lý của cô mà không ra giải pháp | ⚠ đề ghi rõ — nên phương án B đã thử rồi | | ⚠ Thuê người tạm là giải pháp CỤ THỂ, thực hiện được | | | ⚠ Bảo vệ được cả công việc hằng ngày lẫn sự tham gia dự án | | | ⚠ Bản chất | ⚠ đây là vấn đề PHÂN BỔ NGUỒN LỰC, và giải pháp phải nằm ở tầng nguồn lực |

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

  • D (cả đội xúm vào làm giúp công việc hằng ngày của Jessica) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất tinh thần đồng đội: ⚠ nhưng ⚠ đội KHÔNG có chuyên môn cho công việc phòng ban của Jessica, ⚠ và làm vậy ⚠ kéo đội ra khỏi chính công việc dự án ⚠ — đổi một vấn đề lấy một vấn đề lớn hơn.

  • B (giải thích cho sếp của Jessica rằng việc này đang gây khó cho đội) — ⚠ ĐÃ LÀM RỒI mà không có kết quả; ⚠ đề nói rõ điều này.

  • A (giao cho Jessica thật nhiều việc để cô không làm việc hằng ngày được cho tới cuối tuần) — ⚠ thao túng và phi đạo đức; ⚠ vi phạm quy tắc ứng xử nghề nghiệp.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26217 ở lô này (minh bạch trong báo cáo — bước TRƯỚC), ⚠ câu #26205 ở lô này (cùng chủ đề), ⚠ câu #26196 ở lô này (yêu cầu nguồn lực), ⚠ câu #26201 ở lô này (ràng buộc nguồn lực).

⚠ Vì sao vấn đề của Jessica rất phổ biến: | Nguyên nhân | Nội dung | |---|---| | ⚠ Bên liên quan thường ĐƯỢC PHÂN CÔNG vào dự án mà KHÔNG được giảm việc cũ | ⚠ lỗi ở tầng tổ chức, không ở cá nhân | | ⚠ Công việc hằng ngày có deadline rõ và người theo dõi | ⚠ dự án thì thường không | | ⚠ Con người ưu tiên việc gấp hơn việc quan trọng | | | ⚠ Kết quả: dự án luôn thua trong cuộc tranh giành thời gian | | | ⚠ Cách chữa duy nhất bền vững | ⚠ GIẢI PHÓNG thời gian một cách chính thức, không phải kêu gọi cố gắng thêm |

Từ khoá nhận diện:

"bận việc hằng ngày, không tham gia được" → ⚠ giải phóng thời gian bằng người thay thế "đội làm giúp việc phòng ban" → ⚠ kéo đội khỏi việc dự án "nói với sếp cô ấy" → ⚠ đã thử, không ra kết quả "chất thêm việc để ép" → ⚠ thao túng, vi phạm đạo đức nghề nghiệp

⚠ Ai trả tiền thuê người tạm Xử lý
⚠ Đưa vào NGÂN SÁCH DỰ ÁN như một chi phí nguồn lực ⚠ hợp lý vì đó là chi phí để có được bên liên quan
⚠ Hoặc phòng ban của Jessica chi, vì họ vẫn cần việc đó được làm
⚠ Cần YÊU CẦU THAY ĐỔI nếu vượt ngân sách ⚠ liên hệ #26206 cùng lô
⚠ Nhà tài trợ là người quyết ⚠ đây là quyết định ở tầng tổ chức
⚠ Cách trình bày thuyết phục ⚠ "chi X đồng thuê người tạm để tránh chậm dự án Y tuần" — số liệu mạnh hơn lời than phiền
⚠ Ba cách khác giải phóng thời gian bên liên quan Cách
⚠ Thuê người tạm hoặc nhà thầu ⚠ CÂU NÀY — rõ ràng nhất
⚠ Chuyển bớt việc hằng ngày cho đồng nghiệp trong phòng ⚠ cần quản lý của cô đồng ý
⚠ Giảm yêu cầu tham gia — chỉ mời các buổi thật cần ⚠ rẻ nhất, nên thử trước
⚠ Chỉ định NGƯỜI ĐẠI DIỆN cho Jessica ở các buổi thường lệ ⚠ cô chỉ dự các quyết định lớn
⚠ Trong khuôn khổ đề ⚠ ba cách sau không có trong phương án, nhưng ngoài đời đáng thử trước khi tốn tiền thuê người

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bên liên quan của bạn có được giảm việc cũ khi tham gia dự án không | | | Bạn có yêu cầu họ tham gia nhiều hơn mức thật sự cần không | | | Chi phí thời gian của bên liên quan có nằm trong ngân sách dự án không | ⚠ thường bị bỏ quên |

Và gốc rễ của mọi vấn đề gắn kết kiểu này: tổ chức giao người cho dự án mà không giao thời gian của họ — và rồi trách cá nhân vì đã không tìm đâu ra thời gian ấy.

Câu 497 People
As a PMP, Natasha must be aware of the different organizational structures and the regular amount of authority a project manager will have in these environments. For example, if Natasha were a project manager in a company with a weak matrix, who would have the authority on the project?
  1. A The project manager
  2. B The customer
  3. C Functional management
  4. D The team leader
Xem giải thích

Đáp án

C — QUẢN LÝ CHỨC NĂNG (functional management).

Vì sao đúng

⚠ Ma trận YẾU là gì: | Đặc điểm | Nội dung | |---|---| | ⚠ Quyền lực chủ yếu nằm ở QUẢN LÝ CHỨC NĂNG (trưởng phòng) | | | ⚠ Quản lý dự án có quyền HẠN CHẾ hoặc RẤT ÍT | | | ⚠ Vai trò quản lý dự án gần với ĐIỀU PHỐI VIÊN hoặc NGƯỜI XÚC TIẾN | ⚠ có nơi còn không gọi là "quản lý dự án" | | ⚠ Đội làm dự án BÁN THỜI GIAN, vẫn báo cáo cho trưởng phòng | | | ⚠ Ngân sách | ⚠ do quản lý chức năng kiểm soát, không phải quản lý dự án |

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

  • A (quản lý dự án) — ⚠ phương án gây nhiễu mạnh nhất vì trong ⚠ ma trận MẠNH và cơ cấu DỰ ÁN HOÁ ⚠ thì đúng là quản lý dự án có quyền: ⚠ nhưng ⚠ đề nói rõ là ma trận YẾU — ⚠ chính chữ "yếu" đó xác định quyền nằm ở đâu.

  • D (trưởng nhóm) — ⚠ không phải một cấp quyền lực trong mô hình cơ cấu tổ chức của PMBOK.

  • B (khách hàng) — ⚠ khách hàng là bên liên quan quan trọng, ⚠ nhưng không nắm quyền điều hành nội bộ.

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

⚠ CÂU NÀY GẦN TRÙNG với câu #26268 ở lô 190 ⚠ (đội từ ba mảng kinh doanh, đang làm hai dự án khác). ⚠ Hai đề khác nhân vật và bối cảnh, ⚠ nhưng ⚠ hỏi cùng một điều, có cùng bốn phương án và CÙNG KHOÁ: QUẢN LÝ CHỨC NĂNG — ⚠ hai khoá NHẤT QUÁN. ⚠ Hash MD5 không bắt được vì câu chữ khác nhau; ⚠ bảng đối chiếu đầy đủ nằm ở #26268.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26193 ở lô này (quản trị dự án), ⚠ câu #26099 lô 187 (quyền lực tham chiếu), ⚠ câu #26161 lô 188 (quyền lực cưỡng chế), ⚠ câu #26202 ở lô này (hiệu ứng hào quang khi đề bạt).

⚠ BẢNG QUYỀN LỰC THEO CƠ CẤU TỔ CHỨC — thuộc lòng bảng này: | Cơ cấu | Quyền của quản lý dự án | Đội toàn thời gian | Ai quản ngân sách | |---|---|---|---| | ⚠ CHỨC NĂNG (functional) | ⚠ rất ít hoặc không có | ⚠ gần như không | ⚠ quản lý chức năng | | ⚠ MA TRẬN YẾU | ⚠ hạn chế | ⚠ 0–25% | ⚠ quản lý chức năng — CÂU NÀY | | ⚠ MA TRẬN CÂN BẰNG | ⚠ thấp tới trung bình | ⚠ 15–60% | ⚠ chia sẻ | | ⚠ MA TRẬN MẠNH | ⚠ trung bình tới cao | ⚠ 50–95% | ⚠ quản lý dự án | | ⚠ DỰ ÁN HOÁ (projectized) | ⚠ cao tới gần như tuyệt đối | ⚠ 85–100% | ⚠ quản lý dự án | | ⚠ Mẹo nhớ | ⚠ đi từ trên xuống dưới, quyền của quản lý dự án TĂNG DẦN — nhớ hai đầu bảng là suy ra được giữa |

Từ khoá nhận diện:

"ma trận yếu" → ⚠ quản lý chức năng nắm quyền "ma trận mạnh, dự án hoá" → ⚠ quản lý dự án nắm quyền "ma trận cân bằng" → ⚠ chia sẻ quyền — nguồn xung đột thường trực "điều phối viên dự án" → ⚠ dấu hiệu của ma trận yếu

⚠ Natasha nên làm gì nếu phải làm việc trong ma trận yếu Chiến lược
⚠ Xây quan hệ tốt với các trưởng phòng ⚠ họ mới là người điều người
⚠ Dùng quyền lực CHUYÊN MÔN và THAM CHIẾU ⚠ liên hệ #26099 lô 187 — không có quyền chính thức thì dùng ảnh hưởng
⚠ Có ĐIỀU LỆ DỰ ÁN rõ ràng ⚠ văn bản trao quyền là chỗ dựa duy nhất
⚠ Thoả thuận trước về thời gian của từng người ⚠ liên hệ #26218 cùng lô
⚠ Leo thang qua nhà tài trợ khi cần
⚠ Rủi ro lớn nhất ⚠ có TRÁCH NHIỆM về kết quả nhưng không có QUYỀN về nguồn lực — đặc trưng khó chịu nhất của ma trận yếu

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tổ chức bạn thuộc loại cơ cấu nào | ⚠ biết được thì hiểu vì sao mọi thứ khó như vậy | | Bạn có quyền quyết ngân sách dự án không | ⚠ câu hỏi lộ ra vị trí thật của bạn trên bảng | | Người trong đội bạn báo cáo cho ai | |

Và điều bảng này giải thích được cho rất nhiều quản lý dự án thấy khó chịu: phần lớn khó khăn của họ không đến từ năng lực, mà đến từ ô mà tổ chức đã đặt họ vào từ trước khi dự án bắt đầu.

Câu 498 Process
You are the project manager of an agile project to create a banking application for mobile users. Your development team is looking for information on their performance to see if their efficiency is on the right track after their third sprint release. Which statement is true about a team's velocity in an agile environment?
  1. A Teams with no slack time focus on individual objectives, increasing their velocity in the long term.
  2. B Velocity is an empirical measure of a team's progress, used for estimation, not a goal or metric that measures team performance.
  3. C Features are loosely estimated to make planning simpler, thus increasing velocity.
  4. D Scrum teams perform at full potential early on and reduce velocity as complexity decreases.
Xem giải thích

Đáp án

B — Tốc độ là THƯỚC ĐO THỰC NGHIỆM về tiến độ của đội, dùng để ƯỚC LƯỢNG — KHÔNG phải mục tiêu hay chỉ số đo hiệu suất của đội.

Vì sao đúng

⚠ Tốc độ (velocity) là gì và không là gì: | Là gì | Không là gì | |---|---| | ⚠ Số điểm câu chuyện đội HOÀN THÀNH trong một sprint | ⚠ KHÔNG phải điểm số đánh giá đội | | ⚠ Dữ liệu THỰC NGHIỆM — đo từ thực tế đã xảy ra | ⚠ KHÔNG phải chỉ tiêu để phấn đấu tăng | | ⚠ Dùng để DỰ BÁO còn bao nhiêu sprint nữa | ⚠ KHÔNG so sánh được giữa các đội | | ⚠ Công cụ của CHÍNH ĐỘI | ⚠ KHÔNG phải công cụ quản lý để ép đội | | ⚠ Vì sao không so sánh được giữa các đội | ⚠ mỗi đội tự định nghĩa thang điểm riêng — 8 điểm của đội A không bằng 8 điểm của đội B |

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

  • C (ước lượng lỏng lẻo cho việc lập kế hoạch đơn giản hơn, nhờ đó tăng tốc độ) — ⚠ phương án gây nhiễu mạnh nhất vì nó ⚠ mô tả đúng một hiện tượng CÓ THẬT: ⚠ ước lượng phóng đại thì tốc độ tăng trên giấy; ⚠ nhưng đó là ⚠ LẠM PHÁT ĐIỂM, một sự bóp méo, ⚠ không phải điều đúng về tốc độ.

  • A (đội không có thời gian dự trữ tập trung vào mục tiêu cá nhân, tăng tốc độ dài hạn) — ⚠ SAI cả hai vế: ⚠ agile nhấn mạnh mục tiêu ĐỘI, ⚠ và chạy hết công suất liên tục sẽ giảm tốc độ vì kiệt sức và nợ kỹ thuật.

  • D (đội scrum đạt đỉnh sớm rồi giảm tốc độ khi độ phức tạp giảm) — ⚠ NGƯỢC với thực tế: ⚠ tốc độ thường THẤP ở đầu rồi ỔN ĐỊNH DẦN khi đội trưởng thành.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26214 ở lô này (công cụ không phải để quản lý vi mô), ⚠ câu #26213 ở lô này (lập trình cặp không phải để giám sát), ⚠ câu #26149 lô 188 (xếp ưu tiên tương đối), ⚠ câu #26211 ở lô này (việc không tạo giá trị). ⚠ Bốn câu, một thông điệp: số liệu agile phục vụ ĐỘI, không phải phục vụ việc chấm điểm đội.

⚠ Dùng tốc độ ĐÚNG cách: | Dùng đúng | Dùng sai | |---|---| | ⚠ Dự báo còn bao nhiêu sprint nữa xong backlog | ⚠ đặt chỉ tiêu "sprint sau phải đạt 30 điểm" | | ⚠ Đội tự chọn khối lượng cho sprint tới | ⚠ quản lý ép nhận thêm việc | | ⚠ Thấy xu hướng bất thường để tìm nguyên nhân | ⚠ so sánh đội A với đội B | | ⚠ Lấy trung bình 3–5 sprint gần nhất | ⚠ dùng một sprint bất thường làm chuẩn | | ⚠ Hệ quả của dùng sai | ⚠ đội LẠM PHÁT ĐIỂM — con số đẹp lên mà công việc giao ra không tăng chút nào | | ⚠ Đó chính là | ⚠ quy luật Goodhart: khi một thước đo trở thành mục tiêu, nó thôi là thước đo tốt |

Từ khoá nhận diện:

"thước đo thực nghiệm, dùng để ước lượng" → ⚠ định nghĩa đúng của tốc độ "chỉ tiêu, mục tiêu phải đạt" → ⚠ dùng sai "so sánh giữa các đội" → ⚠ vô nghĩa vì thang điểm khác nhau "tốc độ giảm khi phức tạp giảm" → ⚠ ngược thực tế

⚠ Đội của bạn nên xem gì để biết hiệu quả có tốt không Chỉ số
⚠ TỐC ĐỘ có ỔN ĐỊNH không ⚠ ổn định quan trọng hơn cao
⚠ Tỷ lệ hoàn thành cam kết sprint ⚠ nhận 20 làm được bao nhiêu
⚠ Số lỗi thoát ra sản phẩm ⚠ tốc độ cao mà lỗi nhiều là ảo
⚠ THỜI GIAN CHU KỲ — từ lúc bắt đầu tới lúc giao ⚠ chỉ số agile giá trị nhất
⚠ Sự hài lòng của người dùng ⚠ thước đo cuối cùng
⚠ Với đội trong đề — mới sprint thứ ba ⚠ CÒN QUÁ SỚM để kết luận gì từ tốc độ; cần ít nhất 3–5 sprint mới có xu hướng đáng tin

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Tốc độ đội bạn có bị dùng làm chỉ tiêu không | | | Tốc độ có ổn định qua các sprint không | | | Có ai so sánh tốc độ giữa các đội không | ⚠ nếu có thì lạm phát điểm chỉ là chuyện thời gian |

Và câu trả lời ngắn nhất cho đội đang muốn biết mình làm tốt hay không: tốc độ nói cho các bạn biết còn bao lâu nữa xong, chứ không nói các bạn giỏi hay dở — muốn biết vế sau thì hỏi người dùng.

Câu 499 People
Madison is working on user stories for her new agile project, which includes a new offshore team. Their primary language is not the same as Madison's. Given this knowledge of the cultural difference, the Team Leader for the project is likely to encourage Madison to
  1. A To set up a matrix that provides traceability to all requirements for reference.
  2. B To ensure all user stories are 100% documented, where there is nothing that the offshore team will assume.
  3. C None of the above.
  4. D Provide a bit more detail in her documentation of user stories, and make an extra effort to ensure the offshore team members share in her understanding.
Xem giải thích

Đáp án

D — Ghi CHI TIẾT HƠN MỘT CHÚT trong tài liệu câu chuyện người dùng, và NỖ LỰC THÊM để bảo đảm đội ở xa hiểu giống mình.

Vì sao đúng

⚠ Vì sao đây là mức cân bằng đúng: | Yếu tố | Nội dung | |---|---| | ⚠ "CHI TIẾT HƠN MỘT CHÚT" — không phải tài liệu hoá 100% | ⚠ vẫn giữ tinh thần agile | | ⚠ Nhận ra rào cản NGÔN NGỮ là có thật, không phớt lờ | | | ⚠ "NỖ LỰC THÊM để cùng hiểu" — nhấn vào ĐỐI THOẠI, không chỉ văn bản | ⚠ vế quan trọng nhất | | ⚠ Câu chuyện người dùng vốn là LỜI HỨA SẼ TRÒ CHUYỆN, không phải đặc tả | | | ⚠ Kết luận | ⚠ thêm tài liệu để giảm hiểu nhầm, nhưng không thay thế được việc trao đổi |

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

  • B (bảo đảm mọi câu chuyện được tài liệu hoá 100%, không để đội ở xa phải giả định gì) — ⚠ phương án gây nhiễu mạnh nhất vì nghe rất chu đáo: ⚠ nhưng ⚠ "100% tài liệu" là BẤT KHẢ THI ⚠ — luôn còn ngữ cảnh ngầm không viết ra được; ⚠ và nó ⚠ biến agile thành thác nước, ⚠ giết mất tinh thần "trò chuyện hơn tài liệu".

  • A (lập ma trận truy vết mọi yêu cầu) — ⚠ công cụ hữu ích nhưng KHÔNG giải quyết vấn đề NGÔN NGỮ; ⚠ truy vết khác hiểu nhau ⚠ (liên hệ #26095 lô 187).

  • C (không phương án nào ở trên) — ⚠ sai vì D đúng.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26192 ở lô này (NHIỄU trong mô hình truyền thông — khác ngôn ngữ là nguồn nhiễu điển hình), ⚠ câu #26214 ở lô này (đội ảo cần công cụ theo dõi), ⚠ câu #26216 ở lô này (chọn phương thức truyền thông), ⚠ câu #26157/#26181 lô 188 (persona — hiểu người dùng).

⚠ Làm việc với đội ở xa khác ngôn ngữ — những gì cần điều chỉnh: | Điều chỉnh | Nội dung | |---|---| | ⚠ Viết chi tiết hơn, dùng câu NGẮN và từ ĐƠN GIẢN | ⚠ tránh thành ngữ và lối nói bóng gió | | ⚠ Dùng HÌNH VẼ, sơ đồ, ảnh chụp màn hình | ⚠ hình ảnh vượt rào ngôn ngữ tốt hơn chữ | | ⚠ Lập TỪ ĐIỂN THUẬT NGỮ chung | ⚠ giảm nhiễu ở gốc | | ⚠ XÁC NHẬN cách hiểu, đừng hỏi "hiểu chưa" | ⚠ hỏi "bạn nhắc lại giúp tôi ta sẽ làm gì" — quan trọng nhất | | ⚠ Ưu tiên gặp mặt qua video hơn là chat | ⚠ thấy nét mặt giúp hiểu nhau nhiều | | ⚠ Chồng lấn múi giờ ít nhất vài giờ mỗi ngày | | | ⚠ Lưu ý văn hoá | ⚠ ở nhiều nền văn hoá, gật đầu không có nghĩa là đã hiểu — nó có nghĩa là đang nghe |

Từ khoá nhận diện:

"chi tiết hơn một chút + nỗ lực để hiểu chung" → ⚠ cân bằng đúng "tài liệu hoá 100%" → ⚠ bất khả thi và phản agile "ma trận truy vết" → ⚠ hữu ích nhưng không giải quyết rào cản ngôn ngữ "không phương án nào" → ⚠ thường sai khi có một phương án hợp lý

⚠ Ba chữ C của câu chuyện người dùng — vì sao chi tiết KHÔNG thay được trò chuyện Chữ C
⚠ CARD (thẻ) ⚠ mô tả ngắn — chỗ mà "chi tiết hơn một chút" tác động
⚠ CONVERSATION (trò chuyện) ⚠ nơi ý nghĩa THẬT SỰ được truyền — không văn bản nào thay được
⚠ CONFIRMATION (xác nhận) ⚠ tiêu chí chấp nhận — cách kiểm chứng đã hiểu đúng
⚠ Với đội ở xa ⚠ chữ C thứ hai khó nhất, nên phải bù bằng chữ C thứ nhất và thứ ba mạnh hơn
⚠ Nhưng đừng bù quá tay ⚠ bỏ hẳn trò chuyện mà chỉ gửi tài liệu là quay về thác nước — và hiểu nhầm vẫn xảy ra, chỉ muộn hơn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Câu chuyện của bạn có tiêu chí chấp nhận rõ ràng không | | | Bạn xác nhận cách hiểu thế nào | ⚠ hỏi "hiểu chưa" gần như luôn nhận được câu "rồi" | | Đội ở xa có kênh hỏi lại dễ dàng không | ⚠ hỏi khó thì người ta đoán, và đoán thì sai |

Và điều Madison cần nhớ nhất: hiểu nhầm với đội ở xa hiếm khi lộ ra lúc nhận việc — nó lộ ra ở buổi trình diễn, khi đã muộn hai tuần.

Câu 500 Process
Evelyn is a product owner at Greyjoy Gaming. She knows that it is important to
  1. A Make sure not to attend any daily standup meetings, which are focused only on the core team.
  2. B Convey the focus of a sprint at the start of each meeting.
  3. C Get feedback and input from the rest of the team when she talks about the focus of a given sprint.
  4. D Complete the backlog priority on her own alone, as it is her responsibility.
Xem giải thích

Đáp án

C — LẤY PHẢN HỒI và ý kiến của đội khi cô nói về trọng tâm của một sprint.

Vì sao đúng

⚠ Vì sao phản hồi của đội là điều quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Product owner quyết CÁI GÌ, đội quyết LÀM THẾ NÀO và BAO NHIÊU | ⚠ ranh giới vai trò | | ⚠ Đội biết rõ nhất điều gì KHẢ THI trong một sprint | | | ⚠ Trọng tâm sprint phải là thứ ĐỘI HIỂU và TIN | ⚠ không phải mệnh lệnh truyền xuống | | ⚠ Đội hiểu VÌ SAO thì đưa ra quyết định kỹ thuật tốt hơn | ⚠ liên hệ #26211 cùng lô | | ⚠ Bản chất | ⚠ họp kế hoạch sprint là cuộc ĐỐI THOẠI, không phải buổi giao việc |

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

  • B (truyền đạt trọng tâm sprint ở đầu mỗi buổi họp) — ⚠ phương án gây nhiễu mạnh nhất vì đây là ⚠ thực hành TỐT và Evelyn NÊN làm: ⚠ nhưng nó ⚠ CHỈ MỘT CHIỀU ⚠ — nói cho đội biết mà không nghe lại; ⚠ phương án C bao trùm nó và thêm phần quan trọng hơn: vòng phản hồi.

  • D (tự mình hoàn thành việc xếp ưu tiên backlog vì đó là trách nhiệm của cô) — ⚠ NỬA ĐÚNG NỬA SAI: ⚠ product owner ⚠ CHỊU TRÁCH NHIỆM CUỐI CÙNG về thứ tự backlog, ⚠ nhưng ⚠ "một mình" là sai — ⚠ cô cần đầu vào từ đội (chi phí, rủi ro kỹ thuật) và từ bên liên quan.

  • A (không dự buổi họp đứng nào vì đó chỉ dành cho đội nòng cốt) — ⚠ SAI: ⚠ product owner ⚠ được phép và thường nên dự ⚠ họp đứng — chỉ là ⚠ không điều hành và không biến nó thành buổi báo cáo.

Ghi nhớ

⚠ Đối chiếu: ⚠ câu #26041 lô 186 (product owner đại diện tiếng nói khách hàng), ⚠ câu #26211 ở lô này (đội phát hiện việc không tạo giá trị → nói với product owner), ⚠ câu #26197 ở lô này (phong cách hợp tác), ⚠ câu #26212 ở lô này (ba ngón cái — cách lấy phản hồi nhanh).

⚠ Ranh giới vai trò trong scrum: | Ai quyết | Cái gì | |---|---| | ⚠ PRODUCT OWNER | ⚠ CÁI GÌ và THỨ TỰ ƯU TIÊN — trách nhiệm cuối cùng là của cô | | ⚠ ĐỘI PHÁT TRIỂN | ⚠ LÀM THẾ NÀO và NHẬN BAO NHIÊU trong một sprint | | ⚠ SCRUM MASTER | ⚠ quy trình chạy đúng, gỡ vật cản — liên hệ #26177 lô 188 | | ⚠ Chỗ giao nhau | ⚠ mục tiêu sprint được thống nhất CHUNG giữa product owner và đội | | ⚠ Vi phạm ranh giới thường gặp | ⚠ product owner ép đội nhận thêm việc, hoặc đội tự đổi thứ tự ưu tiên |

Từ khoá nhận diện:

"lấy phản hồi và ý kiến của đội" → ⚠ đúng — hai chiều "truyền đạt trọng tâm sprint" → ⚠ tốt nhưng mới một chiều "tự làm backlog một mình" → ⚠ trách nhiệm là của cô nhưng đầu vào phải từ nhiều phía "không dự họp đứng" → ⚠ sai — được dự, chỉ không điều hành

⚠ Product owner lấy đầu vào từ những ai Nguồn
⚠ ĐỘI PHÁT TRIỂN ⚠ chi phí, rủi ro kỹ thuật, phụ thuộc — CÂU NÀY
⚠ NGƯỜI DÙNG CUỐI ⚠ giá trị thật — liên hệ #26181 lô 188, persona
⚠ BÊN LIÊN QUAN kinh doanh ⚠ mục tiêu chiến lược
⚠ Dữ liệu vận hành và phản hồi sau phát hành
⚠ Nhưng QUYẾT ĐỊNH cuối cùng ⚠ là của product owner — một người, để backlog có một thứ tự nhất quán
⚠ Vì sao phải một người quyết ⚠ ưu tiên theo uỷ ban thì mọi thứ đều là ưu tiên số một
⚠ Một trọng tâm sprint tốt trông thế nào Đặc điểm
⚠ Nói được bằng MỘT CÂU
⚠ Nói về GIÁ TRỊ, không phải danh sách việc ⚠ "giúp người dùng thanh toán bằng ví điện tử" chứ không phải "làm xong 8 hạng mục"
⚠ Đội GẬT ĐẦU vì hiểu, không vì được giao ⚠ đây là kết quả của việc lấy phản hồi
⚠ Đủ linh hoạt để đội chọn cách đạt
⚠ Tác dụng lớn nhất ⚠ khi có việc phát sinh giữa sprint, đội tự quyết được cái gì bỏ, cái gì giữ — vì họ biết trọng tâm là gì

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có nói được mục tiêu sprint hiện tại không | ⚠ hỏi thử, kết quả thường bất ngờ | | Product owner của bạn có nghe đội không | ⚠ hay chỉ thông báo | | Thứ tự backlog có được giải thích lý do không | |

Và điều làm nên khác biệt giữa một product owner tốt và một người chỉ giữ danh sách việc: người tốt rời buổi họp kế hoạch với vài điều mình chưa biết trước khi vào phòng.