Để xây dựng một dự án Agile thành công, mỗi doanh nghiệp hay cá nhân cần hiểu rõ định nghĩa về Agile để nhanh nhạy áp dụng và xử lý các rủi ro nhằm tối đa hóa khả năng đáp ứng nhu cầu thị trường cũng như các mục tiêu cá nhân... (tìm hiểu thêm tại đây). Theo anh Minh Tuệ - Head of Agile PMO, VNGGames, VNG, trong quá trình Agile Transformation chúng ta sẽ gặp phải 10 lầm tưởng về Agile có thể gây ảnh hưởng đến dự án:

 

1. Agile là một quy trình?

Đây là sai lầm thường thấy ở mọi nơi và gắn nhiều nhất với phòng quản lý dự án (Project Management Office - PMO). Ở nhiều công ty, PMO lầm tưởng áp dụng các quy trình a, b, c và tổ chức đẹp đẽ, tạo ra hệ thống tài liệu, nhiều tầng hướng dẫn trên Confluence hay 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,... mới là Agile.

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

 

2. Scrum cũng là Agile?

Nhiều công ty muốn được Agile thì á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 là sai vì dù nếu áp dụng Scrum mà sản phẩm vẫn phải chờ nhiều tháng hay 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 thực tế - tương đương với không Agile.

 

3. SAFe là Agile?

SAFe giống như NEXUS, LESS,... là một framework nhằm giải quyết bài toán lớn của nhiều nhóm liên quan nhau… 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 nhóm 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 thì 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 quy trình, quy định, vai trò hay tài liệu. Vì quá hoàn hảo nên nó khó thay đổi, vì vậy không Agile.

 

4. Áp dụng Sprint, User Story, Story Point Estimating,... 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 để ước tính nhưng lại không linh hoạt trong hoạt động, nhóm của bạn vẫn không thể quyết định là Sprint này sẽ làm những công việc gì, khối lượng bao nhiêu và sau vài Sprints, team không có cải tiến mới… thì tương đương với không Agile.

 

5. Quản lý dự án Agile mà 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 đúng đắn của Agile chia nó ra thành từng phần nhỏ, dùng các công cụ tinh tế để phát hiệ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ó kế hoạch

Đâ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 cả năm, được các cấp lãnh đạo phê duyệt và dựa trên đó để thực hiện thì 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ức mục tiêu dài hạn.

 

7. Dự án Agile không cần tài liệu?

Thay vì tạo ra các tài liệu chi tiết vài trăm trang hay hơn 50% nội dung trong tài liệu bị lỗi thời chỉ vài tháng sau 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 theo lý thuyết về Agile. 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ó chỉ đưa vấn đề đến trước bạn rất sớm và bạn sẽ 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"!. Để áp dụng Agile hiệu quả trong doanh nghiệp, mỗi thành viên phải có những hiểu biết cơ bản về phương pháp này và áp dụng vào chính công việc của mình để thích nghi dần, từ đó tạo ra hiệu suất quản lý tối đa.

 

(Nguồn: Freepik)

 

Hiện tại, Agile đang đóng vai trò quan trọng trong cách thức quản lý dự án của nhiều sản phẩm công nghệ. Bằng cách tăng cường sự tương tác giữa các thành viên trong nhóm, quản lý tốt các phản hồi của khách hàng và thử nghiệm những ý tưởng mới, đội ngũ có thể tiếp tục tận dụng nâng cao hiệu quả và thành công mang đến sản phẩm đáp ứng nhu cầu của thị trường.

 

• Nội dung được đóng góp bởi anh TueDNM, Head of Agile PMO, VNGGames, VNG.
• Nếu bạn muốn gia nhập đội ngũ VNG, xem ngay các vị trí mở tuyển tại đây