Bài 2

Các phương pháp luận quản lý dự án

Không có phương pháp nào "tốt nhất" một cách tuyệt đối. Mỗi phương pháp luận là một bộ giả định về thế giới — về việc yêu cầu có rõ ràng hay không, môi trường có ổn định hay biến động. Việc chọn đúng phụ thuộc vào mức độ rõ ràng của yêu cầu và mức độ biến động của dự án.

1. Waterfall (thác nước)

Tuần tự, dự đoán trước (predictive)

Waterfall chia dự án thành các pha tuần tự, mỗi pha hoàn tất hẳn rồi mới chuyển sang pha kế tiếp — giống dòng nước chỉ chảy xuôi một chiều, không quay lại. Luồng điển hình:

Requirements  # thu thập & chốt yêu cầu
    ↓
Design        # thiết kế kiến trúc & giải pháp
    ↓
Build         # lập trình / thi công
    ↓
Test          # kiểm thử & nghiệm thu
    ↓
Deploy        # triển khai & bàn giao

Toàn bộ phạm vi được định nghĩa từ đầu; kế hoạch, ngân sách và lịch trình được lập chi tiết trước khi bắt tay vào làm.

Ưu điểm	Nhược điểm
Rõ ràng, dễ hiểu, dễ quản lý theo cột mốc	Cứng nhắc, khó thay đổi khi pha trước đã đóng
Phù hợp dự án có yêu cầu cố định ngay từ đầu	Phát hiện vấn đề muộn — chỉ lộ ra ở pha test cuối
Sinh nhiều tài liệu, thuận lợi cho bàn giao & tuân thủ	Khách hàng chỉ thấy sản phẩm ở giai đoạn cuối
Dễ ước lượng chi phí & thời gian khi phạm vi ổn định	Chi phí sửa lỗi tăng vọt nếu yêu cầu thay đổi giữa chừng

Khi nào dùng: dự án xây dựng/hạ tầng, yêu cầu đã rõ ràng và ổn định, hoặc có ràng buộc pháp lý/hợp đồng đòi hỏi tài liệu và cột mốc chặt chẽ.

2. Agile (linh hoạt)

Lặp & tăng dần (iterative & incremental)

Agile không phải một quy trình cụ thể mà là một triết lý. Thay vì làm một mạch từ đầu đến cuối, Agile chia công việc thành các vòng lặp ngắn (iteration): mỗi vòng cho ra một phần sản phẩm dùng được, nhận phản hồi, rồi điều chỉnh cho vòng sau. Mục tiêu là giao giá trị sớm, phản hồi liên tục và đón nhận thay đổi thay vì chống lại nó.

Triết lý này được cô đọng trong Agile Manifesto (2001) gồm 4 giá trị cốt lõi và 12 nguyên tắc. Bốn giá trị:

Cá nhân & tương tác hơn là quy trình & công cụ.
Phần mềm chạy được hơn là tài liệu đầy đủ.
Hợp tác với khách hàng hơn là đàm phán hợp đồng.
Phản ứng với thay đổi hơn là bám theo kế hoạch.

Lưu ý cách diễn đạt "A hơn là B": vế bên phải vẫn có giá trị, nhưng vế bên trái được đề cao hơn. 12 nguyên tắc đi kèm cụ thể hóa các giá trị này — giao sản phẩm thường xuyên, hoan nghênh yêu cầu thay đổi kể cả muộn, đội ngũ tự tổ chức, duy trì nhịp độ bền vững, và thường xuyên nhìn lại để cải tiến.

Ưu điểm	Nhược điểm
Thích ứng nhanh với thay đổi của thị trường/yêu cầu	Khó ước lượng tổng chi phí & thời gian từ đầu
Giao giá trị sớm và đều đặn, giảm rủi ro	Phụ thuộc nhiều vào sự tham gia của khách hàng
Phản hồi liên tục giúp đúng nhu cầu thực	Ít tài liệu — khó cho dự án cần tuân thủ chặt
Đội ngũ chủ động, gắn kết, tinh thần cao	Dễ "trượt phạm vi" nếu thiếu kỷ luật quản trị

Hợp nhất với: dự án phần mềm và các dự án có mức biến động cao, nơi yêu cầu sẽ còn thay đổi và việc học từ phản hồi quan trọng hơn việc bám kế hoạch ban đầu.

3. Waterfall vs Agile

So sánh trực diện

Tiêu chí	Waterfall	Agile
Yêu cầu	Cố định, chốt từ đầu	Tiến hóa dần qua các vòng lặp
Thay đổi	Tốn kém, hạn chế	Được hoan nghênh, kể cả muộn
Giao hàng	Một lần ở cuối dự án	Liên tục, từng phần nhỏ
Tài liệu	Nhiều, chi tiết, trả trước	Vừa đủ, ưu tiên sản phẩm chạy
Khách hàng tham gia	Chủ yếu đầu & cuối	Xuyên suốt, thường xuyên
Rủi ro	Dồn về cuối, lộ ra muộn	Phát hiện & xử lý sớm mỗi vòng
Phù hợp	Yêu cầu rõ & ổn định	Yêu cầu mơ hồ & biến động

4. Các khung Agile phổ biến

Agile là triết lý — đây là các cách hiện thực hóa

Agile chỉ nêu nguyên tắc; để áp dụng thực tế người ta dùng các khung (framework) cụ thể:

Khung	Ý tưởng cốt lõi
Scrum	Làm theo các chu kỳ cố định gọi là sprint (1–4 tuần), với các vai trò Product Owner / Scrum Master / Dev Team và các sự kiện chuẩn. Đây là khung phổ biến nhất — sẽ đi sâu ở Bài 3.
Kanban	Luồng làm việc liên tục (không chia sprint), trực quan hóa công việc trên bảng và đặt WIP limit (giới hạn số việc đang làm) để tránh quá tải và phát hiện điểm nghẽn.
Lean	Bắt nguồn từ sản xuất Toyota — tập trung loại bỏ lãng phí (việc thừa, chờ đợi, làm lại), tối ưu dòng giá trị và chỉ làm những gì khách hàng thực sự cần.
XP (Extreme Programming)	Nhấn mạnh các kỹ thuật lập trình để giữ chất lượng cao: TDD (test-driven development), pair programming (lập trình đôi), tích hợp liên tục (CI), refactoring thường xuyên.

5. Hybrid (kết hợp)

Cấu trúc ở trên, linh hoạt ở dưới

Trong thực tế, rất nhiều tổ chức không chọn "thuần" mà dùng hybrid: giữ Waterfall ở mức tổng thể để quản trị — các cổng pha (phase gate), ngân sách, cột mốc lớn và phê duyệt — đồng thời dùng Agile ở mức thực thi — chia công việc trong mỗi pha thành các sprint để đội ngũ linh hoạt và giao giá trị sớm.

Cách này dung hòa nhu cầu của lãnh đạo/khách hàng (cần dự đoán được ngân sách, lịch trình) với nhu cầu của đội thực thi (cần linh hoạt). Đây là lựa chọn rất phổ biến ở các tổ chức lớn hoặc dự án có cả phần ổn định lẫn phần biến động.

6. Khung quản trị: PMBOK & PRINCE2

Không phải "đối thủ" của Agile — chúng ở tầng quản trị

PMBOK (Project Management Body of Knowledge) do PMI (Project Management Institute) xuất bản, không phải một phương pháp ra lệnh "phải làm thế nào" mà là một kho kiến thức chuẩn hóa: tập hợp các quy trình (process groups: khởi tạo, lập kế hoạch, thực hiện, giám sát & kiểm soát, kết thúc) và các lĩnh vực kiến thức (knowledge areas: phạm vi, thời gian, chi phí, chất lượng, rủi ro, nhân lực...). PMBOK là nền tảng cho chứng chỉ PMP.

PRINCE2 (PRojects IN Controlled Environments) là một phương pháp có cấu trúc, tổ chức quanh các nguyên tắc (principles), chủ đề (themes) và quy trình (processes); nhấn mạnh tính chính danh kinh doanh (business case) và phân vai trò rõ ràng. PRINCE2 đặc biệt phổ biến ở châu Âu và khu vực công.

Tiêu chí	PMBOK / PMI	PRINCE2
Bản chất	Body of knowledge (kho kiến thức, "cái gì")	Phương pháp có cấu trúc ("làm thế nào")
Cấu trúc	Process groups & knowledge areas	Principles, themes & processes
Trọng tâm	Kỹ năng & công cụ của người quản lý dự án	Quản trị, vai trò & kiểm soát dự án
Phổ biến	Mỹ & toàn cầu (chứng chỉ PMP)	Anh, châu Âu, khu vực công

Lưu ý: PMBOK/PRINCE2 không loại trừ Agile. Cả PMI lẫn PRINCE2 đều có biến thể tích hợp Agile (PMI-ACP, PRINCE2 Agile) — chúng là khung quản trị bao trùm, còn Agile/Waterfall là cách thực thi bên trong.

7. Chọn phương pháp nào?

Quyết định theo bối cảnh, không theo trào lưu

Không có câu trả lời chung. Hãy cân nhắc các tiêu chí sau cho từng dự án:

Độ rõ của yêu cầu — yêu cầu đã rõ và chốt được chưa, hay còn mơ hồ và sẽ khám phá dần?
Mức biến động — thị trường/công nghệ/nhu cầu có thay đổi nhanh không? Càng biến động càng nghiêng về Agile.
Quy mô & mức phân tán của nhóm — nhóm nhỏ ngồi cùng chỗ hợp Agile; nhóm rất lớn, phân tán nhiều múi giờ cần thêm cấu trúc.
Ràng buộc pháp lý / hợp đồng — có yêu cầu tài liệu, kiểm toán, phê duyệt cứng không? Nếu có, nghiêng về Waterfall/hybrid.
Văn hóa tổ chức — đội ngũ và lãnh đạo đã quen cách làm nào, có sẵn sàng cho việc tự tổ chức và phản hồi liên tục không?

Quy tắc nhanh: dự án data/phần mềm, biến động cao → nghiêng về Agile/Scrum; dự án hạ tầng hoặc cần tuân thủ chặt → nghiêng về Waterfall hoặc hybrid. Quan trọng nhất: chọn vì bối cảnh dự án, không vì phương pháp đang "thời thượng".