Trả lời nhanh: Agile là cách làm việc linh hoạt, chia dự án thành nhiều vòng ngắn, thường vài tuần. Sau mỗi vòng, đội giao một phần dùng được, lấy phản hồi thật rồi điều chỉnh kế hoạch. Agile dựa trên Tuyên ngôn Agile năm 2001 gồm 4 giá trị, 12 nguyên tắc; Scrum, Kanban, XP là các khung để thực hiện.
Điểm chính
- Agile là một tư duy (mindset) và bộ giá trị, không phải một phần mềm hay một quy trình cố định. Scrum chỉ là một trong nhiều khung làm việc theo tinh thần Agile.
- Tuyên ngôn Agile ra đời sau cuộc gặp của 17 người làm phần mềm tại khu nghỉ Snowbird, bang Utah (Mỹ), ngày 11–13/02/2001.
- Khác biệt lớn nhất so với Waterfall: Agile giao giá trị nhiều lần, phát hiện sai lệch sớm; Waterfall giao một lần ở cuối, hợp với việc đã rõ và ít thay đổi.
- Agile không có nghĩa là “không kế hoạch” hay “họp mỗi ngày là xong”. Đội làm Agile tốt vẫn lập kế hoạch, chỉ là lập nhiều lần và ngắn hơn.
- Đo Agile bằng thời gian giao hàng (lead time, cycle time) và kết quả cho người dùng. Đừng dùng velocity để so sánh hay chấm điểm các đội.
Mục lục
- Agile là gì?
- Agile ra đời như thế nào?
- 4 giá trị của Tuyên ngôn Agile là gì?
- 12 nguyên tắc Agile nói gì?
- Agile vận hành theo vòng lặp như thế nào?
- Agile và Waterfall khác nhau thế nào?
- Các mô hình Agile phổ biến: Scrum, Kanban, XP, Lean, SAFe
- Agile có dùng được ngoài phần mềm không?
- Khi nào nên và không nên dùng Agile?
- Chuyển đổi sang Agile cho một đội trong doanh nghiệp Việt Nam: 8 bước
- Những sai lầm phổ biến khi áp dụng Agile
- Đo hiệu quả Agile bằng chỉ số nào?
- Agile liên quan gì đến tự động hoá và chuyển đổi số?
- Câu hỏi thường gặp
Agile là gì?
Agile (tiếng Anh, nghĩa gốc là nhanh nhẹn, linh hoạt) là một cách tiếp cận quản lý công việc và phát triển sản phẩm theo vòng lặp. Thay vì lập một kế hoạch chi tiết cho cả năm rồi làm theo từng bước, đội Agile chia mục tiêu thành những phần nhỏ, làm xong từng phần, cho người dùng xem và điều chỉnh hướng đi dựa trên những gì học được.
Cụm từ đầy đủ là “phát triển phần mềm linh hoạt” (Agile Software Development), vì Agile sinh ra trong ngành phần mềm. Ngày nay, các đội marketing, nhân sự, vận hành cũng dùng tư duy này. Trong tiếng Việt, bạn sẽ gặp nhiều cách gọi: phương pháp Agile, mô hình Agile, quản lý dự án Agile, quản lý dự án linh hoạt. Về bản chất, chúng nói về cùng một tư duy.
Điểm cần hiểu đúng ngay từ đầu: Agile không phải một quy trình có các bước bắt buộc. Agile là một tập giá trị và nguyên tắc. Các “khung làm việc” (framework) như Scrum, Kanban, XP mới là những cách cụ thể để biến tư duy đó thành việc làm hằng ngày.
Một ví dụ dễ hình dung
Ví dụ minh hoạ. Một công ty bán lẻ muốn làm ứng dụng đặt hàng cho khách.
- Cách truyền thống: mất 2 tháng viết tài liệu yêu cầu cho mọi tính năng, 2 tháng thiết kế, 5 tháng lập trình, 1 tháng kiểm thử. Sau 10 tháng, khách mới thấy ứng dụng. Lúc đó mới phát hiện khách hầu như chỉ dùng tính năng “đặt lại đơn cũ”, còn phần “mạng xã hội trong app” gần như không ai đụng tới.
- Cách Agile: sau 3–4 tuần, đội ra mắt bản rất gọn cho một nhóm khách thử: xem sản phẩm, đặt hàng, thanh toán. Số liệu và góp ý cho thấy khách hay mua lặp lại, nên vòng tiếp theo đội làm ngay nút “đặt lại đơn cũ”. Phần mạng xã hội bị đẩy xuống cuối danh sách, có khi không bao giờ cần làm.
Cả hai cách đều có kế hoạch. Khác nhau ở chỗ Agile chấp nhận rằng ở thời điểm bắt đầu, không ai biết đủ. Vì vậy, Agile thiết kế quy trình để học nhanh và đổi hướng rẻ.
Agile ra đời như thế nào?
Trong những năm 1990, nhiều dự án phần mềm lớn được quản lý theo kiểu tuần tự: phân tích yêu cầu thật kỹ, rồi thiết kế, lập trình, kiểm thử, bàn giao. Cách làm này thường được gọi là Waterfall (thác nước). Khi công nghệ và thị trường đổi nhanh, nhiều dự án mất hàng năm mới bàn giao, và thứ bàn giao không còn khớp nhu cầu.
Song song, một số người làm phần mềm phát triển các phương pháp “nhẹ” hơn: Extreme Programming (XP), Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming. Mỗi nhóm một cách, nhưng cùng hướng tới làm từng phần nhỏ, gần khách hàng và chấp nhận thay đổi.
Theo phần lịch sử do Jim Highsmith viết trên trang chính thức của Tuyên ngôn, ngày 11–13/02/2001, 17 người đại diện cho các phương pháp trên gặp nhau tại khu nghỉ trượt tuyết The Lodge at Snowbird, vùng núi Wasatch, bang Utah (Mỹ). Họ tự gọi nhóm mình là “Liên minh Agile” (Agile Alliance) và thống nhất bản “Tuyên ngôn phát triển phần mềm linh hoạt” (Manifesto for Agile Software Development), thường gọi tắt là Tuyên ngôn Agile. Trong số người ký có Kent Beck (cha đẻ XP), Ken Schwaber và Jeff Sutherland (hai tác giả của Scrum Guide), Martin Fowler, Alistair Cockburn, Ward Cunningham.
Một sự thật ít người biết: bài báo năm 1970 của Winston W. Royce, “Managing the Development of Large Software Systems”, thường được coi là nguồn gốc mô hình Waterfall. Nhưng bài báo không dùng chữ “waterfall”. Royce còn chỉ ra rằng làm tuần tự thuần tuý, để kiểm thử đến cuối, là rủi ro và dễ thất bại. Nói cách khác, chính người được gắn với Waterfall cũng không khuyên làm Waterfall “nguyên bản”.
4 giá trị của Tuyên ngôn Agile là gì?
Tuyên ngôn Agile rất ngắn. Phần cốt lõi là 4 cặp giá trị, mỗi cặp viết theo dạng “A hơn B”. Câu chốt của Tuyên ngôn nói rõ: các mục bên phải vẫn có giá trị, nhưng nhóm tác giả coi trọng các mục bên trái hơn. Đây là chỗ hay bị hiểu sai nhất.
| Coi trọng hơn | Vẫn có giá trị, nhưng xếp sau | Nghĩa thực tế | Hiểu sai thường gặp |
|---|---|---|---|
| Cá nhân và sự tương tác | Quy trình và công cụ | Người trong đội nói chuyện trực tiếp, giải quyết vấn đề cùng nhau, thay vì chuyền phiếu yêu cầu qua lại | “Agile thì không cần quy trình” |
| Phần mềm chạy được | Tài liệu đầy đủ | Tiến độ được chứng minh bằng thứ dùng được, không phải bằng số trang tài liệu | “Agile thì bỏ tài liệu” |
| Hợp tác với khách hàng | Đàm phán hợp đồng | Khách hàng là người cùng đội, góp ý thường xuyên, không chỉ xuất hiện lúc ký và lúc nghiệm thu | “Agile thì không cần hợp đồng rõ ràng” |
| Phản hồi với thay đổi | Làm theo kế hoạch | Kế hoạch được cập nhật khi có thông tin mới, thay vì cố bám kế hoạch đã lỗi thời | “Agile thì không cần kế hoạch” |
Ở ngoài lĩnh vực phần mềm, bạn có thể đọc “phần mềm chạy được” thành “kết quả dùng được”: một chiến dịch quảng cáo đã chạy thử, một quy trình tuyển dụng đã áp dụng cho vài vị trí, một biểu mẫu đã có người điền thật.
12 nguyên tắc Agile nói gì?
Đi kèm 4 giá trị là 12 nguyên tắc. Bảng dưới diễn giải từng nguyên tắc bằng lời dễ hiểu, kèm câu hỏi giúp bạn tự kiểm tra đội mình có đang làm đúng tinh thần hay không.
| # | Ý chính của nguyên tắc | Câu hỏi tự kiểm tra |
|---|---|---|
| 1 | Ưu tiên cao nhất là làm khách hàng hài lòng bằng cách giao sớm và giao liên tục những thứ có giá trị. | Lần gần nhất khách hàng nhận được thứ dùng được là khi nào? |
| 2 | Sẵn sàng đón nhận thay đổi yêu cầu, kể cả khi đã muộn, nếu thay đổi đó giúp khách hàng có lợi thế. | Đội có cơ chế đổi ưu tiên mà không phải “đập đi làm lại” kế hoạch cả năm không? |
| 3 | Giao sản phẩm chạy được thường xuyên, từ vài tuần đến vài tháng, càng ngắn càng tốt. | Chu kỳ giao hàng của đội đang là bao lâu? |
| 4 | Người làm nghiệp vụ và người làm kỹ thuật phải làm việc cùng nhau hằng ngày. | Người hiểu nghiệp vụ có trả lời câu hỏi của đội trong ngày không, hay phải chờ cả tuần? |
| 5 | Xây dựng dự án quanh những người có động lực, cho họ môi trường, sự hỗ trợ và tin tưởng họ làm được việc. | Đội có được tự quyết cách làm, hay mọi việc nhỏ đều phải xin duyệt? |
| 6 | Trao đổi trực tiếp, mặt đối mặt là cách truyền thông tin hiệu quả nhất. | Có bao nhiêu hiểu lầm đang “nằm” trong chuỗi email dài? |
| 7 | Sản phẩm chạy được là thước đo tiến độ chính. | Báo cáo tiến độ đang đo “phần trăm công việc” hay “phần đã dùng được”? |
| 8 | Phát triển bền vững: nhà tài trợ, người làm và người dùng giữ được nhịp độ ổn định lâu dài. | Đội có đang tăng ca liên tục để kịp mỗi vòng không? |
| 9 | Luôn chú ý đến chất lượng kỹ thuật và thiết kế tốt, vì đó là thứ giúp đội linh hoạt. | Mỗi lần sửa một chỗ có làm hỏng chỗ khác không? |
| 10 | Sự đơn giản, tức nghệ thuật tối đa hoá phần việc không cần làm, là điều thiết yếu. | Trong danh sách việc, có bao nhiêu mục “làm cho đủ bộ” mà không ai thực sự cần? |
| 11 | Kiến trúc, yêu cầu và thiết kế tốt nhất đến từ những đội tự tổ chức. | Ai quyết định cách chia việc: đội hay một người đứng ngoài? |
| 12 | Định kỳ, đội nhìn lại cách làm việc để hiệu quả hơn, rồi điều chỉnh hành vi cho phù hợp. | Buổi nhìn lại gần nhất đã dẫn tới thay đổi cụ thể nào? |
Nếu đội bạn trả lời “chưa” cho phần lớn câu hỏi trên, việc đổi tên cuộc họp thành “sprint” hay mua bảng Kanban chưa làm đội trở nên Agile.
Agile vận hành theo vòng lặp như thế nào?
Trái tim của Agile là vòng lặp ngắn (iteration). Mỗi vòng lấy một số việc quan trọng nhất từ danh sách việc đã sắp xếp ưu tiên (backlog), làm xong, cho người dùng xem, rồi rút kinh nghiệm cho vòng sau.
Năm bước trong một vòng, diễn giải ngắn:
- Lập kế hoạch: đội chọn vài việc có giá trị nhất mà vòng này làm xong được, và thống nhất “thế nào là xong”.
- Xây dựng: làm phần nhỏ nhất đủ để người dùng thấy và dùng. Tránh làm dở dang nhiều việc cùng lúc.
- Kiểm thử: kiểm tra ngay trong vòng, không dồn đến cuối. Việc chỉ được tính là xong khi đạt tiêu chí đã thống nhất.
- Demo, lấy phản hồi: cho người dùng hoặc người đặt hàng xem kết quả thật, không phải xem slide.
- Cải tiến: đội nhìn lại cách làm việc trong vòng vừa qua, chọn một hai điều để làm khác đi.
Hai khái niệm hay đi cùng nhau: lặp (iterative), tức làm đi làm lại để hoàn thiện dần, và tăng trưởng (incremental), tức mỗi lần thêm một phần mới vào sản phẩm. Agile kết hợp cả hai. Ba thao tác “minh bạch, kiểm tra, điều chỉnh” (transparency, inspection, adaptation) là nền tảng thực nghiệm mà Scrum Guide 2020 nêu rõ, và cũng đúng với Agile nói chung.
Agile và Waterfall khác nhau thế nào?
Waterfall chia dự án thành các giai đoạn nối tiếp: xong giai đoạn trước mới sang giai đoạn sau. Agile chia dự án thành nhiều vòng ngắn, mỗi vòng có đủ các hoạt động từ lập kế hoạch đến kiểm thử. Sơ đồ dưới cho thấy khác biệt quan trọng nhất: thời điểm người dùng nhận được giá trị.
| Tiêu chí | Waterfall | Agile |
|---|---|---|
| Cách lập kế hoạch | Lập chi tiết một lần ở đầu dự án | Lập kế hoạch tổng quan, chi tiết hoá dần theo từng vòng |
| Phạm vi, thời gian, chi phí | Cố định phạm vi, ước tính thời gian và chi phí theo phạm vi | Thường cố định thời gian và nguồn lực, linh hoạt phạm vi theo ưu tiên |
| Khi nào có sản phẩm dùng được | Cuối dự án | Sau mỗi vòng (vài tuần) |
| Xử lý thay đổi yêu cầu | Qua quy trình kiểm soát thay đổi, tốn kém khi đã sang giai đoạn sau | Đón nhận, sắp xếp lại ưu tiên trong backlog |
| Vai trò khách hàng | Tham gia nhiều ở đầu (yêu cầu) và cuối (nghiệm thu) | Tham gia đều đặn, xem kết quả mỗi vòng |
| Kiểm thử | Một giai đoạn riêng, sau khi làm xong | Diễn ra liên tục trong từng vòng |
| Tài liệu | Đầy đủ, là đầu ra chính của từng giai đoạn | Vừa đủ để làm việc và bàn giao, cập nhật theo sản phẩm |
| Đo tiến độ | Phần trăm hoàn thành theo kế hoạch | Phần sản phẩm đã dùng được, thời gian giao hàng |
| Khi nào lộ rủi ro | Thường muộn, ở giai đoạn kiểm thử hoặc nghiệm thu | Sớm, sau mỗi lần demo |
| Cơ cấu đội | Chia theo chức năng, chuyển giao giữa các phòng | Đội liên chức năng, ngồi chung, cùng chịu trách nhiệm kết quả |
| Phù hợp nhất với | Việc đã rõ, ít thay đổi, chi phí sửa sau rất cao (xây dựng, lắp đặt hạ tầng, tuân thủ pháp lý chặt) | Việc nhiều ẩn số, nhu cầu thay đổi, cần phản hồi nhanh (sản phẩm số, cải tiến dịch vụ, marketing) |
Không có cách nào “tốt hơn” trong mọi trường hợp. Nhiều doanh nghiệp dùng cách lai (hybrid): giai đoạn khảo sát, ký hợp đồng, phê duyệt ngân sách theo kiểu tuần tự; phần xây dựng sản phẩm thì chạy theo vòng lặp. Cách lai chỉ có ích khi phần chạy vòng lặp thực sự giao được kết quả cho người dùng giữa chừng. Nếu mọi thứ vẫn dồn về một lần nghiệm thu cuối, đó là Waterfall đổi tên.
Các mô hình Agile phổ biến: Scrum, Kanban, XP, Lean, SAFe
Khi nói “mô hình Agile” hay “phương pháp Agile”, người ta thường muốn nói đến các khung làm việc cụ thể dưới đây. Chúng không loại trừ nhau. Nhiều đội dùng Scrum để tổ chức nhịp làm việc, bảng Kanban để quản lý luồng việc và các kỹ thuật XP để giữ chất lượng.
Scrum: khung làm việc theo sprint
Scrum là khung Agile phổ biến nhất. Theo Scrum Guide 2020 (phiên bản tháng 11/2020) của Ken Schwaber và Jeff Sutherland, Scrum là một khung làm việc gọn nhẹ giúp con người, đội nhóm và tổ chức tạo ra giá trị thông qua các giải pháp thích ứng cho những vấn đề phức tạp. Đội làm việc theo các sprint dài tối đa một tháng; một đội Scrum thường có từ 10 người trở xuống, gồm ba trách nhiệm: Product Owner, Scrum Master và Developers.
Scrum có hệ thống sự kiện, vai trò và tạo phẩm riêng, cần một bài phân tích đầy đủ. Ở đây bạn chỉ cần nhớ: Scrum là một cách làm Agile, có nhịp cố định, phù hợp với đội phát triển sản phẩm cần cam kết theo chu kỳ.
Agile Scrum là gì? Agile và Scrum có phải là một?
“Agile Scrum” là cách gọi phổ biến ở Việt Nam để chỉ việc áp dụng Agile bằng khung Scrum. Agile là triết lý, Scrum là một công thức cụ thể để thực hiện triết lý đó. Một đội có thể Agile mà không dùng Scrum (ví dụ dùng Kanban). Ngược lại, một đội có thể làm đủ các cuộc họp Scrum nhưng không Agile, nếu không giao được kết quả và không điều chỉnh theo phản hồi.
Kanban: quản lý luồng công việc
Kanban (tiếng Nhật, nghĩa là “bảng hiệu” hay “thẻ”) bắt nguồn từ hệ thống sản xuất “đúng lúc” (just-in-time) mà Toyota áp dụng từ cuối những năm 1940, do Taiichi Ohno thiết kế. David J. Anderson đưa Kanban vào phát triển phần mềm và công việc tri thức, với cuốn sách xuất bản năm 2010.
Kanban không có sprint. Việc chảy liên tục qua các cột trên bảng (ví dụ: Cần làm, Đang làm, Chờ duyệt, Xong). Hai thực hành cốt lõi:
- Trực quan hoá công việc: mọi việc đều nằm trên bảng, ai cũng thấy việc đang tắc ở đâu.
- Giới hạn việc đang làm (WIP limit): mỗi cột chỉ được chứa tối đa một số việc. Muốn kéo việc mới vào phải làm xong việc cũ. Đây là “bí quyết” khiến việc chảy nhanh hơn, dù nghe có vẻ ngược đời.
Kanban hợp với đội có việc đến liên tục, khó lên kế hoạch trước vài tuần: hỗ trợ khách hàng, vận hành hệ thống, xử lý hồ sơ, sản xuất nội dung. Nếu bạn đang thiết kế lại cách việc chạy giữa các bước và các bộ phận, bài viết về quy trình công việc (workflow) sẽ giúp bạn vẽ luồng trước khi đưa lên bảng Kanban.
XP (Extreme Programming): kỷ luật kỹ thuật
Extreme Programming do Kent Beck phát triển khi làm dự án tính lương C3 của hãng Chrysler (giữa thập niên 1990). Cuốn “Extreme Programming Explained” của ông xuất bản tháng 10/1999. XP tập trung vào chất lượng kỹ thuật, với các thực hành như:
- Lập trình theo cặp (pair programming): hai người cùng làm trên một đoạn mã.
- Viết kiểm thử trước khi viết mã (test-driven development, TDD).
- Tích hợp liên tục (continuous integration): mã được gộp và kiểm thử tự động nhiều lần mỗi ngày.
- Tái cấu trúc mã (refactoring) thường xuyên và phát hành nhỏ, thường xuyên.
Nhiều đội “làm Scrum” nhưng thất bại vì bỏ qua phần kỹ thuật này: giao nhanh mà không có kiểm thử tự động thì mỗi vòng lại sinh thêm lỗi, càng về sau càng chậm.
Lean: loại bỏ lãng phí
Lean bắt nguồn từ Hệ thống sản xuất Toyota. Khái niệm “phát triển phần mềm tinh gọn” (Lean Software Development) đến từ cuốn sách năm 2003 của Mary và Tom Poppendieck, với 7 nguyên tắc: loại bỏ lãng phí, khuếch đại việc học, quyết định muộn nhất có thể, giao nhanh nhất có thể, trao quyền cho đội, xây chất lượng ngay từ trong, tối ưu toàn cục.
Với doanh nghiệp, Lean đặc biệt hữu ích ở câu hỏi “việc này có tạo giá trị cho khách hàng không?”. Những bước chờ duyệt, chuyển giao, làm lại đều là lãng phí cần cắt. Khi lãng phí nằm ở chính cấu trúc quy trình chứ không chỉ ở một đội, bạn có thể cần nhìn rộng hơn với tái cấu trúc quy trình kinh doanh (BPR).
SAFe và Agile ở quy mô lớn
Khi nhiều đội cùng làm một sản phẩm lớn, cần cơ chế phối hợp. Scaled Agile Framework (SAFe) là khung mở rộng phổ biến nhất, do Dean Leffingwell khởi xướng, ra mắt chính thức năm 2011; phiên bản 6.0 phát hành tháng 3/2023. SAFe gom nhiều đội vào một “đoàn tàu phát hành” (Agile Release Train) và lập kế hoạch chung theo các chu kỳ dài khoảng vài tháng.
SAFe cũng bị phê bình nhiều: một số người ký Tuyên ngôn Agile và chuyên gia cho rằng nó nặng về phân cấp, tạo “ảo giác Agile” trong khi giữ nguyên cách quản lý cũ. Lời khuyên thực tế: hãy làm Agile tốt ở cấp một vài đội trước, chỉ tính chuyện mở rộng khi việc phối hợp giữa các đội thực sự là nút thắt.
Bảng so sánh nhanh các khung Agile
| Khung | Nhịp làm việc | Trọng tâm | Hợp với | Lưu ý |
|---|---|---|---|---|
| Scrum | Sprint cố định, tối đa 1 tháng | Cam kết mục tiêu theo chu kỳ, vai trò rõ | Đội phát triển sản phẩm 3–10 người | Dễ biến thành chuỗi họp nếu không giao được kết quả |
| Kanban | Liên tục, không chia vòng | Luồng việc, giới hạn việc đang làm | Hỗ trợ, vận hành, nội dung, việc đến bất chợt | Cần kỷ luật giữ giới hạn WIP |
| XP | Vòng ngắn, phát hành nhỏ | Chất lượng kỹ thuật | Đội lập trình | Đòi hỏi kỹ năng và đầu tư tự động hoá kiểm thử |
| Lean | Không quy định | Giá trị cho khách, cắt lãng phí | Mọi cấp, cả ngoài phần mềm | Là bộ nguyên tắc hơn là quy trình |
| SAFe | Sprint của đội cộng chu kỳ kế hoạch chung vài tháng | Phối hợp nhiều đội | Tổ chức lớn, hàng chục đội | Nặng, dễ thành phân cấp mới |
Ngoài ra còn các khung ít gặp hơn ở Việt Nam như Crystal, DSDM, Feature-Driven Development (FDD), và cách kết hợp Scrumban (nhịp của Scrum cộng bảng và giới hạn WIP của Kanban).
Agile có dùng được ngoài phần mềm không?
Có. Tư duy “làm nhỏ, xem kết quả, điều chỉnh” áp dụng được cho mọi công việc có nhiều ẩn số. Dưới đây là các ví dụ minh hoạ thường gặp.
Marketing
- Thay vì lên kế hoạch nội dung cố định cho cả quý, đội chạy vòng 2 tuần: thử 3–4 thông điệp quảng cáo, đo kết quả, dồn ngân sách cho thông điệp hiệu quả ở vòng sau.
- Backlog gồm các ý tưởng chiến dịch, sắp xếp theo giá trị kỳ vọng và công sức. Buổi demo cuối vòng là xem số liệu thật, không phải xem bản kế hoạch.
- Bảng Kanban giúp thấy bài viết, video đang tắc ở khâu nào: viết, duyệt nội dung, thiết kế hay chờ pháp chế.
Nhân sự
- Tuyển dụng theo bảng Kanban: mỗi ứng viên là một thẻ đi qua các cột sàng lọc, phỏng vấn, đề nghị, nhận việc. Giới hạn số vị trí tuyển song song giúp đội không bị dàn trải.
- Thay đánh giá hiệu suất một lần mỗi năm bằng trao đổi ngắn định kỳ, giống buổi nhìn lại của đội Agile.
- Thiết kế chương trình đào tạo hội nhập theo vòng: chạy thử với một nhóm nhân viên mới, lấy góp ý, chỉnh rồi mới áp dụng toàn công ty.
Vận hành và cải tiến quy trình
- Đội vận hành dùng Kanban để quản lý yêu cầu nội bộ, đo thời gian xử lý từng loại yêu cầu.
- Cải tiến quy trình theo từng bước nhỏ: tự động hoá một khâu, đo kết quả rồi mới làm khâu tiếp. Các nền tảng low-code, no-code giúp đội nghiệp vụ tự dựng biểu mẫu, luồng duyệt trong vài ngày, rất hợp với nhịp vòng lặp ngắn.
- Gắn mục tiêu quý của bộ phận với các vòng làm việc: nhiều doanh nghiệp kết hợp Agile với OKR (mục tiêu và kết quả then chốt), trong đó OKR trả lời “đạt kết quả gì”, còn Agile trả lời “làm theo nhịp nào, điều chỉnh ra sao”.
Khi nào nên và không nên dùng Agile?
Agile không phải lời giải cho mọi việc. Hãy dựa vào bản chất công việc, không dựa vào trào lưu.
| Dấu hiệu | Nên dùng Agile | Cân nhắc cách tuần tự hoặc lai |
|---|---|---|
| Mức độ rõ ràng của yêu cầu | Yêu cầu chưa rõ, sẽ thay đổi khi người dùng thấy sản phẩm | Yêu cầu đã rõ, ổn định, có tiêu chuẩn sẵn |
| Khả năng chia nhỏ | Chia được thành phần nhỏ, mỗi phần dùng được ngay | Chỉ có giá trị khi hoàn thành toàn bộ (ví dụ một cây cầu) |
| Chi phí thay đổi | Đổi hướng rẻ (phần mềm, nội dung, chiến dịch) | Đổi hướng rất đắt hoặc không thể (đã đổ bê tông, đã sản xuất hàng loạt) |
| Sự tham gia của người dùng hoặc khách hàng | Có người đại diện nghiệp vụ dành thời gian góp ý đều đặn | Khách hàng chỉ muốn nhận kết quả cuối, không tham gia giữa chừng |
| Ràng buộc pháp lý, hợp đồng | Hợp đồng cho phép linh hoạt phạm vi theo ưu tiên | Phạm vi phải cố định theo hồ sơ phê duyệt, khó điều chỉnh |
| Đội ngũ | Đội ổn định, ngồi gần nhau hoặc phối hợp trực tuyến tốt, được trao quyền | Nhân sự kiêm nhiệm quá nhiều dự án, thay đổi liên tục |
Ngay cả với dự án đi theo kiểu tuần tự, bạn vẫn có thể mượn một vài thực hành Agile: họp ngắn đầu ngày để gỡ vướng mắc, bảng việc trực quan, buổi nhìn lại sau mỗi giai đoạn.
Chuyển đổi sang Agile cho một đội trong doanh nghiệp Việt Nam: 8 bước
Phần lớn thất bại khi áp dụng Agile không đến từ kỹ thuật, mà đến từ thói quen quản lý. Ở nhiều doanh nghiệp Việt Nam, có vài đặc điểm cần tính trước: quyết định tập trung ở cấp trên, nhân viên ngại nói “không” hoặc ngại báo tin xấu, KPI tính theo cá nhân, hợp đồng và ngân sách duyệt theo hạng mục cố định, nhân sự kiêm nhiệm nhiều việc. Lộ trình dưới đây giúp bạn bắt đầu nhỏ và an toàn.
- Xác định vấn đề cần giải, không phải “làm Agile cho kịp xu hướng”. Ví dụ: “dự án nội bộ luôn trễ 3 tháng”, “phòng marketing không biết chiến dịch nào hiệu quả”. Vấn đề rõ giúp bạn đo được Agile có giúp gì hay không.
- Chọn một đội thí điểm. Đội 5–9 người, làm một sản phẩm hoặc dịch vụ có người dùng thật, có lãnh đạo sẵn sàng bảo trợ. Tránh chọn dự án sống còn hoặc dự án đã gần xong.
- Có người làm “chủ sản phẩm” thật sự. Một người có quyền quyết định thứ tự ưu tiên, dành được thời gian cho đội hằng tuần. Nếu mọi ưu tiên vẫn phải chờ giám đốc duyệt, hãy để giám đốc tham gia buổi demo thay vì duyệt qua email.
- Đào tạo ngắn cho cả đội và quản lý trực tiếp. Quản lý cần hiểu vai trò mới của mình: gỡ vướng, bảo vệ đội khỏi việc chen ngang, không giao việc trực tiếp cho từng cá nhân trong vòng.
- Chọn khung phù hợp và bắt đầu đơn giản. Việc phát triển sản phẩm thì thử Scrum với sprint 2 tuần; việc đến liên tục thì dùng Kanban. Một bảng giấy trên tường hoặc bảng tính dùng chung là đủ để bắt đầu; chỉ chọn công cụ sau khi cách làm đã ổn.
- Thiết lập cuộc họp tối thiểu và giữ đúng giờ. Họp lập kế hoạch đầu vòng, họp ngắn hằng ngày khoảng 15 phút, demo và nhìn lại cuối vòng. Không thêm báo cáo song song theo mẫu cũ nếu demo đã cho thấy tiến độ.
- Đo trước và sau. Ghi lại thời gian giao hàng, số lỗi phát sinh, mức hài lòng của người dùng trước khi thí điểm. Sau 2–3 tháng (mốc minh hoạ, tuỳ quy mô), so sánh và chia sẻ trung thực, kể cả điều chưa tốt.
- Mở rộng có chọn lọc và điều chỉnh các “luật chơi” xung quanh. Khi mở rộng sang nhiều đội, phải sửa cả những thứ ngoài đội: cách duyệt ngân sách theo giai đoạn thay vì một lần, KPI có phần chung của đội, mẫu hợp đồng với đối tác cho phép linh hoạt phạm vi. Đây cũng là một phần của chuyển đổi số trong doanh nghiệp, vốn đòi hỏi thay đổi cả cách tổ chức chứ không chỉ công nghệ.
Lưu ý về văn hoá: buổi nhìn lại chỉ có tác dụng khi mọi người dám nói thật. Nếu trưởng phòng ngồi trong buổi nhìn lại và nhân viên im lặng, hãy thử để đội tự nhìn lại, hoặc dùng phiếu góp ý ẩn danh, rồi chỉ mang ra các việc cần cấp trên hỗ trợ.
Những sai lầm phổ biến khi áp dụng Agile
“Agile là không cần kế hoạch”
Đây là hiểu lầm lớn nhất. Agile lập kế hoạch nhiều hơn chứ không ít hơn: kế hoạch tổng thể theo quý, kế hoạch mỗi vòng, điều chỉnh hằng ngày. Khác biệt là kế hoạch được coi là giả thuyết để kiểm chứng, không phải cam kết bất biến. Lãnh đạo vẫn cần biết khoảng thời gian, ngân sách và mục tiêu; đội Agile tốt trả lời được các câu đó bằng số liệu thực tế từ các vòng trước.
Họp quá nhiều mà không giao được gì
Nhiều đội thêm họp đầu ngày, họp lập kế hoạch, họp demo, họp nhìn lại nhưng vẫn giữ nguyên các cuộc họp báo cáo cũ. Kết quả là nhân viên ngồi họp nhiều hơn làm. Dấu hiệu cần sửa: họp hằng ngày kéo dài 45 phút và biến thành báo cáo với sếp; buổi demo chỉ trình chiếu slide. Cách sửa: giữ thời lượng cố định, bỏ báo cáo trùng lặp, và mỗi cuộc họp phải có đầu ra rõ.
Agile “hình thức” (cargo cult)
Cargo cult chỉ việc bắt chước hình thức bên ngoài mà không hiểu bản chất. Đội đổi tên mọi thứ (sprint, backlog, stand-up), mua công cụ quản lý dự án đắt tiền, nhưng sau mỗi sprint không có gì đến tay người dùng, ưu tiên vẫn do một người quyết từ trên xuống, buổi nhìn lại không dẫn tới thay đổi nào. Một biến thể khác: “Water-Scrum-Fall”, tức phân tích yêu cầu kiểu Waterfall, lập trình theo sprint, rồi kiểm thử và triển khai dồn ở cuối.
Bỏ hẳn tài liệu và chất lượng kỹ thuật
“Phần mềm chạy được hơn tài liệu đầy đủ” không có nghĩa là không viết gì. Thiếu tài liệu tối thiểu, đội mới vào không hiểu hệ thống, việc bàn giao và bảo trì rất khó. Tương tự, bỏ kiểm thử để giao nhanh sẽ khiến mỗi vòng sau chậm hơn vòng trước.
Nhồi việc vào mỗi vòng
Quản lý nhìn thấy đội giao được việc sau 2 tuần, liền nhồi thêm việc cho vòng sau. Đội tăng ca, chất lượng giảm, đúng điều nguyên tắc số 8 về nhịp độ bền vững muốn tránh.
Dùng velocity để chấm điểm đội
Phần dưới giải thích kỹ vì sao đây là một sai lầm tốn kém.
Đo hiệu quả Agile bằng chỉ số nào?
Mục tiêu của đo lường trong Agile là giúp đội tự cải tiến và giúp lãnh đạo dự báo, không phải để xếp hạng con người. Các chỉ số nên theo dõi:
| Chỉ số | Đo cái gì | Dùng để | Lưu ý |
|---|---|---|---|
| Lead time (thời gian đáp ứng) | Từ khi yêu cầu được ghi nhận đến khi giao cho người dùng | Trả lời câu hỏi của khách: “bao lâu thì có?” | Định nghĩa điểm bắt đầu khác nhau giữa các tổ chức; hãy thống nhất trước khi đo |
| Cycle time (thời gian xử lý) | Từ khi đội bắt đầu làm đến khi xong | Tìm khâu chậm, tắc trong luồng việc | Nên xem phân bố (ví dụ 85% việc xong trong bao nhiêu ngày), không chỉ trung bình |
| Throughput (thông lượng) | Số việc hoàn thành trong một khoảng thời gian | Dự báo khi nào xong một nhóm việc | Việc phải có kích thước tương đối đồng đều |
| WIP (việc đang làm) | Số việc đang dở dang cùng lúc | Phát hiện đội ôm quá nhiều việc | WIP cao thường kéo cycle time dài |
| Velocity (tốc độ) | Lượng việc đội hoàn thành mỗi sprint, thường tính bằng điểm ước lượng (story point) | Đội tự lập kế hoạch cho sprint sau | Chỉ có ý nghĩa trong nội bộ một đội, xem cảnh báo bên dưới |
| Chất lượng | Số lỗi lọt đến người dùng, tỷ lệ phải làm lại | Đảm bảo giao nhanh không đổi bằng chất lượng | Đo cùng lúc với tốc độ để tránh “nhanh mà ẩu” |
| Kết quả cho người dùng | Mức hài lòng, tỷ lệ dùng tính năng, chỉ số kinh doanh liên quan | Kiểm tra đội đang làm đúng việc | Quan trọng nhất nhưng hay bị quên |
Giữa các chỉ số luồng có một quan hệ đơn giản, thường gọi là định luật Little trong lý thuyết hàng đợi: thời gian xử lý trung bình bằng số việc đang làm trung bình chia cho thông lượng trung bình. Hệ quả thực tế: muốn giao nhanh hơn mà không tăng người, cách dễ nhất là bớt ôm việc dở dang.
Cảnh báo khi dùng velocity
Velocity là công cụ lập kế hoạch của đội, không phải thước đo năng suất. Ngay cả Scrum Guide 2020 cũng không nhắc đến từ “velocity”; nó chỉ là một thực hành được nhiều đội dùng thêm.
- Không so sánh giữa các đội. Mỗi đội có thang điểm ước lượng riêng. Đội A làm 40 điểm và đội B làm 20 điểm không có nghĩa đội A giỏi gấp đôi.
- Không dùng làm KPI cá nhân hay căn cứ thưởng. Khi một con số trở thành mục tiêu, nó thôi là thước đo tốt (thường được gọi là định luật Goodhart). Đội sẽ “lạm phát điểm”: việc trước ước 3 điểm, nay ước 5 điểm, velocity tăng nhưng sản phẩm không nhanh hơn.
- Không ép velocity tăng đều. Velocity ổn định mới là dấu hiệu tốt, vì nó giúp dự báo. Tăng liên tục thường là dấu hiệu điểm đang bị thổi phồng hoặc đội đang làm quá sức.
- Đo đầu ra, đừng quên kết quả. Đội có thể giao rất nhiều tính năng mà không ai dùng. Hãy luôn đặt velocity cạnh các chỉ số về chất lượng và giá trị cho người dùng.
Agile liên quan gì đến tự động hoá và chuyển đổi số?
Agile là cách tổ chức công việc, còn tự động hoá và chuyển đổi số là nội dung công việc. Hai thứ bổ trợ nhau. Các dự án số hoá, tự động hoá quy trình thường có nhiều ẩn số: dữ liệu thật bẩn hơn dự kiến, người dùng phản ứng khác kỳ vọng. Làm theo vòng lặp giúp phát hiện sớm những điều đó. Ví dụ, khi triển khai tự động hoá quy trình, bạn có thể tự động hoá một luồng duyệt chứng từ cho một phòng trước, đo thời gian xử lý, rồi mới nhân rộng, thay vì thiết kế cùng lúc cho cả tập đoàn.
Ngược lại, Agile cũng cần nền tảng: muốn giao phần mềm vài tuần một lần, đội cần kiểm thử và triển khai tự động; muốn đo lead time, công việc phải được ghi nhận trên một hệ thống chung thay vì rải rác trong tin nhắn.
Câu hỏi thường gặp
Agile là phương pháp hay tư duy?
Agile trước hết là tư duy và bộ giá trị, được viết thành Tuyên ngôn Agile với 4 giá trị và 12 nguyên tắc. Các phương pháp, khung làm việc cụ thể như Scrum, Kanban, XP là cách hiện thực hoá tư duy đó. Vì vậy câu hỏi đúng không phải “đội có làm Agile không” mà là “đội có giao giá trị sớm và điều chỉnh theo phản hồi không”.
Agile và Scrum khác nhau thế nào?
Agile là triết lý chung; Scrum là một khung làm việc cụ thể theo triết lý đó, với sprint tối đa một tháng, ba trách nhiệm (Product Owner, Scrum Master, Developers) và các sự kiện cố định. Mọi đội làm Scrum đúng cách đều là Agile, nhưng đội Agile không nhất thiết dùng Scrum.
Một vòng lặp Agile nên dài bao lâu?
Tuyên ngôn Agile khuyến khích giao sản phẩm sau vài tuần đến vài tháng, càng ngắn càng tốt. Scrum giới hạn sprint tối đa một tháng. Nhiều đội chọn 2 tuần vì đủ dài để làm xong việc có ý nghĩa và đủ ngắn để đổi hướng kịp. Kanban thì không chia vòng, việc chảy liên tục.
Đội nhỏ 3–4 người có cần làm Agile không?
Đội nhỏ thường làm Agile dễ hơn đội lớn vì giao tiếp trực tiếp, ít khâu chuyển giao. Bạn không cần đủ các vai trò và cuộc họp như sách; một bảng Kanban, buổi demo với người dùng và buổi nhìn lại ngắn mỗi 2 tuần đã mang lại phần lớn lợi ích.
Làm Agile thì có cần tài liệu và hợp đồng không?
Có. Tuyên ngôn chỉ nói coi trọng sản phẩm chạy được hơn tài liệu đầy đủ, và coi trọng hợp tác hơn đàm phán hợp đồng; tài liệu và hợp đồng vẫn có giá trị. Điều nên làm là viết tài liệu vừa đủ, cập nhật theo sản phẩm, và dùng hợp đồng cho phép điều chỉnh phạm vi theo ưu tiên, ví dụ thanh toán theo giai đoạn hoặc theo từng phần bàn giao.
Agile có phù hợp với doanh nghiệp sản xuất, thương mại truyền thống không?
Phù hợp ở những mảng có nhiều ẩn số: phát triển sản phẩm mới, marketing, bán hàng trực tuyến, cải tiến quy trình nội bộ, dự án số hoá. Còn dây chuyền sản xuất ổn định thì Lean và các phương pháp quản lý chất lượng thường hợp hơn. Bạn có thể bắt đầu Agile ở một phòng ban rồi mở rộng dần.
Có cần chứng chỉ mới làm Agile được không?
Không bắt buộc. Chứng chỉ giúp hệ thống hoá kiến thức và có thể hữu ích khi tuyển dụng, nhưng không thay được kinh nghiệm thực tế. Một đội hiểu 4 giá trị, 12 nguyên tắc, thực hành đều đặn và chịu nhìn lại trung thực thường làm tốt hơn một đội có nhiều chứng chỉ nhưng chỉ làm theo hình thức.
Làm sao biết đội mình đã thực sự Agile?
Ba dấu hiệu đơn giản: người dùng nhận được thứ dùng được đều đặn sau vài tuần; khi ưu tiên thay đổi, đội đổi hướng trong một vòng mà không xáo trộn lớn; mỗi buổi nhìn lại dẫn tới ít nhất một thay đổi cụ thể trong cách làm. Nếu thiếu cả ba, đội đang có hình thức Agile nhưng chưa có bản chất.