Phương pháp luận cấu trúc và phương pháp luận Agile (Scrum, Kanban)
1. Tổng quan
A. Định nghĩa
Phương pháp luận cấu trúc (Structured Methodology) là phương pháp luận phát triển truyền thống phân chia và định nghĩa hệ thống từ trên xuống theo chức năng, tiến hành tuần tự phân tích → thiết kế → hiện thực → kiểm thử; còn phương pháp luận Agile là phương pháp luận gọn nhẹ (Lightweight) bàn giao phần mềm hoạt động được một cách tăng dần qua các vòng lặp (Iteration) ngắn và ứng phó linh hoạt với thay đổi yêu cầu.
Khác biệt căn bản giữa hai phương pháp luận nằm ở thái độ triết lý phát triển: “tuân theo kế hoạch hay ứng phó với thay đổi”. Phương pháp luận cấu trúc cố gắng bảo đảm khả năng dự đoán (Predictability) bằng cách xác định yêu cầu ở giai đoạn đầu và kiểm soát sản phẩm bằng tài liệu chi tiết. Nó dùng các công cụ như sơ đồ luồng dữ liệu (DFD), từ điển dữ liệu (DD), đặc tả tiểu đơn vị (Mini-spec), sơ đồ cấu trúc (Structure Chart) để phân chia chức năng hệ thống từ trên xuống (Top-down), và lấy vòng đời thác nước (Waterfall) — mỗi giai đoạn phải hoàn tất mới sang giai đoạn tiếp theo — làm nền tảng. Phương thức này có các cổng rà soát, phê duyệt (Gate) rõ ràng ở mỗi giai đoạn nên dễ kiểm toán và truy vết, và vẫn có thế mạnh trong các ngành bị quản lý như khu vực công, tài chính, quốc phòng — nơi yêu cầu ổn định và trách nhiệm về sản phẩm phải được quy định bằng hợp đồng.
Ngược lại, Agile dựa trên tiền đề “yêu cầu thay đổi suốt dự án”, bàn giao kết quả thực sự hoạt động (Working Software) ở mỗi vòng lặp 2~4 tuần, và điều chỉnh hướng tiếp theo bằng phản hồi của khách hàng. Agile Manifesto (Tuyên ngôn Agile) công bố năm 2001 đưa ra 4 giá trị cốt lõi và 12 nguyên tắc, coi trọng hơn ① cá nhân và sự tương tác hơn quy trình và công cụ ② phần mềm hoạt động hơn tài liệu đồ sộ ③ cộng tác với khách hàng hơn đàm phán hợp đồng ④ ứng phó với thay đổi hơn tuân theo kế hoạch. Tức là Agile không phải một thủ tục cụ thể mà là tập hợp các giá trị và nguyên tắc, và các framework tiêu biểu thực hành nó là Scrum (cộng tác nhóm, timebox), Kanban (tối ưu hóa luồng) và XP (thực hành kỹ thuật).
Tiêu chí lựa chọn là: nếu yêu cầu rõ ràng, ổn định và cần quy mô lớn, độ tin cậy cao thì phương pháp luận cấu trúc có lợi; nếu yêu cầu không chắc chắn và tốc độ ứng phó thị trường quan trọng thì Agile có lợi. Trên thực tế, hình thức lai (hybrid) — kiểm soát kế hoạch cấp cao và kiến trúc theo cấu trúc, còn thực thi phát triển thì lặp theo Agile — đang tăng lên trong các dự án SI của tập đoàn lớn và khu vực công.
B. Bối cảnh áp dụng và sự cần thiết
Phương pháp luận truyền thống bộc lộ ba giới hạn trong môi trường phần mềm hiện đại nơi yêu cầu thường xuyên thay đổi. Thứ nhất, giả định xác định toàn bộ yêu cầu ở giai đoạn đầu là phi thực tế, nên khi thị trường, kinh doanh thay đổi, thiết kế đã xác định nhanh chóng trở nên lỗi thời. Thứ hai, khiếm khuyết được phát hiện cùng lúc ở giai đoạn kiểm thử cuối nên chi phí sửa chữa tăng theo cấp số nhân (nếu ở giai đoạn yêu cầu là 1 thì ở giai đoạn vận hành ở mức 100). Thứ ba, dù có nhiều sản phẩm trung gian, “thứ hoạt động được” chỉ xuất hiện ở cuối dự án nên khách hàng xác nhận giá trị muộn.
Như một phản ứng trước những giới hạn này, Agile áp dụng cách tiếp cận chia nhỏ, bàn giao nhanh và điều chỉnh hướng bằng phản hồi. Khi sự lan rộng của đám mây, DevOps, CI/CD khiến việc build và triển khai chu kỳ ngắn trở nên khả thi về mặt kỹ thuật, kết hợp với yêu cầu kinh doanh “ra mắt nhanh (Time-to-Market) và ứng phó với thay đổi”, Agile đã trở thành dòng chính trên thực tế của phát triển phần mềm.
2. So sánh khái niệm giữa phương pháp luận cấu trúc và Agile
flowchart LR
subgraph S["Phương pháp luận cấu trúc (tuần tự·hoàn tất từng giai đoạn)"]
S1["Phân tích (xác định yêu cầu)"] --> S2["Thiết kế (DFD·sơ đồ cấu trúc)"] --> S3["Hiện thực"] --> S4["Kiểm thử·Bàn giao"]
end
subgraph A["Agile (lặp·bàn giao tăng dần)"]
A1["Lập kế hoạch (backlog)"] --> A2["Phát triển"] --> A3["Review·Phản hồi"] --> A4["Hồi cứu"] --> A1
end
style A fill:#e8f0fe,stroke:#2f6fed
style S fill:#f8f9fb,stroke:#64748b
Như thấy trong sơ đồ cấu trúc trên, phương pháp luận cấu trúc có các giai đoạn chảy theo một hướng và hoàn tất, trong khi Agile có lập kế hoạch-phát triển-review-hồi cứu tạo thành một vòng tuần hoàn khép kín (Loop). Khác biệt cấu trúc này tạo ra sự khác biệt về cách ứng phó thay đổi yêu cầu, hình thức sản phẩm và phương thức quản lý rủi ro.
Khác biệt lớn nhất là thái độ đối với thay đổi yêu cầu. Phương pháp luận cấu trúc coi thay đổi là “đối tượng cần kiểm soát, tối thiểu hóa”, kìm hãm chặt chẽ bằng Ban kiểm soát thay đổi (CCB) và quản lý cấu hình. Lý do là thay đổi làm lung lay toàn bộ sản phẩm của các giai đoạn trước. Agile coi thay đổi là “nguồn lợi thế cạnh tranh”, điều chỉnh lại thứ tự ưu tiên backlog tại mỗi ranh giới vòng lặp. Tuy nhiên, điều này không có nghĩa là cho phép thay đổi tùy tiện “trong khi” sprint đang diễn ra, mà có nghĩa là đã định kỳ hóa điểm tiếp nhận thay đổi tại ranh giới vòng lặp.
Khác biệt thứ hai là thời điểm rủi ro lộ diện. Trong phương pháp luận cấu trúc, các rủi ro lớn như vấn đề tích hợp, tải dồn vào giai đoạn kiểm thử cuối (tính trễ của rủi ro), nên phát hiện muộn và chi phí sửa lớn. Agile tạo phần mềm hoạt động ở mỗi vòng lặp, làm lộ sớm các vấn đề tích hợp, hiệu năng nên quản lý rủi ro sớm hơn.
| Phân loại | Phương pháp luận cấu trúc | Phương pháp luận Agile |
|---|---|---|
| Cách tiến hành | Tuần tự·Hoàn tất từng giai đoạn (Waterfall) | Lặp·Tăng dần (Iterative·Incremental) |
| Thay đổi yêu cầu | Kiểm soát·Tối thiểu hóa (CCB) | Tích cực tiếp nhận tại ranh giới vòng lặp |
| Giá trị cốt lõi | Tài liệu chi tiết·Kế hoạch·Khả năng dự đoán | Phần mềm hoạt động·Cộng tác khách hàng·Ứng phó thay đổi |
| Công cụ chính | DFD·Từ điển dữ liệu·Sơ đồ cấu trúc | Backlog·Sprint·Bảng·Burndown |
| Lộ diện rủi ro | Tập trung ở cuối (trễ) | Lộ sớm ở mỗi vòng lặp |
| Tình huống phù hợp | Yêu cầu ổn định·Quy mô lớn·Ngành bị quản lý | Yêu cầu không chắc chắn·Ứng phó thị trường nhanh |
3. Framework hiện thực Agile: Scrum và Kanban
Hai framework tiêu biểu hiện thực giá trị Agile thành thủ tục phát triển thực tế là Scrum và Kanban. Cả hai đều chia sẻ nguyên tắc “nhỏ, thường xuyên, minh bạch”, nhưng cách tiếp cận khác nhau ở chỗ Scrum là phương thức tạo nhịp điệu bằng timebox, vai trò và sự kiện, còn Kanban là phương thức trực quan hóa và tối ưu hóa chính luồng công việc.
A. Scrum — Lặp dựa trên timebox
Scrum là framework lấy Sprint — khoảng thời gian cố định 2~4 tuần — làm đơn vị, với mục tiêu hoàn thành (Done) công việc đã lập kế hoạch trong khoảng thời gian đó. Cốt lõi gồm ba vai trò, năm sự kiện và ba sản phẩm. Các vai trò được chia thành Product Owner (chủ sở hữu sản phẩm) chịu trách nhiệm về giá trị sản phẩm và thứ tự ưu tiên backlog, Scrum Master thúc đẩy quy trình và loại bỏ trở ngại, và Dev Team (nhóm phát triển) tự tổ chức và thực sự tạo ra sản phẩm.
Lý do sự phân tách vai trò này quan trọng là nó tách trách nhiệm “làm cái gì (PO)”, “làm tốt như thế nào (nhóm)” và “để quy trình vận hành tốt (SM)”, ngăn quyền lực tập trung vào một người. Đặc biệt, Scrum Master không phải người ra lệnh mà là lãnh đạo phục vụ (Servant Leader), đóng vai trò người thúc đẩy giúp nhóm tự giải quyết vấn đề.
Các sự kiện gồm lập kế hoạch sprint để xác định mục tiêu và công việc của sprint, daily scrum chia sẻ tiến độ và trở ngại trong 15 phút mỗi ngày, sprint review trình diễn kết quả cho các bên liên quan và nhận phản hồi, và hồi cứu (Retrospective) để cải tiến quy trình. Các sản phẩm là product backlog, sprint backlog và phần tăng trưởng (Increment) có thể bàn giao thực tế. Tình hình tiến độ được chia sẻ minh bạch bằng biểu đồ burndown (Burndown Chart) trực quan hóa lượng công việc còn lại.
flowchart TB
PB["Product backlog (ưu tiên)"] --> SP["Lập kế hoạch sprint"]
SP --> SB["Sprint backlog"]
SB --> DEV["Thực thi sprint (2~4 tuần)"]
DEV --> DS["Daily scrum (15 phút mỗi ngày)"]
DS --> DEV
DEV --> INC["Phần tăng trưởng có thể bàn giao tiềm năng"]
INC --> RV["Sprint review (trình diễn·phản hồi)"]
RV --> RE["Hồi cứu (cải tiến quy trình)"]
RE --> SP
style INC fill:#e8f0fe,stroke:#2f6fed
style DEV fill:#fef9c3,stroke:#ca8a04
B. Kanban — Xử lý liên tục dựa trên luồng (Flow)
Kanban là phương thức không có chu kỳ lặp cố định, trực quan hóa công việc bằng thẻ trên bảng (To Do → In Progress → Done) và giới hạn số công việc đang tiến hành đồng thời (WIP, Work In Progress) ở mỗi bước để tối ưu hóa luồng. Lý do giới hạn WIP là cơ chế cốt lõi là khi một người ôm nhiều việc cùng lúc, chi phí chuyển ngữ cảnh và thời gian chờ tăng lên, làm giảm thông lượng tổng thể. Khi giới hạn WIP, bước nút thắt cổ chai (Bottleneck) lộ ra rõ ràng, và nhóm tập trung vào “hoàn thành việc đang tồn đọng” hơn là bắt đầu việc mới.
Kanban không bắt buộc vai trò, sự kiện chính thức nên ít bị kháng cự khi áp dụng, và có ưu điểm là có thể đặt nguyên lên trên quy trình đang diễn ra. Vì vậy nó đặc biệt phù hợp với công việc vận hành, bảo trì, hỗ trợ kỹ thuật nơi yêu cầu đến liên tục. Hiệu quả của luồng được đo bằng thời gian dẫn (Lead Time) — thời gian một công việc đi từ bắt đầu đến hoàn thành, thông lượng (Throughput) — lượng hoàn thành trên đơn vị thời gian, và biểu đồ luồng tích lũy (CFD) thể hiện phân bố công việc theo thời gian.
C. So sánh Scrum và Kanban
| Phân loại | Scrum | Kanban |
|---|---|---|
| Chu kỳ | Sprint cố định (timebox) | Luồng liên tục (không chu kỳ) |
| Vai trò | PO·SM·Nhóm phát triển (chính thức) | Không quy định riêng (linh hoạt) |
| Điều tiết công việc | Cam kết theo đơn vị sprint | Điều tiết luồng bằng giới hạn WIP |
| Chỉ số cốt lõi | Vận tốc (Velocity)·Burndown | Thời gian dẫn·Thông lượng·CFD |
| Tiếp nhận thay đổi | Tránh thay đổi trong sprint | Tái ưu tiên bất cứ lúc nào |
| Tình huống phù hợp | Phát triển chức năng·Vòng lặp rõ ràng | Vận hành·Hỗ trợ·Xử lý liên tục |
Hai framework không loại trừ nhau. Scrumban — kết hợp nhịp điệu của Scrum (sprint, hồi cứu) với quản lý luồng của Kanban (giới hạn WIP, bảng) — được dùng rộng rãi trong thực tế, và cũng có nhiều tổ chức vận hành tách biệt: phát triển theo Scrum, vận hành và xử lý lỗi theo Kanban. Tiêu chí lựa chọn là “công việc đến theo lô (Batch) có thể lập kế hoạch hay đến liên tục như dòng chảy”.
4. Giải pháp thực hiện Agile hiệu quả và tình huống áp dụng
Nếu chỉ bắt chước hình thức Agile thì sẽ dừng ở mức “Agile chỉ trên danh nghĩa (Cargo-cult Agile)”. Để tạo ra thành quả thực sự, các yếu tố sau phải đi cùng nhau.
Thứ nhất là áp dụng từng bước và định hình văn hóa. Thay vì chuyển đổi toàn diện, cần bắt đầu từ nhóm thí điểm và lan tỏa kinh nghiệm thành công ra tổ chức, đồng thời xây dựng văn hóa cải tiến liên tục thông qua tự chủ, minh bạch và hồi cứu. Agile lấy nhóm tự tổ chức làm tiền đề, nên nếu văn hóa quản lý kiểu ra lệnh, kiểm soát vẫn còn thì chỉ còn lại hình thức.
Thứ hai là kết hợp với DevOps và CI/CD. “Bàn giao giá trị nhanh” của vòng lặp ngắn chỉ thực sự hiện thực được khi có tự động hóa build, kiểm thử, triển khai hỗ trợ. Nếu không có pipeline tự động, gánh nặng triển khai thủ công và kiểm thử hồi quy tích lũy qua mỗi chu kỳ lặp, khiến vòng lặp ngược lại làm nhóm kiệt sức. Ví dụ, Netflix và Amazon triển khai hàng nghìn lần mỗi ngày trên pipeline triển khai tự động, điều này cho thấy vòng lặp Agile phải kết hợp với DevOps thì mới đạt tốc độ ở quy mô lớn.
Thứ ba là tận dụng framework mở rộng quy mô lớn. Khi số nhóm tăng lên hàng chục, phát sinh vấn đề phụ thuộc và căn chỉnh giữa các nhóm, nên dung hòa bằng các hệ thống mở rộng điều phối nhiều nhóm agile như SAFe (Scaled Agile Framework), LeSS (Large-Scale Scrum), mô hình Spotify (Squad, Tribe, Chapter, Guild). Tại Hàn Quốc, các trường hợp các công ty tài chính, viễn thông lớn áp dụng SAFe cho dự án hệ thống thế hệ mới và chuyển đổi số — căn chỉnh kế hoạch cấp cao nhưng giao việc thực thi của nhóm cho sự tự chủ — cũng đang tăng lên.
Thứ tư là dẫn dắt cải tiến bằng chỉ số phù hợp. Scrum quản lý khả năng dự đoán bằng vận tốc (Velocity), burndown, còn Kanban quản lý luồng bằng thời gian dẫn, thông lượng, nhưng phải dùng chỉ số làm chất liệu cho hồi cứu chứ không phải phương tiện kiểm soát nhóm. Nếu dùng vận tốc để so sánh, cạnh tranh giữa các nhóm sẽ sinh tác dụng ngược như thổi phồng ước tính.
5. Chuyên sâu: Xu hướng mới nhất và hướng ra đề dự kiến
Gần đây thảo luận về Agile đang mở rộng vượt ra ngoài “thực hành ở cấp nhóm” sang sự linh hoạt kinh doanh (Business Agility) của toàn tổ chức. Vì dù nhóm phát triển lặp nhanh đến đâu, nếu lập kế hoạch, ngân sách, mua sắm vẫn theo thác nước hằng năm thì thời gian dẫn tổng thể vẫn kéo dài, nên Beyond Budgeting — đưa cả ngân sách và quản trị theo luồng — và Quản lý chuỗi giá trị (VSM, Value Stream Management) — quản lý toàn bộ luồng giá trị — đang được chú ý. Ngoài ra, khi trợ lý lập trình AI (loại copilot) lan rộng khiến tốc độ phát triển trong vòng lặp tăng lên, quản lý backlog, định nghĩa tiêu chí chấp nhận (AC) và chất lượng kiểm thử tự động đang nổi lên như những nút thắt cổ chai.
Dưới góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), chủ đề này dễ được ra đề dưới dạng ① so sánh cấu trúc vs Agile theo “tính ổn định của yêu cầu, thời điểm lộ diện rủi ro”, ② phân biệt Scrum và Kanban theo các trục “chu kỳ, vai trò, chỉ số”, hoặc ③ viết luận về giải pháp lan tỏa Agile trong tổ chức quy mô lớn (SAFe, kết hợp DevOps). Bài làm nên kết thúc bằng kết luận cân bằng: “phương pháp luận không phải mục đích mà là phương tiện, và phải lựa chọn, kết hợp phù hợp với đặc tính dự án (tính không chắc chắn của yêu cầu, quy mô, quy định)”.
6. Các điểm cần cân nhắc và hàm ý
- Năng lực và văn hóa nhóm quyết định thành công hơn là phương pháp luận. Agile nếu không có văn hóa nhóm tự chủ, cộng tác sẽ sa vào chủ nghĩa hình thức chỉ còn lại các sự kiện. Thay đổi văn hóa tổ chức và lãnh đạo phải song hành với việc áp dụng phương pháp luận.
- Tối thiểu hóa tài liệu không phải là loại bỏ tài liệu. Phải duy trì tài liệu tối thiểu cần cho truy vết, bảo trì và kiểm toán (bản ghi quyết định kiến trúc, tiêu chí chấp nhận, ghi chú phát hành), và đặc biệt trong các ngành bị quản lý, phải định nghĩa các sản phẩm bắt buộc ngay trong Agile.
- Mô hình lai là giải pháp thực tế. Sự kết hợp kiểm soát kế hoạch cấp cao, ngân sách, kiến trúc theo cấu trúc và lặp thực thi phát triển theo Agile là giải pháp dung hòa thực dụng cho các dự án khu vực công, SI quy mô lớn nơi tính ổn định của yêu cầu và ứng phó thay đổi cùng tồn tại.
- Agile không có tự động hóa (DevOps, CI/CD) là không bền vững. Chu kỳ lặp càng ngắn thì gánh nặng kiểm thử, triển khai thủ công càng tích lũy, nên phải nhận thức tự động hóa pipeline là điều kiện tiên quyết của Agile và đầu tư vào đó.
- Dùng chỉ số làm chất liệu cải tiến chứ không phải để kiểm soát. Dùng vận tốc, thời gian dẫn để so sánh, đánh giá giữa các nhóm sẽ dẫn đến méo mó ước tính và kiệt sức. Chỉ số phải là công cụ để nhóm tự hồi cứu và tìm nút thắt.
Tài liệu tham khảo
- Agile Manifesto, https://agilemanifesto.org/
- Scrum Guide (Schwaber·Sutherland), https://scrumguides.org/
- Kanban University, https://kanban.university/
- Scaled Agile Framework (SAFe), https://scaledagileframework.com/
Tóm tắt một câu: Phương pháp luận cấu trúc cung cấp khả năng dự đoán lấy tuần tự và kế hoạch làm trung tâm, Agile cung cấp tính linh hoạt của lặp và ứng phó thay đổi; cần lựa chọn, kết hợp các hiện thực của Agile là Scrum (timebox, vai trò, sự kiện) và Kanban (giới hạn WIP, tối ưu hóa luồng) phù hợp với đặc tính dự án, và văn hóa nhóm, sự kết hợp với DevOps, CI/CD cùng việc sử dụng đúng đắn chỉ số quyết định thành công.