Agile là một triết lý quản lý dự án, ra đời từ Tuyên ngôn Agile (Agile Manifesto) năm 2001 của một nhóm chuyên gia phát triển phần mềm, ưu tiên phản hồi nhanh với thay đổi và giao sản phẩm từng phần liên tục, thay vì cố định toàn bộ kế hoạch chi tiết ngay từ đầu rồi làm đúng theo kế hoạch đó tới cuối. Nhận định của bài: Agile không phải một quy trình cụ thể có các bước làm sẵn, mà là một tập giá trị định hướng cách ra quyết định; Scrum, Kanban là những khung làm việc cụ thể áp dụng triết lý Agile, không phải Agile tự nó là một quy trình duy nhất áp dụng chung cho mọi đội ngũ.
Bốn giá trị cốt lõi của Agile
| Ưu tiên hơn | So với |
|---|---|
| Con người và tương tác | Quy trình và công cụ |
| Phần mềm chạy được | Tài liệu đầy đủ, chi tiết |
| Hợp tác với khách hàng | Đàm phán hợp đồng cứng nhắc |
| Phản hồi với thay đổi | Bám sát kế hoạch ban đầu |
Cách đọc đúng bảng trên: Agile không phủ nhận quy trình, tài liệu, hợp đồng hay kế hoạch là không cần thiết, chỉ là đặt các giá trị bên trái lên ưu tiên cao hơn khi hai bên xung đột nhau.
Vì sao doanh nghiệp thuê làm phần mềm nên hiểu Agile trước khi ký hợp đồng
Nếu một hợp đồng phần mềm được thi công theo Agile, yêu cầu ban đầu trong hợp đồng thường chỉ là khung tổng quát, chi tiết cụ thể sẽ được làm rõ dần trong quá trình làm việc qua các buổi trao đổi định kỳ. Doanh nghiệp cần chuẩn bị tinh thần tham gia góp ý thường xuyên trong suốt dự án, thay vì chỉ ký một bản đặc tả đầy đủ rồi đợi tới ngày bàn giao mới xem sản phẩm, vì cách làm đó lệch với chính triết lý Agile mà đơn vị thi công đang áp dụng.
Kanban: một khung làm việc Agile khác, không chia theo sprint cố định
Bên cạnh Scrum, Kanban là một khung làm việc Agile phổ biến khác, khác ở chỗ không chia công việc theo các chu kỳ sprint cố định thời gian, mà quản lý công việc liên tục qua một bảng trực quan chia thành các cột (ví dụ: cần làm, đang làm, đã xong), mỗi công việc là một thẻ di chuyển dần qua các cột đó. Kanban phù hợp với những đội có luồng công việc phát sinh liên tục, không đều đặn theo chu kỳ, ví dụ đội hỗ trợ kỹ thuật xử lý yêu cầu khách hàng hằng ngày, trong khi Scrum phù hợp hơn với các dự án có thể lên kế hoạch trước theo từng đợt tính năng cụ thể. Một số đội kết hợp cả hai, dùng sprint để lên kế hoạch tổng thể nhưng theo dõi tiến độ hằng ngày bằng bảng kiểu Kanban.
Áp dụng Agile một phần, không nhất thiết phải làm trọn vẹn ngay từ đầu
Một đội hoặc doanh nghiệp mới làm quen với Agile không cần áp dụng toàn bộ các thực hành cùng lúc ngay từ dự án đầu tiên. Có thể bắt đầu từ những thay đổi nhỏ, dễ áp dụng nhất, như tổ chức các buổi trao đổi ngắn định kỳ để cập nhật tiến độ, hoặc chia công việc lớn thành các phần nhỏ hơn để giao từng đợt thay vì dồn hết vào cuối dự án, rồi mở rộng dần sang các thực hành phức tạp hơn khi đội đã quen với cách làm việc mới. Cố gắng áp dụng đầy đủ mọi nghi thức của Scrum ngay từ đầu, khi cả đội chưa quen, đôi khi phản tác dụng, khiến các buổi họp trở thành hình thức thay vì thực chất mang lại giá trị.
Đo lường hiệu quả khi áp dụng Agile, tránh chỉ làm theo hình thức
Một rủi ro khi áp dụng Agile là đội chỉ làm đúng hình thức (tổ chức đủ các buổi họp, dùng đúng thuật ngữ) mà không thực sự đạt được giá trị cốt lõi là phản hồi nhanh và cải thiện liên tục. Để tránh điều này, nên theo dõi một vài chỉ số cụ thể qua thời gian: tốc độ hoàn thành công việc mỗi chu kỳ có ổn định hay ngày càng chậm, số lượng vấn đề phát hiện muộn (sau khi đã làm xong một phần lớn công việc) có giảm dần không, và mức độ hài lòng của khách hàng hoặc người đại diện doanh nghiệp sau mỗi lần xem sản phẩm có cải thiện theo thời gian hay không. Những chỉ số này giúp phân biệt một đội đang thực sự hưởng lợi từ Agile với một đội chỉ đang làm đúng thủ tục bề ngoài. Doanh nghiệp thuê ngoài làm phần mềm hoàn toàn có quyền hỏi đơn vị thi công về các chỉ số này định kỳ, thay vì chỉ nhận báo cáo chung chung rằng dự án đang chạy đúng theo quy trình Agile, vì bản thân việc gọi tên đúng quy trình không đảm bảo giá trị thực chất đã đạt được cho công việc kinh doanh của doanh nghiệp đang bỏ tiền ra thuê đội phát triển làm việc theo đúng quy trình đó mỗi ngày, tuần này qua tuần khác.
Câu hỏi thường gặp
Agile và Scrum khác nhau ở đâu?
Agile là triết lý, tập giá trị chung. Scrum là một khung làm việc cụ thể (có vai trò, sự kiện, tài liệu rõ ràng) áp dụng triết lý Agile vào thực tế, và là khung phổ biến nhất.
Agile chỉ dùng được cho dự án phần mềm thôi sao?
Agile ra đời từ ngành phần mềm nhưng các giá trị của nó, như ưu tiên phản hồi nhanh và hợp tác với khách hàng, cũng được áp dụng ở một số lĩnh vực khác như marketing, phát triển sản phẩm nói chung.
Dự án theo Agile có kế hoạch và thời hạn cố định không?
Vẫn có, nhưng kế hoạch chi tiết được điều chỉnh linh hoạt theo từng chu kỳ ngắn thay vì cố định toàn bộ ngay từ đầu; thời hạn tổng thể của dự án vẫn có thể thoả thuận trong hợp đồng.
Kanban và Scrum, đội mới bắt đầu nên chọn khung nào?
Nếu công việc có thể lên kế hoạch theo từng đợt tính năng rõ ràng, Scrum thường dễ bắt đầu hơn nhờ cấu trúc vai trò và sự kiện cụ thể; nếu công việc phát sinh liên tục, không đều, Kanban đơn giản và linh hoạt hơn để bắt đầu.
Doanh nghiệp có thể yêu cầu đơn vị thi công đổi từ mô hình thác nước sang Agile giữa chừng không?
Về mặt kỹ thuật là có thể, nhưng việc chuyển đổi giữa chừng thường phát sinh thêm chi phí và thời gian điều chỉnh lại kế hoạch, quy trình làm việc; nên trao đổi rõ mô hình quản lý dự án ngay từ khi ký hợp đồng để tránh phải đổi giữa chừng.
