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

Tìm thấy 718 câu.

Câu 581 People
Mia is an agile leader at Northview Investments. She has invited all of the project's stakeholders to the scheduled planning meetings, including customers and sponsors. All but one of the following are valid reasons for the invite. Which one is invalid?
  1. A She invited all of the project's stakeholders to determine the success or failure of one of the team members.
  2. B She invited all of the project's stakeholders so that everyone's concerns can be heard.
  3. C She invited all of the project's stakeholders to assist in the discovery of issues in the project.
  4. D She invited all of the project's stakeholders to ensure that all of the project members' priorities are being addressed.
Xem giải thích

Đáp án

A — CÔ ẤY MỜI TẤT CẢ BÊN LIÊN QUAN ĐỂ XÁC ĐỊNH SỰ THÀNH CÔNG HAY THẤT BẠI CỦA MỘT THÀNH VIÊN TRONG ĐỘI.

Vì sao đúng

⚠ Vì sao đây là lý do KHÔNG hợp lệ: | Vấn đề | Nội dung | |---|---| | ⚠ Buổi lập kế hoạch bàn về CÔNG VIỆC, không về CON NGƯỜI | ⚠ sai mục đích hoàn toàn | | ⚠ Đánh giá cá nhân là chuyện RIÊNG TƯ | ⚠ liên hệ #26918 lô 203 | | ⚠ Đưa bên liên quan vào việc đánh giá nội bộ là vượt ranh giới | | | ⚠ Phá huỷ an toàn tâm lý của cả đội | ⚠ không ai dám phát biểu nữa | | ⚠ Agile đo thành công của ĐỘI, không của cá nhân | ⚠ đội chịu trách nhiệm tập thể | | ⚠ Kết luận | ⚠ ba lý do còn lại đều hướng tới công việc và giá trị; riêng lý do này hướng vào một con người |

⚠ Ba lý do hợp lệ có điểm chung: ⚠ nghe được mối lo của mọi người, phát hiện vấn đề sớm, và bảo đảm mọi ưu tiên đều được xem xét ⚠ — ⚠ cả ba đều làm cho KẾ HOẠCH tốt hơn.

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

  • D (để bảo đảm mọi ưu tiên của thành viên dự án đều được xem xét) — ⚠ phương án gây nhiễu mạnh nhất trong ba lý do hợp lệ vì ⚠ cụm "ưu tiên của các thành viên dự án" nghe hơi lạ: chẳng phải chủ sản phẩm mới là người xếp ưu tiên hay sao: ⚠ nhưng ⚠ ở đây "ưu tiên" mang nghĩa các mối quan tâm và ràng buộc mà từng bên đưa vào cuộc thảo luận, chứ không phải thứ tự tồn đọng ⚠; ⚠ và việc bảo đảm mọi góc nhìn được xem xét trong buổi lập kế hoạch là mục đích chính đáng của việc mời đông đủ; ⚠ liên hệ #26986 cùng lô: giá trị của một cuộc thảo luận nằm ở chỗ các quan điểm khác nhau được đưa ra bàn.

  • B (để mọi mối lo đều được nghe) — ⚠ lý do hoàn toàn chính đáng; ⚠ liên hệ #26950 lô 204 về việc tạo sự đồng thuận.

  • C (để hỗ trợ phát hiện các vấn đề của dự án) — ⚠ cũng chính đáng; ⚠ nhiều góc nhìn thì phát hiện rủi ro sớm hơn — liên hệ #26928 lô 203.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26950 lô 204 (cả nhóm cùng giải quyết vấn đề tạo đồng thuận), ⚠ #26986 cùng lô (thảo luận mới sinh ra phương án tốt hơn), ⚠ #26918 lô 203 (chuyện cá nhân phải giữ kín), ⚠ #26942 lô 204 (bên liên quan dự buổi rà soát chặng).

⚠ Mời bên liên quan dự họp lập kế hoạch — lợi ích: | Lợi ích | Nội dung | |---|---| | ⚠ Nghe được mối lo trước khi chúng thành vấn đề | | | ⚠ Phát hiện ràng buộc mà đội không biết | ⚠ quy định, lịch của bộ phận khác | | ⚠ Tạo cam kết với kế hoạch chung | ⚠ liên hệ #26941 lô 204 | | ⚠ Người quyết định có mặt tại chỗ | ⚠ rút ngắn thời gian chờ quyết | | ⚠ Cái giá phải trả | ⚠ họp đông thì lâu hơn và khó điều phối hơn — nên phải có người điều phối tốt và một chương trình rõ ràng; xem #26944 lô 204 |

⚠ Đánh giá cá nhân nên diễn ra ở đâu: | Nơi | Nội dung | |---|---| | ⚠ Trao đổi RIÊNG giữa hai người | ⚠ liên hệ #26859 lô 202 | | ⚠ Quy trình đánh giá hiệu suất của tổ chức | ⚠ với quản lý chức năng | | ⚠ Buổi kèm cặp một–một | ⚠ liên hệ #27016 cùng lô | | ⚠ TUYỆT ĐỐI KHÔNG trong buổi họp có bên liên quan | | | ⚠ Nguyên tắc bất biến | ⚠ khen công khai, góp ý riêng tư — và việc mời người ngoài đội tới chứng kiến một cuộc đánh giá cá nhân vi phạm nguyên tắc đó theo cách nặng nhất có thể |

⚠ Vì sao agile đo thành công theo ĐỘI: | Lý do | Nội dung | |---|---| | ⚠ Sản phẩm là kết quả của cả đội | ⚠ khó tách phần đóng góp của từng người | | ⚠ Đo cá nhân tạo cạnh tranh nội bộ | ⚠ người ta thôi giúp nhau | | ⚠ Nó khuyến khích tối ưu cục bộ | ⚠ mỗi người lo phần mình, không ai lo tổng thể | | ⚠ Hệ quả | ⚠ chỉ số cá nhân trong một đội agile gần như luôn phản tác dụng — nó khiến người ta tối ưu con số của mình thay vì tối ưu kết quả chung, và trong một đội nhỏ thì thiệt hại lộ ra rất nhanh |

Từ khoá nhận diện:

"để đánh giá thành bại của một thành viên" → ⚠ lý do KHÔNG hợp lệ "để nghe mọi mối lo" → ⚠ hợp lệ "để phát hiện vấn đề" → ⚠ hợp lệ "để mọi ưu tiên được xem xét" → ⚠ hợp lệ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi lập kế hoạch của bạn có mời đủ các góc nhìn không | | | Bạn có bao giờ nêu chuyện cá nhân trong họp chung không | | | Đội bạn được đo theo tập thể hay theo cá nhân | |

Và ranh giới đơn giản nhất để biết một cuộc họp có mời đúng người hay không: hỏi xem cuộc họp này bàn về CÔNG VIỆC hay bàn về MỘT NGƯỜI — và nếu là vế sau thì danh sách khách mời phải ngắn lại rất nhiều.

Câu 582 Process
Nancy is the project manager for Project G, which is in its fifth week, has a budget of $150,000, and is one week ahead of schedule. This project is being utilized in a health care environment, and quality is paramount for the project team. Recently a team member noted many deliverables are being returned after failing quality checks. What should Nancy do next?
  1. A Implement more quality inspections.
  2. B Hire a new quality analyst.
  3. C Investigate the root cause of the poor quality.
  4. D Do nothing. Some amount of poor quality is expected.
Xem giải thích

Đáp án

C — ĐIỀU TRA NGUYÊN NHÂN GỐC CỦA VIỆC CHẤT LƯỢNG KÉM.

Vì sao đúng

⚠ Vì sao phải tìm nguyên nhân gốc trước: | Lý do | Nội dung | |---|---| | ⚠ CHƯA AI biết vì sao chất lượng kém | ⚠ mới chỉ có một thành viên NHẬN THẤY hiện tượng | | ⚠ Nhiều nguyên nhân có thể có | ⚠ yêu cầu mơ hồ, thiếu kỹ năng, quy trình sai, áp lực thời gian | | ⚠ Mỗi nguyên nhân cần một cách chữa khác nhau | ⚠ chữa nhầm thì tốn tiền mà không hết bệnh | | ⚠ Đây là môi trường y tế, chất lượng là tối quan trọng | ⚠ càng không được đoán | | ⚠ Kết luận | ⚠ chẩn đoán trước, kê đơn sau — nguyên tắc không có ngoại lệ |

⚠ Đề còn cho biết dự án đang SỚM hơn tiến độ một tuần: ⚠ tức là có thời gian để làm việc này cho tử tế ⚠ — ⚠ và cũng gợi ý một giả thuyết đáng kiểm tra: liệu tốc độ đang được đổi lấy chất lượng hay không.

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

  • A (tăng cường kiểm tra chất lượng) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ thêm kiểm tra chắc chắn sẽ BẮT ĐƯỢC nhiều lỗi hơn, nên cảm giác là vấn đề đang được xử lý: ⚠ nhưng ⚠ kiểm tra chỉ PHÁT HIỆN lỗi chứ không NGĂN lỗi phát sinh — chất lượng phải được xây vào sản phẩm chứ không kiểm tra ra được ⚠; ⚠ nó cũng làm tăng chi phí thẩm định mà không giảm chi phí hỏng hóc; ⚠ liên hệ #26945 lô 204: đầu tư đúng chỗ là vào nhóm PHÒNG NGỪA, mà muốn biết phòng ngừa cái gì thì phải biết nguyên nhân gốc trước.

  • B (tuyển một chuyên viên phân tích chất lượng mới) — ⚠ tốn kém và có thể không giải quyết đúng vấn đề; ⚠ nếu nguyên nhân là yêu cầu mơ hồ thì thêm người kiểm tra cũng vô ích.

  • D (không làm gì, chất lượng kém ở mức nào đó là bình thường) — ⚠ sai, đặc biệt trong môi trường y tế; ⚠ và "nhiều" sản phẩm bàn giao bị trả lại không phải là mức bình thường ở bất kỳ đâu.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27019 cùng lô (cùng chủ đề chất lượng kém, khoá là cấp thêm thời gian cho bảo đảm chất lượng — đọc ghi chú chất lượng câu hỏi ở bài đó), ⚠ #26898 lô 203 (phân tích nguyên nhân gốc), ⚠ #26945 lô 204 (chi phí chất lượng), ⚠ #27011 cùng lô (kế hoạch quản lý chất lượng).

⚠ Ghi chú đối chiếu: ⚠ #27019 và câu này rất giống nhau về hiện tượng nhưng khác nhau ở một chi tiết quyết định ⚠ — ⚠ ở #27019, vấn đề được nêu tại buổi CẢI TIẾN, tức là đội đã cùng phân tích rồi, nên bước tiếp theo là hành động; ở đây mới chỉ có một thành viên NHẬN THẤY hiện tượng, chưa có phân tích nào, nên phải điều tra trước; ⚠ quy tắc rút ra: đọc kỹ xem đề đã cho một bước phân tích tập thể nào chưa.

⚠ Các công cụ tìm nguyên nhân gốc: | Công cụ | Nội dung | |---|---| | ⚠ Biểu đồ xương cá (Ishikawa) | ⚠ nhóm nguyên nhân theo con người, quy trình, thiết bị, vật liệu, môi trường | | ⚠ Năm lần hỏi tại sao | ⚠ đơn giản mà hiệu quả bất ngờ | | ⚠ Biểu đồ Pareto | ⚠ 80% lỗi thường đến từ 20% nguyên nhân | | ⚠ Biểu đồ kiểm soát | ⚠ phân biệt biến thiên thường và bất thường — liên hệ #27011 cùng lô | | ⚠ Biểu đồ phân tán | ⚠ tìm tương quan giữa hai yếu tố | | ⚠ Bắt đầu từ đâu | ⚠ Pareto trước để biết loại lỗi nào chiếm đa số, rồi mới đào sâu loại đó bằng xương cá hoặc năm lần hỏi tại sao — làm ngược lại sẽ tốn công cho những lỗi hiếm gặp |

⚠ Các nguyên nhân gốc thường gặp của chất lượng kém: | Nguyên nhân | Cách chữa tương ứng | |---|---| | ⚠ Yêu cầu hoặc tiêu chí chấp nhận mơ hồ | ⚠ làm rõ trước khi làm — liên hệ #26937 lô 204 | | ⚠ Thiếu kỹ năng hoặc thiếu đào tạo | ⚠ liên hệ #26945 lô 204 | | ⚠ Không đủ thời gian cho kiểm thử | ⚠ liên hệ #27019 cùng lô | | ⚠ Quy trình có lỗ hổng | ⚠ sửa quy trình, thêm danh mục kiểm tra — #27021 cùng lô | | ⚠ Công cụ hoặc môi trường không phù hợp | | | ⚠ Điểm chung quan trọng | ⚠ không nguyên nhân nào trong số này được chữa bằng cách kiểm tra nhiều hơn — kiểm tra chỉ cho biết vấn đề vẫn còn đó |

⚠ Nancy nên làm gì cụ thể: | Bước | Nội dung | |---|---| | ⚠ Thu thập dữ liệu về các lỗi đã xảy ra | ⚠ loại lỗi, tần suất, ở khâu nào | | ⚠ Họp với đội, không đổ lỗi | ⚠ liên hệ #26950 lô 204 | | ⚠ Dùng Pareto và năm lần hỏi tại sao | | | ⚠ Chọn một tới hai nguyên nhân lớn nhất để xử lý | | | ⚠ Đo lại sau vài tuần | | | ⚠ Điều đáng lưu ý | ⚠ dự án đang SỚM một tuần — nên rất đáng kiểm tra giả thuyết rằng đội đang chạy nhanh bằng cách bỏ bớt các bước chất lượng; nếu đúng vậy thì con số "sớm một tuần" là một khoản vay chứ không phải một thành tích |

Từ khoá nhận diện:

"nhiều sản phẩm trượt kiểm tra, chưa ai phân tích" → ⚠ ĐIỀU TRA NGUYÊN NHÂN GỐC "tăng cường kiểm tra" → ⚠ phát hiện chứ không ngăn lỗi "tuyển thêm người kiểm tra" → ⚠ tốn kém, có thể sai nguyên nhân "chất lượng kém là bình thường" → ⚠ sai, nhất là trong môi trường y tế

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có dữ liệu về loại lỗi hay gặp nhất không | | | Lần gần nhất chất lượng kém, bạn chữa triệu chứng hay nguyên nhân | | | Dự án đang sớm tiến độ của bạn có đang vay từ chất lượng không | |

Và lý do việc tăng cường kiểm tra luôn hấp dẫn hơn việc tìm nguyên nhân: nó cho cảm giác đang hành động ngay lập tức — trong khi thứ duy nhất nó bảo đảm là bạn sẽ nhìn thấy đúng vấn đề đó thêm nhiều lần nữa.

Câu 583 People
Jenny is a project manager for the Mars Insight Organization and she has inherited Project WKS from a project manager who left the organization. Jenny decides she needs to speak with the key stakeholders to speak with them about her role in the project and get a sense of their attitude towards the project. Jenny quickly learns that the different groups of stakeholders are not speaking with one another, though they need to collaborate on the project requirements. Each group refuses to attend meetings with the other group, and any interaction escalates quickly. What should Jenny do next in this situation?
  1. A Do nothing. Eventually, they will realize the need to work together.
  2. B Meet with each group separately to understand the source of their conflict.
  3. C Invite both parties to one meeting and tell them they must work together.
  4. D Escalate the situation to the project management office.
Xem giải thích

Đáp án

B — GẶP RIÊNG TỪNG NHÓM ĐỂ HIỂU NGUỒN CƠN CỦA MÂU THUẪN.

Vì sao đúng

⚠ Vì sao gặp riêng trước là bước đúng: | Lý do | Nội dung | |---|---| | ⚠ Jenny CHƯA BIẾT mâu thuẫn bắt nguồn từ đâu | ⚠ cô ấy vừa tiếp quản dự án | | ⚠ Người ta nói thật hơn khi không có phía bên kia | | | ⚠ Mỗi bên có một phiên bản câu chuyện | ⚠ sự thật thường nằm ở giữa | | ⚠ Đưa hai bên vào phòng ngay sẽ leo thang | ⚠ đề nói mọi tương tác đều bùng lên rất nhanh | | ⚠ Kết luận | ⚠ hiểu trước, hoà giải sau — và gặp riêng là cách duy nhất để hiểu ở giai đoạn này |

⚠ Vị thế của Jenny là một lợi thế: ⚠ cô ấy là người MỚI, không thuộc phe nào và chưa có lịch sử với ai ⚠ — ⚠ đó là điều kiện lý tưởng để làm trung gian, và cửa sổ thời gian đó không kéo dài lâu.

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

  • C (mời cả hai bên vào một cuộc họp và nói rằng họ phải hợp tác) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ đưa hai bên ngồi lại với nhau ĐÚNG LÀ đích đến, và giải quyết vấn đề trực diện thường là cách tiếp cận tốt nhất: ⚠ nhưng ⚠ làm điều đó khi chưa hiểu nguyên nhân là đưa hai bên vào một cuộc đối đầu không có người chuẩn bị ⚠ — ⚠ đề đã nói mọi tương tác giữa họ đều leo thang nhanh, nên xác suất buổi họp đó thất bại là rất cao; ⚠ và "bảo họ phải hợp tác" là ÁP ĐẶT chứ không phải giải quyết vấn đề — nó bỏ qua hoàn toàn lý do vì sao họ không hợp tác; ⚠ cuộc họp chung vẫn sẽ diễn ra, chỉ là sau khi Jenny đã biết mình đang xử lý chuyện gì.

  • D (leo thang lên văn phòng quản lý dự án) — ⚠ quá sớm; ⚠ Jenny chưa thử gì cả, và đây là vấn đề trong phạm vi trách nhiệm của cô ấy.

  • A (không làm gì, rồi họ sẽ tự nhận ra cần hợp tác) — ⚠ bỏ mặc một vấn đề đang chặn việc xác định yêu cầu; ⚠ mâu thuẫn để lâu hầu như luôn nặng thêm.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26979 lô 204 (giải quyết xung đột giữa hai nhà thầu), ⚠ #26949 lô 204 (tiếp quản dự án từ người quản lý cũ), ⚠ #26859 lô 202 (gặp riêng khi vấn đề thuộc về cá nhân), ⚠ #26995 cùng lô (xung đột nguồn lực giữa hai đội).

⚠ Quy trình hoà giải xung đột giữa hai nhóm: | Bước | Nội dung | |---|---| | ⚠ 1. Gặp RIÊNG từng nhóm, chủ yếu để nghe | ⚠ bước Jenny cần làm — ĐÁP ÁN | | ⚠ 2. Tìm điểm chung và lợi ích thật của mỗi bên | ⚠ thường nhiều hơn họ tưởng | | ⚠ 3. Chuẩn bị khung cho buổi gặp chung | ⚠ chương trình, quy tắc, mục tiêu cụ thể | | ⚠ 4. Tổ chức buổi gặp chung có điều phối | | | ⚠ 5. Chốt thoả thuận về cách làm việc và GHI LẠI | | | ⚠ Điều dễ làm sai nhất | ⚠ nhảy thẳng vào bước 4 — nó tiết kiệm được vài ngày nhưng thường đốt cháy cơ hội duy nhất để hai bên ngồi lại, và sau một buổi họp thất bại thì việc mời họ lần thứ hai khó hơn nhiều |

⚠ Cần tìm hiểu gì trong buổi gặp riêng: | Câu hỏi | Mục đích | |---|---| | ⚠ Chuyện bắt đầu từ khi nào và từ việc gì | ⚠ thường có một sự kiện gốc cụ thể | | ⚠ Điều gì làm họ khó chịu nhất | | | ⚠ Họ cần gì để dự án thành công | ⚠ chuyển từ lập trường sang LỢI ÍCH | | ⚠ Họ nghĩ phía bên kia muốn gì | ⚠ thường lộ ra hiểu nhầm lớn | | ⚠ Điều kiện nào để họ sẵn sàng ngồi lại | | | ⚠ Câu hỏi giá trị nhất | ⚠ "anh chị nghĩ phía bên kia đang muốn gì" — câu trả lời thường sai lệch rất xa so với thực tế, và chính khoảng cách đó là thứ Jenny có thể thu hẹp |

⚠ Vì sao mâu thuẫn này nguy hiểm cho dự án: | Hậu quả | Nội dung | |---|---| | ⚠ Yêu cầu không được thống nhất | ⚠ hai nhóm cần phối hợp để xác định yêu cầu | | ⚠ Quyết định bị treo | | | ⚠ Đội phát triển nhận chỉ dẫn mâu thuẫn | | | ⚠ Người mới như Jenny dễ bị kéo về một phe | | | ⚠ Ưu tiên cao nhất | ⚠ xử lý sớm, vì mọi thứ khác của dự án đều phụ thuộc vào việc hai nhóm này thống nhất được yêu cầu — và Jenny giữ được vị thế trung lập càng lâu thì khả năng hoà giải càng cao |

Từ khoá nhận diện:

"hai nhóm không chịu nói chuyện, mọi tương tác đều leo thang" → ⚠ GẶP RIÊNG từng nhóm trước "mời cả hai vào họp và bảo phải hợp tác" → ⚠ áp đặt khi chưa hiểu nguyên nhân "leo thang lên PMO" → ⚠ quá sớm, chưa thử gì cả "rồi họ sẽ tự nhận ra" → ⚠ mâu thuẫn để lâu chỉ nặng thêm

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn biết mâu thuẫn trong dự án mình bắt đầu từ đâu không | | | Bạn đã nghe riêng từng bên chưa | | | Bạn còn giữ được vị thế trung lập không | |

Và điều mà một cuộc gặp riêng cho người hoà giải mà một cuộc họp chung không bao giờ cho: phiên bản câu chuyện mà người ta chỉ kể khi phía bên kia không có mặt — và đó thường là phiên bản gần sự thật nhất.

Câu 584 Process
Acceptance Test-Driven Development is different than standard Test-Driven Development. As Debra writes her code, she can expect that she will most likely not have to:
  1. A Focus exclusively on the testing of code.
  2. B Implement upfront testing of requirements.
  3. C Focus on the testing of business requirements.
  4. D Discuss the user story acceptance criteria when it is pulled from the backlog.
Xem giải thích

Đáp án

A — CHỈ TẬP TRUNG DUY NHẤT VÀO VIỆC KIỂM THỬ MÃ.

Vì sao đúng

⚠ ATDD khác TDD ở chỗ nào: | TDD | ATDD | |---|---| | ⚠ Kiểm thử ĐƠN VỊ, do lập trình viên viết | ⚠ kiểm thử CHẤP NHẬN, cả ba vai cùng xây | | ⚠ Kiểm tra MÃ chạy đúng không | ⚠ kiểm tra YÊU CẦU NGHIỆP VỤ được đáp ứng không | | ⚠ Ngôn ngữ kỹ thuật | ⚠ ngôn ngữ nghiệp vụ | | ⚠ Xoay quanh hàm, lớp, mô đun | ⚠ xoay quanh hành vi mà người dùng thấy | | ⚠ Kết luận cho Debra | ⚠ cô ấy sẽ KHÔNG chỉ tập trung vào kiểm thử mã — công việc mở rộng sang phần nghiệp vụ |

⚠ Vì sao câu hỏi dạng phủ định lại rõ ràng ở đây: ⚠ ba phương án còn lại đều mô tả đúng những gì ATDD THÊM VÀO, còn phương án A mô tả đúng phạm vi HẸP của TDD ⚠ — ⚠ đó chính là thứ ATDD vượt ra ngoài.

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

  • B (kiểm thử yêu cầu ngay từ đầu) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cụm "upfront testing" nghe như một việc nặng nề và có vẻ trái với tinh thần agile, nên dễ bị chọn nhầm là điều Debra KHÔNG phải làm: ⚠ nhưng ⚠ đây chính là ĐẶC TRƯNG của ATDD — kiểm thử chấp nhận được viết TRƯỚC khi có mã, từ tiêu chí chấp nhận đã thống nhất ⚠; ⚠ "upfront" ở đây không có nghĩa là làm hết mọi thứ từ đầu dự án, mà là làm trước cho TỪNG câu chuyện khi nó được lấy ra; ⚠ liên hệ #26994 cùng lô về cách ATDD vận hành.

  • C (tập trung vào kiểm thử các yêu cầu nghiệp vụ) — ⚠ đúng là điều Debra SẼ làm; ⚠ đó là bản chất của kiểm thử chấp nhận.

  • D (thảo luận tiêu chí chấp nhận khi câu chuyện được lấy ra khỏi tồn đọng) — ⚠ cũng là điều cô ấy SẼ làm; ⚠ đây là bước mở màn của quy trình ATDD.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26994 cùng lô (đội mới dùng ATDD — CÙNG CHỦ ĐỀ, nên đọc liền nhau), ⚠ #26937 lô 204 (cùng làm rõ yêu cầu mơ hồ khi kiểm thử), ⚠ #26948 lô 204 (TDD ghi lại hệ thống làm gì, không ghi vì sao), ⚠ #26980 lô 204 (tích hợp liên tục là vòng phản hồi tự động).

⚠ Ba phương pháp hướng kiểm thử, so sánh đầy đủ: | Phương pháp | Ai viết kiểm thử | Trả lời câu hỏi | |---|---|---| | ⚠ TDD | ⚠ lập trình viên | ⚠ "ta có xây ĐÚNG CÁCH không" | | ⚠ ATDD | ⚠ nghiệp vụ + phát triển + kiểm thử | ⚠ "ta có xây ĐÚNG THỨ không" | | ⚠ BDD | ⚠ tương tự ATDD | ⚠ nhấn mạnh ngôn ngữ mô tả hành vi | | ⚠ Quan hệ giữa chúng | ⚠ chúng không loại trừ nhau — một đội trưởng thành dùng cả hai: ATDD định nghĩa thế nào là đúng thứ, TDD bảo đảm mã bên trong sạch sẽ |

⚠ Công việc của Debra mở rộng ra sao khi chuyển sang ATDD: | Trước (TDD thuần) | Sau (ATDD) | |---|---| | ⚠ Nhận đặc tả rồi viết mã và kiểm thử đơn vị | ⚠ tham gia làm rõ yêu cầu từ đầu | | ⚠ Làm việc chủ yếu với lập trình viên | ⚠ làm việc với cả nghiệp vụ và kiểm thử | | ⚠ Đo bằng độ phủ mã | ⚠ đo bằng việc tiêu chí chấp nhận có xanh không | | ⚠ Thay đổi lớn nhất về tư duy | ⚠ câu hỏi "mã này có chạy đúng không" được thay bằng "thứ này có phải là điều khách hàng cần không" — và câu thứ hai không trả lời được nếu chỉ ngồi trong trình soạn thảo mã |

⚠ Quy tắc ba người bạn (three amigos): | Vai | Đóng góp | |---|---| | ⚠ Nghiệp vụ (chủ sản phẩm hoặc BA) | ⚠ cần gì và vì sao cần | | ⚠ Phát triển | ⚠ làm được thế nào, tốn bao nhiêu | | ⚠ Kiểm thử | ⚠ làm sao biết là đã xong và đúng | | ⚠ Vì sao cần đủ ba | ⚠ thiếu vai nghiệp vụ thì xây sai thứ; thiếu vai phát triển thì hứa thứ không làm nổi; thiếu vai kiểm thử thì không ai hỏi "thế trường hợp này thì sao" — và câu hỏi đó chính là nơi phần lớn yêu cầu ẩn được phát hiện |

Từ khoá nhận diện:

"ATDD, điều KHÔNG phải làm" → ⚠ chỉ tập trung vào kiểm thử MÃ "kiểm thử yêu cầu từ đầu" → ⚠ là ĐẶC TRƯNG của ATDD, không phải điều loại trừ "kiểm thử yêu cầu nghiệp vụ" → ⚠ bản chất của kiểm thử chấp nhận "thảo luận tiêu chí chấp nhận" → ⚠ bước mở màn của ATDD

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Kiểm thử của đội bạn viết bằng ngôn ngữ kỹ thuật hay ngôn ngữ nghiệp vụ | | | Người viết kiểm thử có tham gia lúc làm rõ yêu cầu không | | | Ba vai của bạn có bao giờ ngồi cùng nhau không | |

Và khác biệt cốt lõi giữa hai phương pháp mà mọi thứ khác đều chảy ra từ đó: TDD hỏi mã có đúng không, ATDD hỏi thứ đang được xây có đáng xây không.

Câu 585 People

In your scrum team's daily standup meeting, several issues come up. Of the following choices, which issue is a blocker?

  1. A The lead developer's internet connection is slower than usual.
  2. B A code bug is found in a testing environment of a new feature.
  3. C A junior developer is out sick.
  4. D The deliverable scheduled to go to production is broken and must be fixed.
Xem giải thích

Đáp án

D — SẢN PHẨM BÀN GIAO SẮP ĐƯA LÊN MÔI TRƯỜNG SẢN XUẤT ĐANG BỊ HỎNG VÀ PHẢI SỬA.

Vì sao đúng

⚠ Vật cản là gì: | Tiêu chí | Nội dung | |---|---| | ⚠ CHẶN ĐỨNG tiến độ, không chỉ làm chậm | ⚠ tiêu chí phân biệt quan trọng nhất | | ⚠ Đội không tự vượt qua được ngay | | | ⚠ Ảnh hưởng tới cam kết của chặng | | | ⚠ Cần được nêu ra và xử lý ngay | ⚠ đúng chức năng của buổi họp đứng | | ⚠ Áp dụng vào phương án D | ⚠ sản phẩm hỏng thì KHÔNG THỂ triển khai — mục tiêu chặng bị chặn hoàn toàn |

⚠ Chữ then chốt trong đề: ⚠ "scheduled to go to production" — nó đã được lên lịch triển khai ⚠ — ⚠ nghĩa là có một cam kết cụ thể đang bị đe doạ, không phải một việc còn xa.

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

  • B (phát hiện lỗi trong môi trường kiểm thử của một tính năng mới) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ "tìm thấy lỗi" nghe rất nghiêm trọng, và trong nhiều tình huống thì lỗi đúng là thứ phải xử lý gấp: ⚠ nhưng ⚠ lỗi được phát hiện trong môi trường KIỂM THỬ chính là hệ thống đang hoạt động đúng như thiết kế ⚠ — ⚠ đó là công việc bình thường của đội, không phải vật cản; ⚠ so sánh trực tiếp với phương án D: một bên là lỗi được bắt đúng nơi cần bắt, một bên là thứ sắp ra môi trường thật mà đang hỏng; ⚠ vật cản không phải là "có việc khó", nó là "không đi tiếp được".

  • A (đường truyền của lập trình viên chính chậm hơn bình thường) — ⚠ gây khó chịu và làm chậm, nhưng anh ấy VẪN làm việc được; ⚠ đây là phiền toái, không phải vật cản.

  • C (một lập trình viên trẻ nghỉ ốm) — ⚠ ảnh hưởng tới năng lực đội nhưng công việc vẫn tiếp tục; ⚠ trở thành vật cản chỉ khi người đó là điểm chết duy nhất của một việc gấp — liên hệ #26920 lô 203.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26911 lô 203 (hỏi về vật cản trong buổi họp đứng), ⚠ #26980 lô 204 (họp đứng để đồng bộ, không phải để phản hồi), ⚠ #26924 lô 203 (tắc ở khâu kiểm thử), ⚠ #27024 cùng lô (chất lượng kém cần tìm nguyên nhân gốc).

⚠ Phân biệt ba mức độ vấn đề: | Mức | Đặc điểm | Cách xử lý | |---|---|---| | ⚠ PHIỀN TOÁI | ⚠ làm chậm, vẫn làm được | ⚠ đội tự xử, ghi lại nếu lặp lại | | ⚠ VẤN ĐỀ | ⚠ cần giải quyết nhưng có thời gian | ⚠ đưa vào sổ vấn đề, có người phụ trách | | ⚠ VẬT CẢN (blocker) | ⚠ CHẶN ĐỨNG công việc — ĐÁP ÁN | ⚠ nêu trong họp đứng, scrum master xử lý ngay | | ⚠ Câu hỏi phân biệt | ⚠ "nếu không xử lý ngay hôm nay thì có ai không làm việc được không" — trả lời có thì đó là vật cản |

⚠ Scrum master làm gì với một vật cản: | Bước | Nội dung | |---|---| | ⚠ Ghi lên bảng theo dõi vật cản | ⚠ hiển thị công khai — liên hệ #27003 cùng lô | | ⚠ Xác định ai có thể gỡ được | ⚠ trong đội hay ngoài đội | | ⚠ Nếu ngoài tầm đội thì LEO THANG ngay | ⚠ đây là việc chính của scrum master | | ⚠ Theo dõi tới khi được gỡ | | | ⚠ Nếu lặp lại nhiều lần thì đưa vào buổi cải tiến | ⚠ liên hệ #27019 cùng lô | | ⚠ Sai lầm phổ biến | ⚠ ghi vật cản lên bảng rồi để đó — một vật cản không có người phụ trách và không có hạn xử lý thì chỉ là một lời than phiền được viết ra đẹp hơn |

⚠ Vì sao phải phân biệt cho đúng: | Nếu gọi mọi thứ là vật cản | Nếu không gọi gì là vật cản | |---|---| | ⚠ Danh sách dài, không ai xử lý nổi | ⚠ vấn đề thật bị chôn vùi | | ⚠ Từ "vật cản" mất sức nặng | ⚠ đội tự chịu đựng cho tới khi trễ hạn | | ⚠ Scrum master thành người chạy vặt | ⚠ scrum master không biết mình cần giúp gì | | ⚠ Điểm cân bằng | ⚠ đội nên nêu ra tất cả, còn scrum master là người PHÂN LOẠI — cách này giữ được thông tin đầy đủ mà vẫn tập trung công sức vào đúng chỗ |

Từ khoá nhận diện:

"sản phẩm sắp triển khai đang hỏng" → ⚠ VẬT CẢN thật sự "tìm thấy lỗi ở môi trường kiểm thử" → ⚠ hệ thống đang hoạt động đúng, việc bình thường "mạng chậm hơn bình thường" → ⚠ phiền toái, vẫn làm việc được "một người nghỉ ốm" → ⚠ ảnh hưởng năng lực, chưa phải vật cản

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bảng vật cản của bạn có bao nhiêu mục đã nằm đó quá ba ngày | | | Mỗi vật cản có người phụ trách không | | | Đội bạn có phân biệt được vật cản với phiền toái không | |

Và câu hỏi duy nhất cần đặt để biết một việc có phải vật cản hay không: có ai đang không làm việc được vì nó — vì mọi thứ khác, dù khó chịu tới đâu, cũng chỉ là công việc.

Câu 586 People
Bricen is a project manager for Blue Sky Organization and has been assigned a new project. It was established that attendance greater than 90 percent would be a key performance indicator for the project's success during the planning. This was determined based on the training that would be needed during the project to complete specific tasks. The last review of the attendance KPI determined that the team was at 85 percent and was considered five percent below the amount of attendance required for success based on the KPI. Bricen should
  1. A Do nothing and see if the key performance indicators go up on the next review.
  2. B Review the key performance indicators to determine if it is still relevant and if the project is actually in jeopardy due to attendance being 85 percent or if the key performance indicators need to be changed.
  3. C Call a meeting with the entire team and cover the key performance indicators again, stressing the importance of attendance and measuring the project's success.
  4. D Review each team member's attendance and determine who has been absent the most, then address the issue so that the key performance indicators go up as necessary on the next review.
Xem giải thích

Đáp án

C — HỌP VỚI TOÀN ĐỘI, NHẮC LẠI CÁC CHỈ SỐ HIỆU SUẤT CHÍNH VÀ NHẤN MẠNH TẦM QUAN TRỌNG CỦA VIỆC THAM DỰ ĐỐI VỚI THÀNH CÔNG CỦA DỰ ÁN.

⚠ Ghi nhớ về chất lượng câu hỏi: ⚠ phương án B rất đáng bảo vệ và nhiều người sẽ chọn nó ⚠ — ⚠ "xem lại xem KPI này còn phù hợp không và dự án có thật sự lâm nguy vì mức 85% hay không" là một câu hỏi rất đúng đắn về mặt quản lý, vì một chỉ số không còn phản ánh thực tế thì việc bám theo nó là vô ích; ⚠ hai điểm bênh vực cho khoá C: thứ nhất, KPI này được thống nhất TRONG GIAI ĐOẠN LẬP KẾ HOẠCH và có căn cứ rõ ràng là nhu cầu đào tạo, nên chưa có lý do gì để nghi ngờ nó ngay lần đầu bị trượt; thứ hai, chính phương án B trong đề BỊ CẮT CỤT giữa câu ("…hay là các chỉ số hiệu suất chính"), một dấu hiệu cho thấy nó không phải phương án được biên tập kỹ; ⚠ trong phòng thi chọn C, nhưng ngoài đời thì việc rà soát lại tính phù hợp của một KPI vẫn là việc nên làm định kỳ.

Vì sao đúng

⚠ Vì sao họp với cả đội là hành động hợp lý: | Lý do | Nội dung | |---|---| | ⚠ Điểm danh là chỉ số của CẢ ĐỘI | ⚠ không phải vấn đề của một cá nhân | | ⚠ KPI được thống nhất từ giai đoạn lập kế hoạch | ⚠ nhắc lại là chính đáng | | ⚠ Đội có thể chưa hiểu VÌ SAO nó quan trọng | ⚠ nó gắn với việc đào tạo cần thiết cho dự án | | ⚠ Can thiệp sớm, ở mức nhẹ nhất | ⚠ mới trượt 5%, chưa cần biện pháp mạnh | | ⚠ Kết luận | ⚠ giải thích cho cả đội trước, rồi mới tới các bước cá nhân hoá nếu cần |

⚠ Điểm mấu chốt là chữ "VÌ SAO": ⚠ một chỉ tiêu điểm danh nghe rất hình thức cho tới khi người ta hiểu rằng vắng mặt nghĩa là bỏ lỡ phần đào tạo cần cho công việc ⚠ — ⚠ liên hệ #26936 lô 204 về việc giải thích giá trị thay vì áp đặt.

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

  • D (rà từng người xem ai vắng nhiều nhất rồi xử lý riêng người đó) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó dựa trên dữ liệu và nhắm đúng vào nguồn gốc con số, nghe rất có phương pháp: ⚠ nhưng ⚠ nó nhảy thẳng sang mức CÁ NHÂN khi chưa thử mức tập thể ⚠ — ⚠ và điều tra ai vắng nhiều nhất mang màu sắc truy tìm thủ phạm; ⚠ có thể mức 85% đến từ việc tất cả cùng vắng một chút chứ không phải một vài người vắng nhiều, và trong trường hợp đó thì cách tiếp cận cá nhân hoàn toàn sai đích; ⚠ thứ tự đúng: nói với cả đội trước, nếu vẫn không cải thiện thì mới trao đổi riêng — liên hệ #26931 lô 203.

  • A (không làm gì, chờ xem kỳ sau có lên không) — ⚠ bỏ qua một chỉ số đã được đặt ra có chủ đích; ⚠ và mất thời gian một chu kỳ.

  • B (xem lại KPI còn phù hợp không) — ⚠ là câu hỏi hay nhưng chưa phải lúc; ⚠ xem mục "Ghi nhớ về chất lượng câu hỏi" ở trên.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26906 lô 203 (chỉ số hiệu suất chính), ⚠ #26929 lô 203 (mục tiêu SMART), ⚠ #26931 lô 203 (nhắc riêng khi một cá nhân vi phạm quy tắc), ⚠ #26936 lô 204 (giải thích tầm quan trọng của đào tạo).

⚠ Khi một KPI bị trượt, xử lý theo thứ tự nào: | Bước | Nội dung | |---|---| | ⚠ 1. Xác nhận số liệu có đúng không | ⚠ đo sai là chuyện thường gặp | | ⚠ 2. Nói với CẢ ĐỘI, giải thích vì sao chỉ số này quan trọng | ⚠ ĐÁP ÁN | | ⚠ 3. Nếu không cải thiện, tìm hiểu nguyên nhân cụ thể | ⚠ có thể có lý do chính đáng: lịch họp trùng, ca kíp | | ⚠ 4. Trao đổi riêng với người liên quan nếu cần | | | ⚠ 5. Rà soát lại tính phù hợp của chính KPI | ⚠ định kỳ, không phải phản ứng tức thời | | ⚠ Nguyên tắc | ⚠ leo thang từ nhẹ tới nặng, từ tập thể tới cá nhân — nhảy cóc lên bước 4 ngay lần đầu sẽ khiến đội cảm thấy bị giám sát thay vì được nhắc nhở |

⚠ Vì sao KPI điểm danh trong dự án này có căn cứ: | Lý do | Nội dung | |---|---| | ⚠ Dự án đòi hỏi ĐÀO TẠO để làm được một số việc | ⚠ đề nói rõ | | ⚠ Vắng mặt = bỏ lỡ phần đào tạo đó | | | ⚠ Người thiếu đào tạo sẽ gây chất lượng kém | ⚠ liên hệ #26925 lô 203 | | ⚠ Nhận xét | ⚠ đây không phải một KPI hình thức về kỷ luật — nó là một chỉ báo SỚM về năng lực của đội, và Bricen cần truyền đạt đúng ý nghĩa đó thay vì nói về con số 90% |

⚠ Một KPI tốt cần gì: | Yêu cầu | Nội dung | |---|---| | ⚠ Gắn với kết quả thật, không phải với hoạt động | ⚠ điểm danh là chỉ báo cho NĂNG LỰC | | ⚠ Đo được khách quan | | | ⚠ Có ngưỡng rõ ràng | ⚠ 90% ở đây | | ⚠ Đội hiểu vì sao nó tồn tại | ⚠ phần thường bị bỏ qua nhất | | ⚠ Được rà soát định kỳ về tính phù hợp | | | ⚠ Điều hay bị nhầm | ⚠ một chỉ số mà đội không hiểu ý nghĩa sẽ bị "làm cho đẹp" thay vì được cải thiện thật — nên bước giải thích của Bricen quan trọng hơn bản thân con số |

Từ khoá nhận diện:

"KPI của cả đội bị trượt lần đầu" → ⚠ HỌP CẢ ĐỘI, giải thích vì sao nó quan trọng "tìm ai vắng nhiều nhất" → ⚠ nhảy sang mức cá nhân quá sớm "chờ kỳ sau" → ⚠ bỏ qua một chỉ số đã đặt có chủ đích "xem KPI còn phù hợp không" → ⚠ việc nên làm định kỳ, không phải phản ứng đầu tiên

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Đội bạn có hiểu vì sao từng KPI tồn tại không | | | KPI của bạn được rà soát tính phù hợp bao lâu một lần | | | Bạn phản ứng ở mức tập thể hay mức cá nhân trước | |

Và điều quyết định một chỉ số có cải thiện được hay không: việc những người bị đo bằng nó có hiểu nó đang đo cái gì hay không.

Câu 587 Process
Raymond and his vendor have had a successful collaboration for years. They now want to move from traditional project methodologies to an agile methodology. What effect will this most likely have on Raymond’s future contracts?
  1. A Raymond and his vendor will sever their relationship due to the difficulty of procurement with agile methodologies.
  2. B Raymond and his vendor can continue to work together and adjust the contract type to graduated fixed-price or fixed-price work packages.
  3. C Raymond will ensure that the vendor cannot change their pricing after the contracts are signed.
  4. D Raymond will not be allowed to reprioritize or modify the work in any of their agile contracts.
Xem giải thích

Đáp án

B — RAYMOND VÀ NHÀ CUNG CẤP VẪN LÀM VIỆC ĐƯỢC VỚI NHAU VÀ CHỈ CẦN ĐIỀU CHỈNH LOẠI HỢP ĐỒNG SANG GIÁ CỐ ĐỊNH BẬC THANG HOẶC GÓI CÔNG VIỆC GIÁ CỐ ĐỊNH.

Vì sao đúng

⚠ Vì sao agile không phá vỡ quan hệ hợp đồng: | Lý do | Nội dung | |---|---| | ⚠ Agile CÓ các mô hình hợp đồng riêng | ⚠ không phải là không hợp đồng được | | ⚠ Gói công việc giá cố định | ⚠ chia phạm vi thành các khối nhỏ, mỗi khối một giá | | ⚠ Giá cố định bậc thang | ⚠ đơn giá thay đổi theo mức hiệu suất hoặc thời điểm giao | | ⚠ Quan hệ nhiều năm là TÀI SẢN | ⚠ lòng tin sẵn có làm agile dễ hơn nhiều | | ⚠ Kết luận | ⚠ đổi phương pháp thì đổi cấu trúc hợp đồng, không phải đổi đối tác |

⚠ Vì sao quan hệ lâu năm lại là lợi thế lớn: ⚠ hợp đồng agile đòi hỏi mức tin cậy cao hơn vì phạm vi không cố định chi tiết từ đầu ⚠ — ⚠ Raymond và nhà cung cấp đã có sẵn thứ khó xây nhất; liên hệ #26963 lô 204.

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

  • D (Raymond sẽ không được phép xếp lại thứ tự hay điều chỉnh công việc trong bất kỳ hợp đồng agile nào) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ nó chạm đúng nỗi lo thường gặp: hợp đồng thì cứng, agile thì linh hoạt, hai thứ nghe như không đi cùng nhau: ⚠ nhưng ⚠ nó nói NGƯỢC HẲN với thực tế — khả năng xếp lại thứ tự phạm vi chính là ĐẶC ĐIỂM TRUNG TÂM của hợp đồng agile ⚠; ⚠ liên hệ #26963 lô 204, nơi đáp án đúng là "cho phép xếp lại thứ tự phạm vi và nghiệm thu theo sự phù hợp với mục đích nghiệp vụ"; ⚠ hợp đồng agile được thiết kế để cố định TIỀN hoặc THỜI GIAN và để mở NỘI DUNG, chứ không phải khoá cứng cả ba.

  • C (bảo đảm nhà cung cấp không đổi giá sau khi ký) — ⚠ đó là đặc điểm của hợp đồng giá cố định truyền thống; ⚠ nó không nói gì về việc chuyển sang agile và cũng không phải điều quan trọng nhất ở đây.

  • A (hai bên sẽ chấm dứt quan hệ vì mua sắm theo agile quá khó) — ⚠ sai hoàn toàn; ⚠ hàng nghìn tổ chức ký hợp đồng agile hằng ngày.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26963 lô 204 (hợp đồng agile cho phép xếp lại phạm vi), ⚠ #26914 lô 203 và ⚠ #26818 lô 201 (mô hình hợp đồng linh hoạt và định nghĩa hoàn thành), ⚠ #26930 lô 203 (hợp đồng CPIF), ⚠ #26933 lô 204 (giữ quan hệ dài hạn với nhà cung cấp).

⚠ Các mô hình hợp đồng phù hợp với agile: | Mô hình | Cách hoạt động | |---|---| | ⚠ GÓI CÔNG VIỆC GIÁ CỐ ĐỊNH | ⚠ chia thành nhiều gói nhỏ, chốt giá từng gói khi tới lượt | | ⚠ GIÁ CỐ ĐỊNH BẬC THANG | ⚠ đơn giá đổi theo mức hiệu suất hoặc thời điểm bàn giao | | ⚠ Trần chi phí có chia sẻ tiết kiệm | | | ⚠ Điều khoản đổi ngang phạm vi | ⚠ thêm việc mới thì bỏ việc cũ tương đương | | ⚠ Điều khoản kết thúc sớm | ⚠ khách dừng khi đã đủ giá trị, có bồi thường | | ⚠ Điểm chung của tất cả | ⚠ cố định một biến (tiền hoặc thời gian) và để mở biến còn lại (nội dung) — vì cố định cả ba đỉnh tam giác là điều không hợp đồng nào giữ nổi trong thực tế |

⚠ Vì sao gói công việc nhỏ lại hiệu quả: | Lợi ích | Nội dung | |---|---| | ⚠ Rủi ro của mỗi gói nhỏ nên giá sát hơn | ⚠ nhà cung cấp bớt phải độn phí rủi ro | | ⚠ Bên mua có điểm dừng sau mỗi gói | | | ⚠ Phạm vi được điều chỉnh giữa các gói | | | ⚠ Cả hai bên học được từ gói trước | | | ⚠ So với một hợp đồng lớn trọn gói | ⚠ hợp đồng lớn buộc nhà cung cấp phải định giá cho toàn bộ mức bất định của cả dự án — và phí rủi ro đó luôn được tính vào giá, dù rủi ro có xảy ra hay không |

⚠ Điều Raymond nên bàn với nhà cung cấp: | Nội dung | Vì sao | |---|---| | ⚠ Cách đo "hoàn thành" của mỗi gói | ⚠ định nghĩa hoàn thành chung — liên hệ #26914 lô 203 | | ⚠ Nhịp bàn giao và nghiệm thu | | | ⚠ Cách xử lý khi phạm vi cần xếp lại | ⚠ thủ tục, không phải tranh chấp | | ⚠ Mức tham gia của bên mua | ⚠ agile đòi khách hàng có mặt thường xuyên hơn | | ⚠ Điều quan trọng nhất phải nói trước | ⚠ agile chuyển một phần công việc sang phía bên MUA — phải có người trả lời câu hỏi và nghiệm thu liên tục; nếu Raymond không cam kết được điều đó thì mô hình hợp đồng nào cũng sẽ trục trặc |

Từ khoá nhận diện:

"chuyển sang agile với nhà cung cấp cũ" → ⚠ ĐỔI LOẠI HỢP ĐỒNG, giữ đối tác "không được xếp lại phạm vi" → ⚠ ngược hẳn với bản chất hợp đồng agile "khoá giá sau khi ký" → ⚠ đặc điểm hợp đồng giá cố định truyền thống "phải chấm dứt quan hệ" → ⚠ sai hoàn toàn

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Hợp đồng của bạn cố định biến nào và để mở biến nào | | | Bạn có cam kết được người trả lời câu hỏi cho nhà cung cấp không | | | Định nghĩa hoàn thành của hai bên có giống nhau không | |

Và điều mà một quan hệ nhiều năm với nhà cung cấp mang lại khi chuyển sang agile: thứ khó mua nhất trong mọi hợp đồng linh hoạt — lòng tin rằng bên kia sẽ hành xử hợp lý khi có chuyện không lường trước.

Câu 588 Process
George has recently taken over a project from his colleague, Kevin, who is no longer working for the company. With a town-hall meeting quickly approaching, George will need to become familiar with the key stakeholders and understand their influence. Which one of the following options would be the most appropriate steps for George to determine his stakeholders' influence on the project?
  1. A Review the communication management plan and ensure the stakeholder register is current.
  2. B Examine the power/influence grid, and understand what motivates them. But George must become familiar with the stage in which the project is in advance.
  3. C Reassess the stakeholder engagement assessment matrix and add missing stakeholders.
  4. D Speak to the technical design team and determine who the key stakeholders are and if they are happy with the team's progress so far.
Xem giải thích

Đáp án

B — XEM LƯỚI QUYỀN LỰC – ẢNH HƯỞNG VÀ HIỂU ĐIỀU GÌ THÚC ĐẨY HỌ; NHƯNG GEORGE PHẢI NẮM ĐƯỢC DỰ ÁN ĐANG Ở GIAI ĐOẠN NÀO TRƯỚC ĐÃ.

Vì sao đúng

⚠ Vì sao phương án này đầy đủ nhất: | Thành phần | Nội dung | |---|---| | ⚠ Lưới quyền lực – ảnh hưởng | ⚠ công cụ CHUẨN để đánh giá mức ảnh hưởng | | ⚠ Hiểu ĐỘNG CƠ của họ | ⚠ biết ai mạnh chưa đủ, phải biết họ muốn gì | | ⚠ Nắm giai đoạn dự án TRƯỚC | ⚠ vì ảnh hưởng của một người thay đổi theo giai đoạn | | ⚠ George vừa tiếp quản, sắp có họp toàn thể | ⚠ cần bức tranh nhanh và đúng | | ⚠ Kết luận | ⚠ đây là phương án duy nhất nêu đủ cả CÔNG CỤ, NỘI DUNG và ĐIỀU KIỆN TIÊN QUYẾT |

⚠ Vì sao vế "phải biết dự án đang ở giai đoạn nào" lại quan trọng: ⚠ cùng một bên liên quan có ảnh hưởng rất khác nhau ở giai đoạn thiết kế và ở giai đoạn triển khai ⚠ — ⚠ liên hệ #26957 lô 204: vị trí trên ma trận thay đổi theo thời gian.

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

  • A (xem kế hoạch quản lý truyền thông và bảo đảm sổ đăng ký bên liên quan là bản mới nhất) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ cả hai việc này đều đúng và đều nên làm khi tiếp quản một dự án — liên hệ #26949 lô 204: ⚠ nhưng ⚠ chúng trả lời câu hỏi "ai là bên liên quan và ta trao đổi với họ thế nào", chứ không trả lời câu hỏi đề đặt ra là "họ ẢNH HƯỞNG tới dự án ra sao" ⚠; ⚠ sổ đăng ký cho bạn DANH SÁCH, còn lưới quyền lực – ảnh hưởng cho bạn BẢN ĐỒ về sức nặng của từng người; ⚠ liên hệ #26973 lô 204 và #26990 cùng lô: việc lập bản đồ mới là thứ biến danh sách thành hiểu biết.

  • C (rà lại ma trận đánh giá mức tham gia của bên liên quan và bổ sung người còn thiếu) — ⚠ ma trận đó đo THÁI ĐỘ hiện tại so với thái độ mong muốn; ⚠ hữu ích nhưng không phải công cụ đo ảnh hưởng.

  • D (hỏi đội thiết kế kỹ thuật xem ai là bên liên quan chính và họ có hài lòng không) — ⚠ nguồn thông tin gián tiếp và thiên lệch; ⚠ đội kỹ thuật chỉ thấy phần bên liên quan mà họ tiếp xúc.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26973 lô 204 (Cara lập ma trận ảnh hưởng – quan tâm), ⚠ #26990 cùng lô (Donald bổ sung đầu mối vào sổ bên liên quan), ⚠ #26949 lô 204 (tiếp quản dự án thì đọc hồ sơ trước), ⚠ #26957 lô 204 (nhận diện bên liên quan suốt vòng đời), ⚠ #27032 cùng lô (kế hoạch thu hút bên liên quan gồm gì).

⚠ Các lưới phân tích bên liên quan: | Lưới | Hai trục | |---|---| | ⚠ Quyền lực – Quan tâm | ⚠ phổ biến nhất, dùng cho chiến lược trao đổi | | ⚠ QUYỀN LỰC – ẢNH HƯỞNG | ⚠ quyền chính thức và khả năng tác động thực tế — ĐÁP ÁN | | ⚠ Ảnh hưởng – Tác động | ⚠ khả năng tác động và mức bị dự án ảnh hưởng | | ⚠ Mô hình nổi bật (salience) | ⚠ ba chiều: quyền lực, tính cấp bách, tính chính danh | | ⚠ Phân biệt quyền lực và ảnh hưởng | ⚠ quyền lực là thẩm quyền CHÍNH THỨC theo chức vụ; ảnh hưởng là khả năng tác động THỰC TẾ tới quyết định — và trong nhiều tổ chức, người có ảnh hưởng lớn nhất không phải người có chức vụ cao nhất |

⚠ George cần biết gì về giai đoạn dự án: | Giai đoạn | Ai có ảnh hưởng lớn nhất | |---|---| | ⚠ Khởi đầu | ⚠ nhà tài trợ, lãnh đạo phê duyệt vốn | | ⚠ Lập kế hoạch | ⚠ người nắm yêu cầu, chuyên gia nghiệp vụ | | ⚠ Thực hiện | ⚠ người cấp nguồn lực, nhà cung cấp | | ⚠ Bàn giao và vận hành | ⚠ bộ phận tiếp nhận, người dùng cuối | | ⚠ Vì sao George phải biết trước | ⚠ cùng một danh sách bên liên quan, nhưng người anh ấy cần thuyết phục ở buổi họp toàn thể phụ thuộc hoàn toàn vào việc dự án đang ở đâu — chuẩn bị sai trọng tâm là mất cơ hội duy nhất để tạo ấn tượng đầu tiên |

⚠ Hiểu động cơ của bên liên quan bằng cách nào: | Cách | Nội dung | |---|---| | ⚠ Đọc sổ đăng ký nếu người trước có ghi kỳ vọng | ⚠ liên hệ #26949 lô 204 | | ⚠ Gặp riêng từng người trước buổi họp lớn | ⚠ liên hệ #27025 cùng lô | | ⚠ Hỏi "điều gì làm anh chị coi dự án này là thành công" | ⚠ câu hỏi hiệu quả nhất | | ⚠ Quan sát loại câu hỏi họ hay đặt | ⚠ liên hệ #27006 cùng lô | | ⚠ Lợi thế của người mới | ⚠ George có quyền hỏi những câu cơ bản mà người cũ không hỏi được nữa — và cửa sổ đó chỉ mở trong vài tuần đầu tiên |

Từ khoá nhận diện:

"xác định mức ẢNH HƯỞNG của bên liên quan" → ⚠ LƯỚI QUYỀN LỰC – ẢNH HƯỞNG + hiểu động cơ "cập nhật sổ đăng ký" → ⚠ cho danh sách, không cho bản đồ sức nặng "ma trận mức tham gia" → ⚠ đo THÁI ĐỘ, không đo ảnh hưởng "hỏi đội kỹ thuật" → ⚠ nguồn gián tiếp và thiên lệch

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn phân biệt được ai có quyền lực và ai có ảnh hưởng không | | | Bạn biết điều gì thúc đẩy từng bên liên quan chính không | | | Dự án bạn đang ở giai đoạn nào và ai quan trọng nhất lúc này | |

Và điều mà một lưới quyền lực – ảnh hưởng cho biết mà sơ đồ tổ chức thì không: ai là người thật sự làm cho một quyết định xảy ra — và người đó thường không có tên trong ô cao nhất.

Câu 589 Process
One of the best ways that Joshua’s project team incorporates problem-solving into their project at regular intervals is:
  1. A Calculating the projected target date
  2. B Training the team regularly
  3. C Making changes based on learnings found in retrospective meetings
  4. D Paired programming
Xem giải thích

Đáp án

C — THỰC HIỆN CÁC THAY ĐỔI DỰA TRÊN NHỮNG ĐIỀU HỌC ĐƯỢC TỪ CÁC BUỔI HỌP CẢI TIẾN.

Vì sao đúng

⚠ Vì sao buổi cải tiến là cơ chế giải quyết vấn đề định kỳ: | Đặc điểm | Nội dung | |---|---| | ⚠ Diễn ra ĐỀU ĐẶN cuối mỗi chặng | ⚠ đúng chữ "at regular intervals" trong đề | | ⚠ Cả đội cùng nhìn lại cách làm việc | ⚠ nhận diện vấn đề một cách có hệ thống | | ⚠ Kết thúc bằng HÀNH ĐỘNG cụ thể | ⚠ không chỉ nêu vấn đề — liên hệ #27019 cùng lô | | ⚠ Kiểm tra kết quả ở buổi cải tiến sau | ⚠ vòng lặp khép kín | | ⚠ Kết luận | ⚠ nhận diện, phân tích, hành động, kiểm chứng — đủ bốn bước của một chu trình giải quyết vấn đề |

⚠ Chữ quan trọng nhất trong đáp án là "THỰC HIỆN": ⚠ buổi cải tiến chỉ có giá trị khi điều học được biến thành thay đổi thật ⚠ — ⚠ liên hệ #27019 cùng lô về việc buổi cải tiến phải kết thúc bằng hành động.

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

  • D (lập trình đôi) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ lập trình đôi thật sự có giải quyết vấn đề, và nó diễn ra LIÊN TỤC nên nghe rất khớp với ý "đều đặn": ⚠ nhưng ⚠ nó giải quyết vấn đề ở cấp KỸ THUẬT, trong từng dòng mã, ngay tại thời điểm viết ⚠ — ⚠ còn câu hỏi nói về việc đưa giải quyết vấn đề vào DỰ ÁN theo các khoảng đều đặn, tức là ở cấp quy trình và cách làm việc của cả đội; ⚠ liên hệ #26948 lô 204: giá trị chính của lập trình đôi là truyền tri thức và rà soát mã liên tục, không phải cải tiến quy trình.

  • B (đào tạo đội thường xuyên) — ⚠ nâng cao NĂNG LỰC nhưng không phải cơ chế giải quyết vấn đề; ⚠ và đào tạo cần biết vấn đề là gì trước đã.

  • A (tính ngày hoàn thành dự kiến) — ⚠ là hoạt động dự báo tiến độ; ⚠ nó cho biết có vấn đề chứ không giải quyết vấn đề nào.

Ghi nhớ

⚠ Đối chiếu: ⚠ #27019 cùng lô (buổi cải tiến phải sinh ra hành động), ⚠ #26905 lô 203 (cả đội dự buổi cải tiến), ⚠ #26950 lô 204 (cả nhóm cùng giải quyết vấn đề), ⚠ #26980 lô 204 (buổi cải tiến là sự kiện phản hồi thuần tuý nhất).

⚠ Buổi cải tiến khác các sự kiện khác thế nào: | Sự kiện | Bàn về cái gì | Ai dự | |---|---|---| | ⚠ Họp đứng hằng ngày | ⚠ kế hoạch trong ngày | ⚠ đội | | ⚠ Rà soát chặng | ⚠ SẢN PHẨM | ⚠ đội + bên liên quan | | ⚠ HỌP CẢI TIẾN | ⚠ CÁCH LÀM VIỆC — ĐÁP ÁN | ⚠ chỉ đội | | ⚠ Lập kế hoạch chặng | ⚠ việc sẽ làm chặng tới | ⚠ đội + chủ sản phẩm | | ⚠ Vì sao chỉ có đội dự buổi cải tiến | ⚠ để mọi người dám nói thật về những gì chưa ổn — có mặt bên liên quan hoặc cấp trên thì cuộc trò chuyện lập tức đổi tính chất; liên hệ #27023 cùng lô |

⚠ Cấu trúc một buổi cải tiến hiệu quả: | Bước | Nội dung | |---|---| | ⚠ 1. Tạo không khí an toàn | ⚠ nhắc nguyên tắc không đổ lỗi | | ⚠ 2. Thu thập dữ liệu | ⚠ chuyện gì đã xảy ra trong chặng | | ⚠ 3. Tìm hiểu nguyên nhân | ⚠ liên hệ #27024 cùng lô | | ⚠ 4. Quyết định LÀM GÌ | ⚠ một tới ba hành động, có người phụ trách | | ⚠ 5. Chốt và đưa vào chặng tới | | | ⚠ Bước quyết định thành bại | ⚠ bước 4 và 5 — rất nhiều đội làm tốt ba bước đầu rồi dừng lại, và sau vài lần như vậy thì buổi cải tiến trở thành một nghi thức than phiền mà ai cũng biết là vô ích |

⚠ Vì sao "đều đặn" lại quan trọng: | Lý do | Nội dung | |---|---| | ⚠ Vấn đề được xử lý khi còn nhỏ | ⚠ không tích tụ tới mức khó gỡ | | ⚠ Tạo thói quen nhìn lại, không chờ khủng hoảng | | | ⚠ Cải tiến nhỏ tích luỹ thành thay đổi lớn | | | ⚠ Đội biết chắc mình sẽ có dịp để nói | ⚠ nên chịu đựng ít hơn | | ⚠ Nguyên tắc nền của agile | ⚠ "đội định kỳ suy ngẫm về cách làm việc hiệu quả hơn, rồi điều chỉnh hành vi cho phù hợp" — đây là nguyên tắc thứ mười hai của Tuyên ngôn Agile, và nó là nguyên tắc duy nhất nói về việc cải tiến chính bản thân cách làm việc |

Từ khoá nhận diện:

"giải quyết vấn đề theo các khoảng đều đặn" → ⚠ HÀNH ĐỘNG từ buổi CẢI TIẾN "lập trình đôi" → ⚠ giải quyết vấn đề ở cấp kỹ thuật, liên tục "đào tạo thường xuyên" → ⚠ nâng năng lực, không phải cơ chế giải quyết vấn đề "tính ngày hoàn thành dự kiến" → ⚠ dự báo, phát hiện chứ không giải quyết

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Buổi cải tiến gần nhất của bạn sinh ra thay đổi nào | | | Có hành động nào từ buổi cải tiến trước chưa được làm không | | | Đội bạn có dám nói thật trong buổi đó không | |

Và điều phân biệt một đội thật sự cải tiến với một đội chỉ họp cải tiến: ở buổi thứ hai, người ta nói được điều gì đã thay đổi kể từ buổi thứ nhất.

Câu 590 People
The project manager for the Vegas Project, Lucas, has just created its stakeholder management plan based on the projects' requirement of using organizational process assets and enterprise environmental factors. All but which of the following components are included in the stakeholder management plan?
  1. A The stakeholder information schedule distribution
  2. B Stakeholder communication requirements
  3. C Relationships among the project team
  4. D Relationships among stakeholders
Xem giải thích

Đáp án

C — QUAN HỆ GIỮA CÁC THÀNH VIÊN TRONG ĐỘI DỰ ÁN.

Vì sao đúng

⚠ Kế hoạch quản lý bên liên quan gồm gì: | Thành phần | Nội dung | |---|---| | ⚠ Mức tham gia HIỆN TẠI và MONG MUỐN của từng bên | ⚠ trọng tâm của kế hoạch | | ⚠ QUAN HỆ GIỮA CÁC BÊN LIÊN QUAN | ⚠ ai liên minh với ai, ai đối đầu ai | | ⚠ Yêu cầu về TRAO ĐỔI THÔNG TIN của họ | | | ⚠ Lịch phân phối thông tin cho bên liên quan | ⚠ khi nào gửi gì cho ai | | ⚠ Cách cập nhật chính kế hoạch này | | | ⚠ QUAN HỆ NỘI BỘ TRONG ĐỘI | ⚠ KHÔNG thuộc kế hoạch này — ĐÁP ÁN | | ⚠ Lý do | ⚠ quan hệ trong đội thuộc về kế hoạch quản lý NGUỒN LỰC và điều lệ đội, không thuộc quản lý bên liên quan |

⚠ Bẫy nằm ở một chữ: ⚠ "quan hệ giữa các BÊN LIÊN QUAN" là thành phần thật, "quan hệ giữa các thành viên trong ĐỘI" thì không ⚠ — ⚠ hai phương án đứng cạnh nhau và chỉ khác đúng một từ.

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

  • D (quan hệ giữa các bên liên quan) — ⚠ phương án gây nhiễu mạnh nhất, vì nó gần như trùng với đáp án về mặt câu chữ ⚠ nhưng ⚠ đây CHÍNH LÀ một thành phần của kế hoạch, và là một trong những phần giá trị nhất ⚠; ⚠ biết ai liên minh với ai giúp bạn dự đoán được phản ứng dây chuyền: thuyết phục được một người có thể kéo theo ba người khác, hoặc làm mất lòng một người có thể mất luôn cả nhóm của họ; ⚠ liên hệ #27025 cùng lô: chính vì hai nhóm bên liên quan mâu thuẫn nhau mà Jenny không xác định được yêu cầu — đó là ví dụ sống động cho việc vì sao phần này cần được ghi lại.

  • A (lịch phân phối thông tin cho bên liên quan) — ⚠ là thành phần thật; ⚠ khi nào và bằng cách nào thông tin tới tay họ.

  • B (yêu cầu trao đổi thông tin của bên liên quan) — ⚠ cũng là thành phần thật; ⚠ mỗi người cần loại thông tin gì.

Ghi nhớ

⚠ Đối chiếu: ⚠ #26954 lô 204 (hướng dẫn chính thức về vai trò bên liên quan), ⚠ #26957 lô 204 (nhận diện bên liên quan suốt vòng đời), ⚠ #27030 cùng lô (lưới quyền lực – ảnh hưởng), ⚠ #27005 cùng lô (ma trận truyền thông), ⚠ #27025 cùng lô (mâu thuẫn giữa hai nhóm bên liên quan).

⚠ Phân biệt ba kế hoạch hay bị lẫn: | Kế hoạch | Nội dung chính | |---|---| | ⚠ Quản lý BÊN LIÊN QUAN | ⚠ chiến lược thu hút từng bên, mức tham gia, quan hệ giữa họ | | ⚠ Quản lý TRUYỀN THÔNG | ⚠ ai nhận thông tin gì, bằng kênh nào, tần suất nào | | ⚠ Quản lý NGUỒN LỰC | ⚠ vai trò trong đội, cách xây dựng đội, quan hệ nội bộ | | ⚠ Vì sao dễ lẫn | ⚠ ba kế hoạch này chồng lấn nhau khá nhiều, và trong thực tế nhiều tổ chức gộp chúng lại; nhưng trong đề thi thì ranh giới rất rõ, và câu hỏi thường khai thác đúng vùng chồng lấn đó |

⚠ Vì sao ghi lại quan hệ giữa các bên liên quan lại giá trị: | Lợi ích | Nội dung | |---|---| | ⚠ Dự đoán được phản ứng dây chuyền | ⚠ thuyết phục A thì B cũng theo | | ⚠ Biết nên nhờ ai tác động tới ai | ⚠ liên hệ #26974 lô 204 | | ⚠ Tránh vô tình làm mất lòng cả một nhóm | | | ⚠ Nhận ra các mâu thuẫn tiềm ẩn sớm | ⚠ liên hệ #27025 cùng lô | | ⚠ Lưu ý về cách ghi | ⚠ phần này chứa nhận định về con người nên tuyệt đối không phải tài liệu công khai — hãy ghi khách quan, dựa trên hành vi quan sát được, và đừng viết điều bạn không muốn chính người đó đọc |

⚠ Kế hoạch quản lý bên liên quan được dựng từ đâu: | Đầu vào | Nội dung | |---|---| | ⚠ Sổ đăng ký bên liên quan | ⚠ danh sách và thông tin cơ bản | | ⚠ Tài sản quy trình tổ chức | ⚠ mẫu biểu, bài học từ dự án trước | | ⚠ Yếu tố môi trường doanh nghiệp | ⚠ văn hoá, cơ cấu, khí hậu chính trị | | ⚠ Kế hoạch quản lý dự án | | | ⚠ Ghi nhận trong đề | ⚠ đề nói Lucas dựng kế hoạch dựa trên tài sản quy trình tổ chức và yếu tố môi trường doanh nghiệp — đúng hai đầu vào chuẩn, và đó cũng là gợi ý rằng câu hỏi này kiểm tra kiến thức về THÀNH PHẦN của tài liệu |

Từ khoá nhận diện:

"quan hệ giữa các thành viên trong ĐỘI" → ⚠ KHÔNG thuộc kế hoạch bên liên quan "quan hệ giữa các BÊN LIÊN QUAN" → ⚠ CÓ, và là phần giá trị nhất "lịch phân phối thông tin" → ⚠ CÓ "yêu cầu trao đổi thông tin" → ⚠ CÓ

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Bạn có ghi lại quan hệ giữa các bên liên quan không | | | Bạn biết ai có thể tác động tới ai không | | | Tài liệu đó có được bảo mật đúng mức không | |

Và điều mà phần "quan hệ giữa các bên liên quan" cho người quản lý dự án, ngoài một danh sách tên: hiểu biết rằng thuyết phục không phải là việc làm với từng người một, mà là việc làm với một mạng lưới đã có sẵn các liên kết của nó.