Mở đầu — vì sao bài này quan trọng
Nếu bạn từng tự hỏi "Tại sao Scrum lại bắt buộc phải có Sprint? Tại sao phải họp Daily Scrum mỗi ngày? Tại sao phải demo cuối Sprint thay vì cứ làm xong hết rồi giao một lần?" — thì câu trả lời cho tất cả những câu hỏi đó nằm gọn trong một khái niệm nền tảng: Empirical Process Control (Kiểm soát quy trình dựa trên thực nghiệm).
Đây là bài học mà tôi luôn nhấn mạnh với học viên rằng: nếu bạn chỉ học thuộc các nghi thức (ceremonies) của Scrum mà không hiểu Empirical Process Control, thì bạn đang làm Agile một cách hình thức — "cargo cult Agile". Bạn họp Daily đầy đủ, bạn có bảng Kanban đẹp, nhưng dự án vẫn trễ, vẫn vượt ngân sách, vẫn giao sai sản phẩm. Lý do là bạn chưa hiểu cơ chế vận hành bên dưới khiến Agile hoạt động.
Empirical Process Control chính là "động cơ triết học" của toàn bộ Scrum và phần lớn các framework Agile khác. Hiểu được nó, bạn sẽ ngừng đặt những câu hỏi sai (như "làm sao để lập kế hoạch chính xác 100% cho 6 tháng tới?") và bắt đầu đặt những câu hỏi đúng ("làm sao để học nhanh nhất, điều chỉnh sớm nhất, giảm rủi ro hiệu quả nhất?"). Đó là sự khác biệt giữa một Project Manager biết áp dụng quy trình và một người thực sự làm chủ quy trình.
Khái niệm cốt lõi
Defined Process Control — mô hình dây chuyền
Để hiểu Empirical, ta phải đặt nó cạnh đối thủ của nó: Defined Process Control (Kiểm soát quy trình đã định nghĩa trước).
Hãy hình dung một dây chuyền lắp ráp xe Toyota tại nhà máy. Để lắp một chiếc Vios, kỹ sư đã biết chính xác từng bước: siết ốc nào, mô-men xoắn bao nhiêu Newton-mét, lắp linh kiện theo thứ tự nào, mất bao nhiêu giây. Quy trình này được định nghĩa trước đến từng chi tiết. Cùng một input (linh kiện) đi qua cùng một quy trình sẽ cho ra cùng một output (chiếc xe giống hệt nhau) mỗi lần. Bạn có thể chạy nó hàng triệu lần với độ lặp lại gần như tuyệt đối.
Đặc điểm của Defined Process Control:
- Quy trình có thể lặp lại và dự đoán trước được hoàn toàn.
- Mọi biến số đều được hiểu rõ trước khi bắt đầu.
- Nếu output sai, ta sửa quy trình một lần là xong cho mọi lần sau.
Empirical Process Control — mô hình quan sát và điều chỉnh
Vấn đề là: phát triển phần mềm (và phần lớn công việc tri thức hiện đại) không giống dây chuyền lắp ráp xe. Nó giống việc... viết một cuốn tiểu thuyết, hay nghiên cứu khoa học hơn. Bạn không thể định nghĩa trước chính xác từng dòng code, vì:
- Yêu cầu khách hàng thay đổi liên tục, đôi khi chính khách hàng cũng chưa biết mình muốn gì.
- Công nghệ thay đổi nhanh.
- Mỗi sản phẩm là duy nhất, không lặp lại.
- Bản thân quá trình làm sản phẩm tạo ra hiểu biết mới làm thay đổi kế hoạch.
Empirical Process Control đưa ra một cách tiếp cận hoàn toàn khác. Empirical (thực nghiệm) nghĩa là dựa trên quan sát và thực nghiệm thay vì lý thuyết tính toán trước. Triết lý của nó là: "Tôi không thể dự đoán hết tương lai, nên thay vì lập kế hoạch hoàn hảo, tôi sẽ làm một phần nhỏ, quan sát kết quả thực tế, rồi điều chỉnh dựa trên những gì tôi vừa học được — và lặp lại vòng đó liên tục."
Đây không phải khái niệm mới mẻ do giới phần mềm sáng tạo ra. Nó xuất phát từ lý thuyết kiểm soát quy trình công nghiệp (industrial process control). Khi Ken Schwaber — đồng sáng lập Scrum — gặp giáo sư Babatunde Ogunnaike (một chuyên gia về process control) vào những năm 1990, ông được giải thích rằng việc cố gắng áp dụng defined process cho một quy trình phức tạp, chưa được hiểu rõ, là nguyên nhân khiến vô số dự án phần mềm thất bại. Đó là một trong những nền móng lý thuyết của Scrum.
Ba trụ cột: Transparency — Inspection — Adaptation
Empirical Process Control đứng vững trên ba trụ cột (three pillars). Hãy ghi nhớ kỹ vì đây là "xương sống" của toàn bộ Scrum:
1. Transparency (Minh bạch) — Mọi khía cạnh quan trọng của quy trình phải hiển thị rõ ràng với những người chịu trách nhiệm về kết quả. Nếu thông tin bị che giấu, bị bóp méo, thì việc quan sát sẽ dựa trên dữ liệu sai, dẫn đến quyết định sai. Minh bạch nghĩa là có một ngôn ngữ chung, một định nghĩa "hoàn thành" (Definition of Done) chung, một bảng công việc ai cũng nhìn thấy. Không có minh bạch, hai trụ cột còn lại trở nên vô nghĩa.
2. Inspection (Kiểm tra) — Người làm Scrum phải thường xuyên kiểm tra các "artifact" (sản phẩm trung gian) và tiến độ hướng tới mục tiêu, để phát hiện những sai lệch không mong muốn. Kiểm tra không nên quá thường xuyên đến mức cản trở công việc, cũng không quá thưa đến mức để vấn đề trôi đi quá xa. Đây là lý do tại sao có Daily Scrum (kiểm tra hằng ngày), Sprint Review (kiểm tra sản phẩm cuối Sprint), Sprint Retrospective (kiểm tra cách làm việc).
3. Adaptation (Thích nghi) — Nếu việc kiểm tra phát hiện một hoặc nhiều khía cạnh đã lệch ra ngoài giới hạn chấp nhận được, và sản phẩm sẽ không đạt yêu cầu, thì quy trình hoặc vật liệu đang được xử lý phải được điều chỉnh càng sớm càng tốt để giảm thiểu sai lệch tiếp theo. Quan sát mà không hành động thì vô ích — đó chỉ là báo cáo.
Ba trụ cột này tạo thành một vòng lặp phản hồi (feedback loop): Minh bạch để nhìn thấy → Kiểm tra để phát hiện → Thích nghi để điều chỉnh → và vòng lặp lặp lại. Toàn bộ cấu trúc Sprint của Scrum tồn tại chỉ để tạo ra những vòng lặp phản hồi ngắn, đều đặn này.
Tình huống thực tế
Ví dụ 1: Ngân hàng số tại TP.HCM — bài học từ Waterfall thất bại
Một ngân hàng tại Việt Nam (tạm gọi là VietBank) năm 2021 quyết định xây dựng ứng dụng mobile banking thế hệ mới. Đội ngũ lập một bản kế hoạch Waterfall chi tiết: 4 tháng phân tích yêu cầu, 3 tháng thiết kế, 6 tháng phát triển, 2 tháng kiểm thử — tổng 15 tháng, với tài liệu đặc tả dày 400 trang được "đóng băng" (frozen requirements) ngay từ đầu.
Đến tháng thứ 12, khi bản demo đầu tiên ra mắt nội bộ, ban lãnh đạo và bộ phận nghiệp vụ mới được nhìn thấy sản phẩm thật. Kết quả: luồng chuyển tiền quá rườm rà so với đối thủ (lúc này đối thủ đã ra mắt tính năng chuyển tiền bằng QR cực nhanh — điều không hề có trong đặc tả 12 tháng trước), giao diện không còn hợp xu hướng, và quy định của Ngân hàng Nhà nước về eKYC đã thay đổi. Họ phải làm lại gần 40% khối lượng. Dự án đội lên 22 tháng.
Diễn giải: Đây là thất bại kinh điển của việc áp dụng Defined Process Control vào môi trường bất định cao. Họ giả định "biết hết mọi thứ từ đầu", nhưng thị trường, công nghệ và quy định đều thay đổi. Vòng phản hồi đầu tiên (lần được nhìn thấy sản phẩm thật) đến quá muộn — sau 12 tháng.
Bài học rút ra: Trong môi trường phức tạp, càng để feedback loop dài, rủi ro càng tích lũy theo cấp số nhân. Empirical Process Control yêu cầu rút ngắn khoảng cách giữa "ra quyết định" và "thấy hậu quả".
Ví dụ 2: Cũng VietBank đó, nhưng làm lại theo Empirical
Sau bài học trên, năm 2023 VietBank tái cấu trúc cách làm. Họ chia sản phẩm thành các Sprint 2 tuần. Cuối mỗi Sprint, đội demo phiên bản chạy được cho đại diện nghiệp vụ và một nhóm 20 khách hàng beta thật.
Ở Sprint thứ 3, qua buổi Review (Inspection), họ phát hiện khách hàng beta liên tục bỏ dở ở bước xác thực OTP vì mất quá nhiều thời gian. Thông tin này minh bạch (Transparency) qua số liệu: tỷ lệ bỏ dở 35%. Ngay Sprint sau, đội điều chỉnh (Adaptation) sang xác thực sinh trắc học. Sprint 5 đo lại: tỷ lệ bỏ dở còn 8%.
Diễn giải: Cùng một đội, cùng một sản phẩm, nhưng cơ chế feedback loop ngắn cho phép họ phát hiện vấn đề sau 6 tuần thay vì 12 tháng, và sửa với chi phí cực nhỏ.
Bài học rút ra: Sức mạnh của Empirical không nằm ở chỗ "làm nhanh hơn", mà ở chỗ "học và điều chỉnh sớm hơn", từ đó tránh được sai lầm đắt đỏ. Ba trụ cột không phải lý thuyết suông — chúng vận hành cụ thể: số liệu minh bạch → buổi review để kiểm tra → quyết định điều chỉnh ngay.
Ví dụ 3: Startup giao đồ ăn tại Đông Nam Á — Empirical ở quy mô sản phẩm
Một startup giao đồ ăn (giả định, tương tự mô hình các kỳ lân khu vực) muốn ra tính năng "đặt nhóm" (group order). Thay vì xây dựng đầy đủ trong 3 tháng rồi tung ra toàn quốc, họ áp dụng tư duy thực nghiệm: tuần 1 làm một phiên bản tối giản chỉ chạy ở một quận của Jakarta, quan sát 500 đơn đầu tiên.
Họ phát hiện người dùng không gặp khó ở khâu mời bạn bè (như họ lo ban đầu), mà gặp khó ở khâu chia tiền. Dữ liệu này — hoàn toàn không thể đoán trước bằng lý thuyết — chỉ lộ ra khi quan sát hành vi thật. Họ điều chỉnh, ưu tiên tính năng chia bill, rồi mới mở rộng.
Diễn giải: Đây là Empirical Process Control áp dụng ở cấp độ khám phá sản phẩm, không chỉ ở cấp độ quản lý dự án. Giả thuyết ban đầu của đội (khó ở khâu mời bạn) đã sai, và chỉ thực nghiệm mới phơi bày sự thật.
Bài học rút ra: Empirical chống lại "ảo tưởng của chuyên gia" — niềm tin rằng ta có thể ngồi trong phòng họp và suy luận ra mọi thứ. Trong môi trường phức tạp, thực tế luôn thông minh hơn dự đoán của ta.
Hướng dẫn từng bước
Làm thế nào để vận hành Empirical Process Control một cách thực tế trong dự án của bạn? Đây là khung 5 bước tôi thường hướng dẫn:
Bước 1 — Phân loại công việc của bạn (Cynefin nhanh). Trước hết hãy hỏi: công việc này thuộc loại "đơn giản/lặp lại" (suitable cho Defined) hay "phức tạp/bất định" (cần Empirical)? Đừng áp Empirical lên mọi thứ một cách máy móc. Xử lý lương hằng tháng là defined; xây sản phẩm mới là empirical.
Bước 2 — Chia nhỏ thành các vòng lặp ngắn. Xác định độ dài chu kỳ phản hồi. Trong Scrum đó là Sprint 1-4 tuần. Nguyên tắc: vòng lặp đủ ngắn để nếu đi sai hướng, bạn chỉ mất tối đa một chu kỳ công sức.
Bước 3 — Thiết lập Transparency. Đảm bảo có một nguồn sự thật chung: bảng công việc ai cũng thấy, Definition of Done rõ ràng, số liệu đo lường công khai. Hỏi: "Mọi người trong đội có đang nhìn cùng một thực tế không?"
Bước 4 — Lên lịch Inspection đều đặn. Đặt các điểm kiểm tra cố định: kiểm tra tiến độ hằng ngày, kiểm tra sản phẩm cuối chu kỳ, kiểm tra cách làm việc cuối chu kỳ. Quan trọng: kiểm tra dựa trên bằng chứng thật (phần mềm chạy được, số liệu thật), không phải báo cáo "90% xong".
Bước 5 — Hành động bằng Adaptation. Mỗi lần kiểm tra phải kết thúc bằng một quyết định điều chỉnh cụ thể: thay đổi backlog, đổi cách làm, đổi ưu tiên. Nếu một buổi inspection không dẫn đến bất kỳ thay đổi nào, hãy nghi ngờ chất lượng của nó.
Sau bước 5, quay lại bước 2 và lặp. Đó chính là động cơ thực nghiệm đang chạy.
Lỗi thường gặp & mẹo
Lỗi 1 — Inspection mà không Adaptation. Đội họp Retrospective, ghi ra một danh sách vấn đề, rồi... không làm gì. Sprint sau lặp lại đúng vấn đề cũ. Đây là lỗi phổ biến nhất. Mẹo: mỗi buổi kiểm tra phải tạo ra tối đa 1-2 hành động cải tiến cụ thể, có người chịu trách nhiệm, đưa vào Sprint tiếp theo.
Lỗi 2 — Giả minh bạch (fake transparency). Bảng Kanban thì đẹp nhưng "Done" của mỗi người hiểu một kiểu; trạng thái báo cáo lạc quan hơn thực tế ("sắp xong rồi"). Khi đó inspection dựa trên dữ liệu giả. Mẹo: thống nhất một Definition of Done chung và chỉ tính "Done" khi sản phẩm thật sự chạy được, kiểm tra được.
Lỗi 3 — Áp Empirical vào việc lẽ ra nên Defined. Không phải mọi thứ đều cần thực nghiệm. Những công việc lặp lại, đã hiểu rõ (triển khai hạ tầng theo checklist, vận hành định kỳ) nên được chuẩn hóa. Mẹo: dùng Empirical cho phần "chưa biết", dùng Defined cho phần "đã biết rõ".
Lỗi 4 — Vòng lặp quá dài. Gọi là Sprint nhưng thực chất 8-10 tuần mới có sản phẩm để xem. Khi đó bạn chỉ mặc áo Scrum lên một dự án Waterfall. Mẹo: giữ chu kỳ ngắn; nếu chưa thể giao gì sau 2 tuần, hãy chia nhỏ công việc hơn nữa.
Lỗi 5 — Coi feedback là lời chỉ trích. Văn hóa sợ sai khiến đội che giấu vấn đề, phá hỏng Transparency. Mẹo: xây dựng môi trường an toàn tâm lý, coi mỗi sai lệch phát hiện sớm là một chiến thắng, không phải thất bại.
Bài tập thực hành
- Phân loại quy trình: Liệt kê 5 công việc trong dự án hiện tại của bạn. Với mỗi việc, đánh dấu nó nên dùng Defined hay Empirical và giải thích ngắn gọn lý do. Mục tiêu: rèn phản xạ nhận diện môi trường phức tạp.
- Soi chiếu ba trụ cột: Chọn một cuộc họp/nghi thức Agile gần nhất bạn tham gia (Daily, Review, hoặc Retro). Trả lời: Nó phục vụ trụ cột nào trong ba trụ cột (Transparency / Inspection / Adaptation)? Nó có thực sự dẫn đến một Adaptation cụ thể không, hay chỉ là báo cáo?
- Đo độ dài feedback loop: Trong dự án của bạn, từ lúc đội đưa ra một quyết định đến lúc nhìn thấy kết quả thật của quyết định đó mất bao lâu? Hãy đề xuất một cách rút ngắn khoảng thời gian này xuống một nửa.
- Tình huống phản biện: Sếp của bạn nói "Cứ lập kế hoạch chi tiết 6 tháng đi, làm theo đúng kế hoạch là xong, cần gì Sprint với demo cho mất thời gian." Hãy viết một đoạn 5-7 câu giải thích cho sếp, dùng khái niệm Empirical Process Control, vì sao điều đó rủi ro trong một dự án sản phẩm mới.
Tóm tắt
- Defined Process Control phù hợp với công việc lặp lại, đã hiểu rõ, độ bất định thấp (như dây chuyền lắp ráp xe). Empirical Process Control phù hợp với công việc phức tạp, bất định cao như phát triển phần mềm và sản phẩm mới.
- Empirical nghĩa là dựa trên quan sát và thực nghiệm, không phải tính toán trước mọi thứ. Thay vì lập kế hoạch hoàn hảo, ta làm từng phần nhỏ, quan sát kết quả thật, rồi điều chỉnh.
- Empirical Process Control đứng trên ba trụ cột: Transparency (minh bạch để nhìn thấy thực tế), Inspection (kiểm tra để phát hiện sai lệch), Adaptation (thích nghi để điều chỉnh sớm).
- Toàn bộ cấu trúc nghi thức của Scrum (Sprint, Daily, Review, Retro) tồn tại để tạo ra những vòng lặp phản hồi ngắn, đều đặn — đó chính là cơ chế vận hành của Empirical Process Control.
- Sức mạnh thật sự không nằm ở "làm nhanh hơn" mà ở "học và điều chỉnh sớm hơn", nhờ đó giảm rủi ro và tránh sai lầm đắt đỏ.
- Hiểu được bài này, bạn sẽ ngừng làm Agile theo hình thức và bắt đầu làm chủ tư duy nền tảng đằng sau nó.