Mục đích thật sự của Agile

Khi được hỏi “Tại sao các bạn muốn áp dụng Agile?” và tôi nhận được rất nhiều câu trả lời khác nhau. Tuy nhiên, có một số phản hồi điển hình như: “Chúng tôi muốn đi nhanh hơn”, “Áp dụng Agile giúp chúng tôi tăng năng suất/hiệu suất làm việc” hay “Vì đối thủ của chúng tôi đang áp dụng Agile”....Vậy, đâu mới là mục đích thật sự của Agile

Vì quá nhiều những diễn giải sai lệch và sự hiểu lầm về “định nghĩa Agile” và “Agile được thực hiện như thế nào” được lan truyền, nên có lẽ “Agile có ý nghĩa thế nào” hay mục đích thật sự của Agile trở nên khó nhận thấy nhất. 

Tôi vẫn luôn hỏi các khách hàng tiềm năng của mình là “Tại sao các bạn muốn áp dụng Agile?” và tôi nhận được rất nhiều câu trả lời khác nhau. Tuy nhiên, có một số phản hồi điển hình như: “Chúng tôi muốn đi nhanh hơn”, “Áp dụng Agile giúp chúng tôi tăng năng suất/hiệu suất làm việc” hay “Vì đối thủ của chúng tôi đang áp dụng Agile”. Những câu trả lời kiểu này giúp tôi biết được, sự tương tác đang diễn ra như nó phải là và công việc huấn luyện được bắt buộc thực hiện - và nó không liên quan gì nhiều đến việc huấn luyện các lập trình viên (developers) đi nhanh hơn, làm việc năng suất hơn hay thực hiện cùng một cách làm việc mà họ đã làm tại công ty x nào đó. 

Đi nhanh hơn...

Các tác giả của bản Tuyên ngôn Phát triển Phần mềm Agile đã chọn từ “agile – nghĩa là linh hoạt” chứ không phải từ “speed – tốc độ”. Việc “đi nhanh hơn” chỉ là một tác dụng phụ hữu ích của sự linh hoạt, nhưng không phải là mục đích chính. Đúng là thuật ngữ “agile” có ngụ ý về yếu tố tốc độ nhưng là về khả năng đổi hướng một cách nhanh chóng.

Việc đi nhanh hơn một cách mù quáng thực sự có thể khiến mọi thứ trở nên tồi tệ hơn; thử tưởng tượng bạn đang trên một chuyến đi bằng ô tô, và nó giúp bạn đi nhanh hơn nhưng bạn không nhận ra rằng mình đang đi sai hướng. Đây là lúc mà tính minh bạch (transparency) và vòng lặp phản hồi (feedback loops) vốn có trong các quy trình của Agile trở nên quan trọng. Tính minh bạch được thể hiện trong tiến độ thực tế, tình trạng của công việc cũng như những thách thức trong quá trình làm việc. Vòng lặp phản hồi là cơ hội để kiểm tra những tạo tác (artifacts) nhằm thể hiện sự minh bạch này và thực hiện những điều chỉnh một cách nhanh chóng và dễ dàng như ẩn dụ việc chuyển hướng đi trong chuyến du lịch được nói đến ở trên . 

Tăng năng suất/hiệu suất làm việc…

Thông thường, ý nghĩa của việc “tăng năng suất” là mong muốn có thể nhận được nhiều hơn với nguồn lực không đổi (hoặc thậm chí ít hơn). Tăng hiệu suất là mong muốn giảm thiểu hoặc loại bỏ lãng phí. Với cả hai trường hợp, chủ yếu tập trung vào kết quả, muốn đạt được nhiều hơn với chi phí thấp hơn. Trong Agile, bạn có thể tăng hiệu suất nhưng chưa chắc đạt được kết quả như mong muốn. Mục đích của Agile là tăng hiệu quả. Các quy trình của Agile liên quan đến việc giao tiếp và hợp tác giữa các lập trình viên (developers) và các bên liên quan (stakeholders) nhằm hiểu rõ các vấn đề cần giải quyết.  Cũng giống như trong một chuyến đi như ví dụ trên, bạn phải thường xuyên chú ý và phản hồi thông tin để chắc chắn mình đang đi đúng hướng. Nỗ lực này được phản ánh qua công việc thường làm và thử nghiệm những cải tiến mới. Tất cả việc này có thể được xem là giảm hiệu suất công việc vì mọi người ít tập trung vào công việc hữu hình, thực hành “năng suất”. Những căng thẳng kịch liệt có thể nảy sinh giữa những người áp dụng tư duy Agile để cải thiện hiệu quả, trong khi số khác hoàn toàn tìm cách tăng năng suất và hiệu suất theo ý nghĩa truyền thống.

Trong sản xuất, một chiến lược hiệu quả giúp giảm lãng phí là giảm thiểu thời gian nhàn rỗi của công nhân hoặc máy móc. Tuy nhiên, điều này lại không phù hợp khi giải quyết các vấn đề phức tạp như phát triển phần mềm, bán hàng, tiếp thị (marketing) – những lĩnh vực mà hầu hết các phương pháp Agile được thiết kế để sử dụng và phát triển mạnh. Nguyên tắc thứ 10 trong bản Tuyên ngôn Agile nêu rõ “Đơn giản - nghệ thuật tối đa hóa số lượng công việc không làm - là điều cần thiết.” Với tư duy Agile, để đạt hiệu suất và tránh lãng phí, ta cần giảm thiểu tối đa những công việc có giá trị thấp hoặc không có giá trị, đồng thời xác định những công việc nào có giá trị và những công việc nào không có giá trị càng sớm càng tốt. 

Vì đối thủ của chúng tôi đang áp dụng Agile…

Một số tổ chức lựa chọn áp dụng Agile chỉ đơn giản vì họ thấy các đối thủ cạnh tranh của mình đang làm điều đó. Trong những tình huống này, hiếm khi có mong muốn áp dụng một tư duy và văn hóa mới hay có động lực để thay đổi thực sự. Một mô hình phổ biến là áp dụng các tên gọi mới (Giám đốc Dự án – Project Manager được đổi tên thành Scrum Master, Chuyên viên Phân tích Nghiệp vụ Kinh doanh – Business Analysts đổi thành Product Owner, v.v.) và thực tế có rất ít sự thay đổi diễn ra với rất ít lợi ích của Agile có thể nhận thấy. Chưa kể nếu có sự thay đổi, tình hình cũng có thể trở nên tồi tệ hơn khi những mô hình trước đó đã không còn mà kỷ luật của mô hình Agile thì vẫn chưa có.
 
Vậy tại sao chúng ta lại áp dụng Agile?

Việc áp dụng Agile sẽ thật sự trở nên tồi tệ hơn nếu lý do chúng ta thay đổi nằm trong số các lý do vừa kể trên. Vì thế, tôi sẽ đưa ra những lý do chính đáng để bắt tay vào việc áp dụng Agile và hiểu mục đích thật sự của Agile là gì.

Khi một tổ chức nhận ra rằng họ đang phải đối mặt với những vấn đề phức tạp và tương lai là những điều chưa biết. Khi có mong muốn thay đổi để trở thành một tổ chức liên tục học hỏi và cải tiến; tìm hiểu về chỗ có vấn đề, khách hàng và tổ chức nhằm hiểu rõ hơn về chính mình. Cởi mở để tìm ra những sự thật đau lòng với mục đích cải thiện mọi công việc mà tổ chức đã/đang thực hiện.

Những lý do trên khiến việc áp dụng Agile trở nên dễ dàng. Tuy nhiên, việc áp dụng đúng tư duy Agile thực sự có thể mang đến những tác động mạnh mẽ. Cho dù là áp dụng mô hình Scrum, Kanban, XP, Lean Startup hay bất kỳ “framework” Agile nào khác, điểm mấu chốt vẫn là chuyển giao giá trị theo cấu trúc lặp đi lặp lại xoắn ốc và tăng dần để có phản hồi thường xuyên và nhận ra giá trị.  Điều này cũng đồng thời thách thức tổ chức trong việc phát hiện và đối phó với những trở ngại ngăn cản tổ chức thực hiện, và xác định đúng hướng đi của mình.

 

Lược dịch: Trần Lan Atoha

NguồnThe Purpose of being Agile

 

Bản tuyên ngôn Agile - lịch sử hình thành Agile

Trong dự án Agile, công việc ước tính có thật sự cần thiết?

12 nguyên tắc của Agile

Quản lý dự án với Scrum

Scrum of Scrums


Cũ hơn Mới hơn


Thông tin liên hệ

Thông tin chuyển khoản
Công ty Cổ phần ATOHA. Ngân hàng Á Châu (ACB). Số tài khoản: 6868 2468, PGD Tân Sơn Nhì, TPHCM.
Đăng ký khóa học
Chọn khóa học phù hợp bằng cách điền thông tin như link bên dưới. Tư vấn viên Atoha sẽ liên hệ anh/chị ngay.
Câu hỏi thường gặp

“Có. Atoha sẽ có chứng nhận hoàn thành chương trình đào tạo dành cho học viên và cung cấp 35 giờ đào tạo bắt buộc (1 trong 3 điều kiện thi lấy chứng chỉ PMP quốc tế)."

“Cả 2. Tài liệu có thể là tiếng Anh hoặc tiếng Việt tùy vào lớp. Atoha có thể đào tạo bằng cả tiếng Anh hoặc tiếng Việt."

“Chưa bao gồm. Học viên sẽ cần đóng phí thi trực tiếp cho viện PMI nếu muốn đăng ký thi, phí thi tham khảo như sau: 389 USD/non-member và 393 USD/member (trong đó phí thành viên PMI là 99 USD, phí admin là 10 USD, phí thi PMP là 284 USD). Chi phí này dành cho một số khu vực, trong đó có Việt Nam. Tham khảo thêm tại: www.pmi.org"

Liên hệ ngay với Atoha để được tư vấn về chương trình phù hợp