So sánh truyền thống và quản lý dự án Agile: Những điểm khác biệt chính và giải thích về tam giác sắt

Quản lý dự án truyền thống

Phương pháp quản lý dự án truyền thống (mô hình thác nước) là tuyến tính, trong đó tất cả các giai đoạn của quá trình diễn ra theo thứ tự. Phương pháp này dựa vào các công cụ có thể dự đoán được và kinh nghiệm có thể dự đoán được. Mỗi dự án tuân theo chu kỳ sống giống nhau, bao gồm các giai đoạn khả thi, lập kế hoạch, thiết kế, xây dựng, kiểm thử, sản xuất và hỗ trợ, như được minh họa trong hình bên dưới.

Phát triển phần mềm thác nước so với Agile

Toàn bộ dự án được lên kế hoạch trước với không có chỗ cho sự thay đổi về yêu cầu — giống như mô hình thác nước, PMBOK của PMI và PRINCE2 là cứng nhắc và được kiểm soát chặt chẽ. Chúng xác định rõ các giai đoạn từ đầu đến cuối và giả định rằng bạn đã có đầy đủ các yêu cầu và thông tin cần thiết.

Phương pháp này giả định thời gian và chi phí là các biến số, trong khi yêu cầu là cố định — chính vì vậy, quản lý dự án truyền thống thường gặp khó khăn với các vấn đề về ngân sách và tiến độ.

Quản lý dự án Agile

Trong khi các hệ thống truyền thống tập trung mạnh vào lập kế hoạch ban đầu, các yếu tố như chi phí, phạm vi và thời gian là rất quan trọng. Ngược lại, Agile nhấn mạnh vào tinh thần làm việc nhóm, hợp tác với khách hàng và tính linh hoạt.

Agile từ chối quản lý dự án truyền thống vì nó nhàm chán, gò bó và không phù hợp với thế giới hiện đại tốc độ cao. Quản lý dự án Agile là theo vòng lặp, nhằm tích hợp liên tục phản hồi từ người dùng và các bản phát hành liên tục trong mỗi vòng phát triển, như minh họa ở trên. Mỗi đầu ra công việc là một sản phẩm bạn bán cho các bên liên quan. Các nhóm và quy trình làm việc được tổ chức xung quanh việc tạo ra những thứ có ích trực tiếp cho khách hàng.

Truyền thống hay Agile – Làm thế nào để lựa chọn?

Theo Báo cáo CHAOS năm 2011 của nhóm Standish, các dự án Agile thành công gấp ba lần so với các dự án thác nước. Biểu đồ bên dưới cho thấy kết quả cụ thể từ các nghiên cứu được thực hiện giữa năm 2002 và 2012:

Tỷ lệ thành công của các dự án thác nước so với Agile

Sự khác biệt giữa truyền thống và Agile

Bảng bên dưới tóm tắt nhiều điểm khác biệt quan trọng giữa mô hình Scrum và quản lý dự án truyền thống.

Chi phí thay đổi

Truyền thống, các thay đổi trong các dự án phần mềm thường bị tránh vì chi phí sẽ tăng đáng kể ở giai đoạn sau của dự án. Phát triển phần mềm Agile nhận thức rằng thay đổi là điều không thể tránh khỏi và việc đầu tư nặng vào lập kế hoạch ban đầu là không thực tế. Điều này được thể hiện rõ ràng trong một trong bốn giá trị của Bản Tuyên ngôn Agile:

“Phản ứng với các yêu cầu thay đổi hơn là tuân theo một kế hoạch cố định.”

Agile thách thức quan niệm này và cho rằng chi phí thay đổi có thể tương đối ổn định, như được minh họa trong hình bên dưới:

Chi phí thay đổi trong truyền thống so với Agile

Agile so với Tam giác sắt truyền thống trong quản lý dự án

Thành công trong quản lý dự án truyền thống thường được liên kết với khả năng quản lý các giới hạn về phạm vi, thời gian, chi phí và chất lượng, như được minh họa trong hình bên dưới. Đây là một ẩn dụ phổ biến cho thấy các nhà quản lý dự án được kỳ vọng phải cân bằng các giới hạn này một cách hợp lý.

Tam giác sắt trong Agile so với quản lý dự án truyền thống

Vấn đề gì với Tam giác Sắt truyền thống?

Ví dụ, một dự án có thể được hoàn thành nhanh hơn bằng cách tăng ngân sách hoặc giảm phạm vi. Tương tự, mở rộng phạm vi thường đòi hỏi sự gia tăng tương ứng về ngân sách và thời gian. Cắt giảm ngân sách mà không điều chỉnh thời gian hoặc phạm vi sẽ dẫn đến suy giảm chất lượng. Tuy nhiên, trong thực tế, việc thỏa hiệp giữa các giới hạn không phải lúc nào cũng khả thi. Ví dụ, đầu tư thêm nguồn lực (và nhân lực) vào một dự án đã có nguồn lực dồi dào có thể thực sự làm chậm tiến độ. Hơn nữa, trong các dự án hoạt động kém hiệu quả, việc cải thiện ngân sách, tiến độ hoặc phạm vi mà không làm ảnh hưởng tiêu cực đến chất lượng thường là điều không thể.

Do đó, Tam giác Sắt truyền thống rõ ràng là không đủ để làm mô hình cho thành công dự án, vì nó bỏ qua các yếu tố then chốt của thành công, bao gồm tác động đến bên liên quan, quá trình học hỏi và sự hài lòng của người dùng.

Tam giác Sắt Agile – Một bước chuyển đổi mô hình

Trong cách tiếp cận truyền thống, tam giác thường trông giống như hình bên trái được hiển thị dưới đây. Như bạn có thể thấy, các yêu cầu sản phẩm có phạm vi cố định. Do đó, để đảm bảo sản phẩm cung cấp đầy đủ các tính năng yêu cầu, chúng ta cần sự linh hoạt về nguồn lực (và ngân sách) và thời gian (thời hạn). Nếu chúng ta tuyệt đối cần sản phẩm phải bao gồm toàn bộ danh sách tính năng được mô tả trong tài liệu yêu cầu ban đầu, chúng ta có thể cần hoãn ngày phát hành đến vài tháng hoặc hơn.

Trong ý nghĩa Agile, thời gian là cố định (trong Scrum, điều này đạt được thông quathời gian cố định Sprintvà nguồn lực cố định). Do đó, khi các việc không diễn ra như kế hoạch, phạm vi phải được giảm. Nhưng trong Agile, chúng tôi đảm bảo rằng ngay cả khi phải thỏa hiệp về phạm vi, chúng tôi vẫn giao các mục ưu tiên cao nhất từ danh sáchDanh sách Sản phẩmđể tối đa hóa giá trị tạo ra bởi dự án.

Tam giác Sắt trong bối cảnh Agile