Mở đầu — vì sao bài này quan trọng
Nếu phải chọn ra một câu hỏi "gốc rễ" mà gần như mọi câu hỏi khác trong kỳ thi PSM I đều mọc ra từ đó, thì đó chính là: "Scrum dựa trên empirical process control hay predictive process control?" Hiểu sai chỗ này, bạn sẽ trả lời sai hàng loạt câu về Sprint Planning, về forecasting, về vì sao Scrum không "lock scope", về vì sao Daily Scrum tồn tại, về vì sao có Sprint Review. Tất cả đều quay về một niềm tin nền tảng: thế giới phát triển sản phẩm là phức tạp (complex), và trong môi trường phức tạp, bạn không thể lập kế hoạch hoàn hảo từ đầu rồi cứ thế thực thi.
Đây là điểm khiến rất nhiều học viên Việt Nam vấp phải, đặc biệt là những bạn đến từ nền tảng quản lý dự án truyền thống (PMP, kỹ sư xây dựng, sản xuất). Bạn đã quen với tư duy "lập kế hoạch chi tiết — duyệt — thực thi đúng kế hoạch — nghiệm thu". Đó là tư duy predictive, và nó hoàn toàn hợp lý trong nhiều bối cảnh. Nhưng Scrum được thiết kế cho một loại bài toán khác, và đề thi PSM I được viết ra để kiểm tra xem bạn đã thật sự chuyển đổi tư duy hay chưa.
Trong bài này, chúng ta sẽ mổ xẻ thật kỹ sự khác biệt cốt lõi giữa hai mô hình kiểm soát tiến trình này. Tôi sẽ không chỉ nói lý thuyết, mà sẽ cho bạn thấy bằng các tình huống cụ thể tại sao một dự án "đúng predictive" lại có thể thất bại, và ngược lại. Lưu ý: bài này tập trung vào sự khác biệt empirical vs predictive ở tầng tư duy. Còn 3 trụ cột Transparency–Inspection–Adaptation đã có bài riêng (Bài 6), nên ở đây tôi chỉ chạm vào chúng đủ để bạn thấy bức tranh, không đi sâu lặp lại.
Khái niệm cốt lõi
Predictive process control là gì
Predictive (còn gọi là "defined process control" hoặc dân gian hay gọi là Waterfall) là mô hình kiểm soát tiến trình dựa trên giả định: nếu tôi hiểu đủ rõ bài toán và quy trình, tôi có thể lập kế hoạch toàn bộ từ đầu và dự đoán chính xác kết quả.
Trong mô hình này:
- Giai đoạn plan diễn ra đầy đủ và kỹ lưỡng trước khi bắt đầu execute. Bạn phân tích yêu cầu, thiết kế, lập Gantt chart chi tiết, ước lượng thời gian từng đầu việc.
- Scope được khóa (locked) ngay từ đầu. Những gì cần làm đã được xác định rõ và ký duyệt.
- Tiến trình đi tuyến tính qua các pha: Requirements → Design → Build → Test → Deploy. Pha sau chỉ bắt đầu khi pha trước hoàn tất.
- Thước đo thành công là: "Chúng ta có làm đúng kế hoạch không? Đúng tiến độ, đúng ngân sách, đúng scope không?"
Empirical process control là gì
Empiricism (chủ nghĩa thực nghiệm) khẳng định: kiến thức đến từ kinh nghiệm thực tế và việc ra quyết định dựa trên những gì đã quan sát được. Thay vì cố dự đoán toàn bộ tương lai, bạn làm một lượng nhỏ công việc, quan sát kết quả thật, rồi điều chỉnh.
Scrum được xây dựng hoàn toàn trên nền tảng empirical. Cơ chế vận hành là vòng lặp ngắn:
- Làm một phần nhỏ có giá trị (trong một Sprint, tối đa 1 tháng).
- Quan sát kết quả thật — một Increment chạy được, phản hồi của stakeholder.
- Học từ những gì thấy được.
- Điều chỉnh kế hoạch cho phần tiếp theo dựa trên hiểu biết mới.
Vì sao Scrum chọn empirical: bài toán complex
Lý do nằm ở bản chất công việc phát triển sản phẩm. Hãy hình dung mô hình Cynefin: công việc có thể là Simple (rõ ràng), Complicated (cần chuyên gia phân tích), Complex (chỉ hiểu được sau khi thử), hoặc Chaotic (hỗn loạn).
Phần lớn công việc phát triển sản phẩm phần mềm rơi vào vùng Complex: yêu cầu thay đổi, công nghệ mới, thị trường biến động, và bạn thường không biết chính xác mình cần xây gì cho đến khi xây thử rồi cho người dùng chạm vào. Trong vùng complex, quan hệ nhân–quả chỉ lộ ra sau khi hành động. Vì vậy bạn không thể "phân tích để biết trước". Bạn phải probe → sense → respond (thử → cảm nhận → phản hồi). Đó chính xác là empiricism.
Scrum Guide nói rõ: "Scrum employs an iterative, incremental approach to optimize predictability and to control risk." Hãy chú ý cụm "optimize predictability" — Scrum không hứa hẹn dự đoán hoàn hảo (đó là predictive), mà tìm cách tối ưu hóa khả năng dự đoán trong một thế giới vốn dĩ khó dự đoán, bằng cách rút ngắn vòng lặp phản hồi.
Bảng so sánh nhanh để ghi nhớ
| Tiêu chí | Predictive | Empirical |
|---|---|---|
| Giả định nền | Hiểu trước được toàn bộ | Hiểu biết đến dần qua kinh nghiệm |
| Kế hoạch | Lập đầy đủ từ đầu, cố định | Lập dần, làm mới liên tục |
| Scope | Khóa sớm | Linh hoạt, có thể tinh chỉnh |
| Phản hồi | Cuối dự án (nghiệm thu) | Mỗi Sprint, mỗi ngày |
| Phù hợp với | Simple / Complicated | Complex |
| Câu hỏi đo lường | "Có làm đúng kế hoạch không?" | "Có tạo ra giá trị và học được gì không?" |
Tình huống thực tế
Ví dụ 1 — App giao đồ ăn của một startup ở TP.HCM đi theo predictive và trả giá
Một startup giao đồ ăn tại TP.HCM (tạm gọi là "FoodFast") gọi vốn vòng seed 8 tỷ đồng và quyết định xây app theo kiểu predictive cho "chắc ăn". Đội ngũ dành 4 tháng đầu để viết một bản đặc tả yêu cầu dày 120 trang, vẽ Gantt chart chi tiết đến từng tuần cho cả 14 tháng, và khóa scope: 47 tính năng, từ đặt món, ví điện tử, chương trình điểm thưởng, đến tính năng "ăn nhóm chia tiền".
Sau 14 tháng, họ ra mắt đúng kế hoạch — đúng tiến độ, gần đúng ngân sách. Nhưng khi đưa ra thị trường, họ phát hiện: người dùng Việt Nam ở phân khúc của họ chủ yếu chỉ dùng 3 tính năng (đặt món nhanh, theo dõi tài xế, thanh toán). Tính năng "ăn nhóm chia tiền" mà họ đổ vào 3 tháng công sức gần như không ai dùng. Tệ hơn, trong 14 tháng đó, hai đối thủ đã ra mắt tính năng đặt món bằng giọng nói tiếng Việt — thứ không hề có trong bản đặc tả 120 trang vì lúc lập kế hoạch chưa ai nghĩ tới.
Diễn giải: Đội FoodFast làm đúng theo predictive. Vấn đề không phải họ thực thi kém, mà là họ chọn nhầm mô hình kiểm soát cho một bài toán complex. Họ khóa scope ở thời điểm mà họ biết ít nhất về thị trường, rồi không có cơ chế nào để học và điều chỉnh trong suốt 14 tháng.
Bài học rút ra: Trong môi trường complex, chi phí lớn nhất không phải là làm sai kế hoạch, mà là làm đúng một kế hoạch sai. Empiricism giải quyết bằng cách buộc bạn đưa sản phẩm ra ánh sáng sớm và thường xuyên để học.
Ví dụ 2 — Cùng bài toán, một đội khác đi theo empirical
Hãy tưởng tượng một đối thủ của FoodFast, gọi là "MonNhanh", cùng số vốn nhưng chọn empirical. Thay vì 14 tháng, sau 3 tuần Sprint đầu tiên họ đã có một phiên bản chạy được chỉ với đúng 2 tính năng: đặt món và xem trạng thái đơn. Họ cho 200 người dùng thật ở một quận thử.
Phản hồi thật cho thấy người dùng cực kỳ khó chịu vì không biết tài xế đang ở đâu. Thế là Sprint tiếp theo, đội ưu tiên làm bản đồ theo dõi tài xế thời gian thực — thứ ban đầu nằm tận cuối backlog. Còn tính năng "điểm thưởng" họ định làm sớm thì hoãn lại vì dữ liệu cho thấy nó không ảnh hưởng đến quyết định đặt món ở giai đoạn này.
Sau 6 tháng, MonNhanh có một app gọn nhưng đúng thứ người dùng cần, và quan trọng hơn: họ đã thực hiện khoảng 8 vòng học–điều chỉnh, mỗi vòng làm sản phẩm tốt lên dựa trên dữ liệu thật chứ không phải phỏng đoán.
Diễn giải: MonNhanh không hề "không lập kế hoạch". Họ vẫn có Product Goal, vẫn có Product Backlog được sắp thứ tự. Khác biệt là họ lập kế hoạch just-in-time và để dữ liệu thực tế quyết định thứ tự ưu tiên.
Bài học rút ra: Empirical không có nghĩa là làm bừa hay không có hướng đi. Nó nghĩa là bạn cam kết với mục tiêu (Product Goal) nhưng linh hoạt với con đường đi tới đó.
Ví dụ 3 — Khi predictive lại là lựa chọn đúng
Đừng để tôi khiến bạn nghĩ predictive luôn xấu. Một công ty cơ điện ở Bình Dương ký hợp đồng lắp đặt hệ thống điện cho một nhà xưởng theo bản vẽ kỹ thuật đã được cơ quan có thẩm quyền phê duyệt. Tiêu chuẩn rõ ràng, vật tư xác định, quy trình thi công đã được kiểm chứng hàng nghìn lần. Họ lập kế hoạch chi tiết, khóa scope, thi công đúng tiến độ và nghiệm thu thành công.
Ở đây, áp Scrum sẽ là sai. Bạn không "thử nghiệm" cách đấu dây điện 3 pha rồi "điều chỉnh ở Sprint sau". Bài toán này nằm trong vùng complicated với nhân–quả đã rõ. Predictive là lựa chọn đúng.
Bài học rút ra: Câu hỏi không phải "empirical hay predictive cái nào tốt hơn", mà là "bài toán của tôi thuộc loại nào". Trong kỳ thi PSM I, bối cảnh luôn là phát triển sản phẩm phức tạp, nên câu trả lời "by the book" gần như luôn nghiêng về empirical — nhưng hiểu được vì sao mới giúp bạn không bị lừa bởi các câu hỏi đánh đố.
Hướng dẫn từng bước
Khi gặp một câu hỏi PSM I hoặc một tình huống thực tế, hãy dùng quy trình tư duy sau để xác định và áp dụng đúng mô hình:
- Xác định loại bài toán. Quan hệ nhân–quả đã rõ chưa? Yêu cầu có ổn định không? Nếu mọi thứ đã biết trước và ổn định → có thể predictive. Nếu nhiều ẩn số, yêu cầu dễ đổi, công nghệ mới → complex → empirical.
- Với bài toán complex, đừng cố hoàn thiện kế hoạch trước. Lập đủ kế hoạch để bắt đầu Sprint đầu tiên, không hơn. Phần xa hơn để ở mức thô trong Product Backlog.
- Đóng gói công việc thành các vòng lặp ngắn. Mỗi Sprint phải tạo ra một Increment dùng được để có thể inspect. Đây là điều kiện sống còn của empirical — không có sản phẩm thật để quan sát thì không có thực nghiệm.
- Tạo điểm phản hồi đều đặn. Daily Scrum để inspect tiến độ hướng tới Sprint Goal; Sprint Review để inspect Increment với stakeholder; Sprint Retrospective để inspect cách làm việc. (Chi tiết từng event ở các bài 13–16.)
- Điều chỉnh dựa trên dữ liệu thật, không phải ý kiến. Sau mỗi vòng, hỏi: "Chúng ta vừa học được gì khác với giả định ban đầu?" rồi cập nhật Product Backlog cho phù hợp.
- Bảo vệ Transparency. Empiricism chỉ đúng nếu thứ bạn quan sát phản ánh sự thật. Một Increment "gần xong", một báo cáo tô hồng, một Definition of Done lỏng lẻo — tất cả phá hỏng nền tảng thực nghiệm.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ empirical là "không lập kế hoạch". Đây là hiểu lầm phổ biến nhất. Scrum lập kế hoạch liên tục — chỉ là just-in-time thay vì up-front toàn bộ. Nếu một đáp án trong đề thi ám chỉ "Scrum không cần kế hoạch", gần như chắc chắn nó sai.
Lỗi 2 — "Sprint 0 để lập kế hoạch toàn bộ". Nhiều đội cố nhét một pha planning predictive vào đầu rồi gọi là Scrum. Đây là water-Scrum-fall. Trong Scrum không có Sprint 0; mọi Sprint đều phải tạo ra giá trị.
Lỗi 3 — Khóa scope của cả release rồi vẫn gọi là Scrum. Khóa scope cứng từ đầu là tư duy predictive. Empiricism yêu cầu để mở khả năng tinh chỉnh Product Backlog khi học được điều mới.
Lỗi 4 — Lẫn lộn "empirical" với "agile nói chung". Trong ngữ cảnh PSM I, empiricism là cơ chế kiểm soát tiến trình cụ thể (dựa trên quan sát thực tế qua Transparency–Inspection–Adaptation). Đừng trả lời chung chung kiểu "vì Agile linh hoạt".
Mẹo thi:
- Khi thấy cụm "detailed plan upfront", "fixed scope", "predict the entire project" → đó là tín hiệu của predictive, thường là đáp án sai trong bối cảnh Scrum.
- Khi thấy "inspect and adapt", "based on what is observed", "empirical" → thường đúng hướng.
- Nhớ câu gốc: Scrum dùng iterative + incremental để optimize predictability và control risk. "Control risk" là lý do cốt lõi cho vòng lặp ngắn.
- Phân biệt với Bài 31: empirical là lý do Scrum forecast thay vì commit cứng; ở đây bạn chỉ cần nắm tầng tư duy, đừng đi sâu vào capacity.
Bài tập thực hành
- Tự phân loại bài toán. Lấy một dự án bạn từng tham gia. Viết ra 5 yếu tố cho thấy nó complex (ẩn số, thay đổi yêu cầu, công nghệ mới...) và 5 yếu tố cho thấy nó complicated/simple. Dựa trên đó, predictive hay empirical phù hợp hơn? Vì sao?
- Tìm "kế hoạch sai làm đúng". Nhớ lại một lần đội bạn hoàn thành đúng kế hoạch nhưng kết quả lại không tạo giá trị như mong đợi. Nếu áp dụng empiricism, điểm phản hồi sớm nào đáng lẽ đã giúp phát hiện vấn đề trước?
- Câu hỏi tự luyện kiểu PSM I. Một stakeholder yêu cầu bạn cung cấp kế hoạch chi tiết cố định cho cả 12 tháng tới với scope khóa cứng. Là Scrum Master, bạn giải thích thế nào về việc Scrum tiếp cận theo empirical thay vì predictive? Viết câu trả lời 4–5 câu, tập trung vào "optimize predictability" và "control risk".
- Vẽ vòng lặp. Vẽ sơ đồ vòng lặp empirical (Làm → Quan sát → Học → Điều chỉnh) và đánh dấu trong Scrum mỗi bước tương ứng với event/artifact nào.
Tóm tắt
- Predictive giả định bạn hiểu trước được toàn bộ: lập kế hoạch đầy đủ, khóa scope, thực thi tuyến tính. Đúng cho bài toán simple/complicated (xây cầu, lắp điện, sản xuất). Không sai về bản chất — chỉ sai khi áp nhầm chỗ.
- Empirical giả định hiểu biết đến dần qua kinh nghiệm: làm phần nhỏ, quan sát kết quả thật, học, điều chỉnh. Đúng cho bài toán complex — chính là môi trường phát triển sản phẩm mà Scrum nhắm tới.
- Scrum hoàn toàn dựa trên empiricism, vận hành qua vòng lặp ngắn (Sprint ≤ 1 tháng) với các điểm inspect & adapt đều đặn, được nâng đỡ bởi Transparency–Inspection–Adaptation (Bài 6).
- Empirical không nghĩa là không lập kế hoạch; nghĩa là lập kế hoạch just-in-time, cam kết với mục tiêu nhưng linh hoạt với con đường.
- Trong môi trường complex, rủi ro lớn nhất là làm đúng một kế hoạch sai. Vòng lặp ngắn của empiricism tồn tại để optimize predictability và control risk.
- Mẹo thi: cảnh giác với đáp án mang hơi hướng "fixed plan upfront / locked scope / predict everything" trong bối cảnh Scrum — đó thường là bẫy predictive.