Agile nghĩa là gì

Agile là một tính từ, nó có nghĩa là dễ thích nghi, gọn nhẹ, khéo léo. Nếu bạn là người tập luyện thể thao, bạn sẽ bắt gặp từ agility trong nội dung huấn luyện (các tố chất vận động viên: nhanh, mạnh, chính xác và khéo léo).

Như vậy, Agile không có nghĩa là một quy trình, một biểu mẫu, một cái gì cố định hay đại loại như vậy. Như trong hình banner ở trên, ta thấy rõ không có môt quy trình một mẫu cố định nào có thể giúp vận động viên leo núi an toàn. Cô ta, phải uyển chuyển, linh hoạt, khéo léo, vận dụng những nguyên tắc, hiểu biết và kinh nghiệm.

Ta đi làm rõ Agile trong 3ngữ cảnh:

Agile đối với doanh nghiệp

Là khả năng doanh nghiệp nhanh nhạy ứng phó và uyển chuyển trong việc xử lý các biến động của thị trường và các vấn đề nội tại để đề ra chiến lược đúng đắn nhất

Agile đối với quản lý dự án

Là khả năng nhanh chóngthay đổi cách vận hành, cập nhật kế hoạch, xử lý rủi ro sớm, vận hành gọn nhẹvà liên tục phát hành sản phẩm nhằm tối đa hoá khả năng sản phẩm đáp ứng nhu cầu từ một thị trường sôi động

Agile đối với cá nhân

Là khả năng tự phủ định những kinh nghiệm, kỹ năng lỗi thời và sẵn sàng, khéo léo tự cải tiến bản thân nhằm đạt được mục tiêu cá nhân

Như vậy, Agile luôn gắn với một mục đích nào đó và làm sao để đạt được trình độ Agile như định nghĩa ở trên thì một tổ chức, cá nhân phải trải qua quá trình Agile Transformation màtôi sẽ trình bày trong những bài viết sau. Tôi cũng dự định có một bài viết đi sâu vào vấn đề Agile đối với quản lý dự án.

Sự hình thành và phát triển của Agile

Agile được định nghĩa vào năm 2001 trên 4 giá trị cốt lõi và 12 nguyên tắc vận hành.

Ban đầu, Agile được áp dụng cho lĩnh vực software nhưng sau đó, nhiều tổ chức thuộc tất cả các lĩnh vực đã áp dụng và công nhận họ được hưởng lợi ích từ Agile, bao gồm cả những lĩnh vực như: quốc phòng, nghiên cứu y khoa, nghiên cứu vũ trụ, thăm dò địa chất, dầu khí, etc.

Những lầm tưởng về Agile

1.Agile là process:

Đây là sai lầm cố hữu, thường thấy nhất ở mọi nơi và sai lầm này thường gắn với bộ phận PMO. Ở nhiều công ty, PMO lầm tưởng áp dụng các process a, b, c và tổ chức đẹp đẽ, tạo ra hệ thống tài liệu, hướng dẫntrên Confluence tầng tầng lớp lớp hay yêu cầu toàn bộ các nhóm phải "standup" vào mỗi sáng, phải chuẩn hoá dùng cùng một tài liệu, dùng cùng một hệ thống quản lý dự án như JIRA, Azure DevOps, etc. mới là Agile.

Cách hiểu này sai lầm vì càng thiết lập các process chi tiết, đẹp đẽ, to lớn thì càng khó thay đổi và vì vậy, nó không linh hoạt = không Agile.

2.Scrum là Agile

Đây là sai lầm thứ hai. Mười công ty muốn được Agile thì hết chín rưỡi công ty áp dụng Scrum. Sau khi các nhóm đã thực hành theo Scrum, họ nghĩ là họ đã Agile. Thực tế, Scrum là một framework để tạo ra nhiều cơ hội bỏ bớt những chi tiết rườm rà trong quản lý dự án, nó cũng tạo ra cơ hội để làm mọi thứ đơn giản và khuyến khích sự thay đổi.

Cách hiểu Scrum là Agile sai vì dù nếu áp dụng Scrum mà sản phẩm vẫn phải chờ nhiều tháng thậm chí cả năm mới phát triển xong, lại chờ thêm một thời gian để bộ phận QC kiểm định, rồi chờ bộ phận này duyệt, bộ phận kia roll out...thì Scrum đó là Scrum vẽ, không Agile chút nào.

3. SAFe là Agile

SAFe, giống như NEXUS, LESS, etc. là một framework nhằm giải quyết bài toán lớn của team of team of teams...ví dụ như những portfolio của nhiều programs của nhiều projects...cùng phát triển một sản phẩm.

Các framework này đều có chung một mục đích: Làm sao để chuẩn hoá, nhất quán hoá, quy ước hoá hoạt động của nhiều teams nhưng vẫn giữ lại sự linh hoạt và gọn nhẹ. Có thể nói, trong các frameworks dạng này SAFe làm điều đó kém nhất. Người ta nhìn vào SAFe và thấy đó là một rừng những processes, quy định, vai trò, tài liệu...rất hoàn hảo và đẹp đẽ. Như tôi đã nói, vì quá lớn, đẹp, hoàn hảo nên nó khó thay đổi, vì vậy, nó không Agile.

4. Áp dụng sprint, user story, story point estimating, etc. là Agile

Tương tự như việc áp dụng Scrum, nhiều nơi, người ta tin rằng chia công việc thành từng đoạn nhỏ và gọi nó là Sprint thì sẽ có được sự linh hoạt.

Cách hiểu này sai vì cho dù bạn chia ra nhiều sprint, bạn dùng story point để estimate mà bạn không linh hoạt trong hoạt động, team của bạn vẫn chẳng có quyền quyết định là sprint này họ sẽ làm những công việc gì, khối lượng bao nhiêu và sau vài sprints, team của bạn không cải tiến gì...thì không có chút gì là Agile cả.

5. Quản lý dự án Agile không có quản lý rủi ro

Thay vì có một tài liệu mấy trăm trang về quản lý tất cả rủi ro của sản phẩm, các thực hành của Agile đúng đắn chia nó ra thành từng phần nhỏ, dùng các công cụ tinh tế để phát hiện ra nó và xử lý rủi ro đócàng sớm càng tốt.

Agile quản lý rủi ro theo cách thích ứng với hoàn cảnh hơn là một chiến lược cứng nhắc.

6. Dự án Agile không có planning

Đây cũng là một trong những hiểu lầm thường thấy. Tuy nhiên, thay vì có một bản kế hoạch chi tiết cho hàng năm trời, được các cấp lãnh đạo phê duyệt và dựa trên đó để thực hiện. Agile chọn cách đưa ra một mục tiêu dài hạn, làm kế hoạch trung hạn, đi thực thi ngắn hạn và liên tục cập nhật kế hoạch ngắn hạn dựa trên các dữ liệu thu thập được trong quá trình thực thi. Từ đó, định kỳ cập nhật kế hoạch trung hạn và thách thứcmục tiêu dài hạn

Chưa kể, vấn đề estimate và plan trong Agile là cả một sự thú vị và khoa học mà nội dung của bài viết này không thể nói hết.

7. Dự án Agile không cần document

Thay vì tạo ra các tài liệu to lớn, đẹp đẽ, chi tiết vài trăm trang rồi để đó không ai muốn đọc tới. Chỉ vài tháng sau, hơn 50% nội dung trong document bị lỗi thời thì Agile khuyến khích viết từng phần đủ dùng, cập nhật ngay khi có thay đổi, xoá bớt nếu không còn dùng nữa và đảm bảo tài liệu luôn đồng hành với thực tế.

8. Dự án Agile không cần thiết kế architecture

Đây là cách hiểu của những người chỉ biết Agile qua sách vở. Bạn không thể xây nhà mà không có bản vẽ. Nhưng bạn không cần chờ cho đến khi có bản vẽ thiết kế nội thất chi tiết xong mới bắt đầu xây dựng. Chỉ cần bản vẽ kết cấu và bố cục hoàn tất, bạn đã có thể xây phần móng, song song với việc tiếp tục hoàn tất bản vẽ nội thất và tất nhiên, bạn không chờ toàn bộ căn nhà xây xong mới nghiệm thu. Bạn sẽ nghiệm thu từng phần và quay lại cập nhật bản vẽ khi cần thiết.

9. Agile giải quyết mọi vấn đề

Agile không giải quyết một vấn đề nào cả. Thay vào đó bằng cách chia vấn đề ra các bước nhỏ nhất, bỏ đi những chi tiết rườm rà, làm các quy trình trở nên tinh gọn, Agile giúp bạn dễ dàng nhìn thấy vấn đề và nhìn thấy vấn đề sớm. Bạn phải giải quyết vấn đề đó theo cách mà bạn thấy tối ưu nhất. Nói cách khác, Agile không giải quyết vấn đề cho bạn, nó quẳng vấn đề vào mặt bạn rất sớm và bạn phải giải quyết thôi.

10. Các dự án có thể được điều hành theo hướng Agile còn "giai cấp lãnh đạo" trong công ty thì không cần Agile

Hãy tưởng tượng một chiếc Ferrari chạy phía sau một chiếc xe ba gác trên một con đường hẹp và chiếc ba gác đó muốn chiếc Ferrari phải "đi theo tôi và chạy tốc độ tối đa"!

Pic source: Unknown