Có những dự án tương đối trực quan và dễ đoán, nơi các công cụ hợp lý của việc lập kế hoạch và ra quyết định có thể được áp dụng. Những dự án khác phức tạp hoặc khó đoán hơn yêu cầu một cách tiếp cận khác, dựa nhiều hơn vào tự tổ chức và sáng tạo.
Hầu hết các dự án phát triển phần mềm được coi là phức tạp và khó đoán do sự kết hợp của ba yếu tố: con người, yêu cầu và công nghệ. Các phương pháp tiếp cận khác nhau được sử dụng để giao và quản lý dự án có thể được hiểu dễ dàng hơn trong ngữ cảnh của các mô hình kiểm soát quy trình và độ phức tạp của dự án.
Quy Trình Được Định Nghĩa — Cách Tiếp Cận Truyền Thống Dựa Trên Kế Hoạch
Theo truyền thống, khi một dự án bắt đầu, một gói yêu cầu được tạo ra và sau đó được “phê duyệt”. Người quản lý dự án giả định rằng việc phê duyệt này dẫn đến một tập hợp các yêu cầu cố định và bây giờ việc lập kế hoạch có thể bắt đầu. Người quản lý dự án ước tính thời gian cần thiết để hoàn thành các yêu cầu và tạo ra kế hoạch dự án. Kế hoạch dự đoán rằng dự án sẽ hoàn thành vào một ngày cụ thể, và ngày đó được thông báo trở lại cho khách hàng.
Nhược điểm cơ bản của cách tiếp cận này là kế hoạch, điều kiện thúc đẩy mọi thứ, dựa trên giả định rằng các yêu cầu là cố định và sẽ không thay đổi. Kinh nghiệm đã chỉ ra rằng điều này không bao giờ xảy ra; các yêu cầu không bao giờ cố định — chúng luôn thay đổi. Khi các yêu cầu thay đổi, kế hoạch bị ảnh hưởng; và do đó, ngày hoàn thành cũng cần phải thay đổi. Thật không may, trong nhiều trường hợp, điều đó là không thể, và đội phải giao hàng vào ngày họ đã cam kết. Đây chính là lúc xảy ra khủng hoảng lớn và dự án bắt đầu mất kiểm soát.
Quy Trình Thực Nghiệm — Cách Tiếp Cận Linh Hoạt Dựa Trên Giá Trị
Cách tiếp cận linh hoạt dựa trên giá trị dựa trên chủ nghĩa thực nghiệm thay đổi hoàn toàn tư duy. Nó giả định ngay từ đầu rằng bất kỳ yêu cầu nào tồn tại ban đầu đều không cố định và chúng sẽ thay đổi.
Tư duy linh hoạt cũng giả định rằng bạn phải giao hàng vào một ngày cụ thể. Cách tiếp cận này cố định thời gian và tài nguyên và để các yêu cầu không xác định. Đối với chúng tôi, cách tiếp cận này gần với thực tế của việc tạo phần mềm hơn. Bây giờ, toàn bộ khái niệm dựa trên giá trị trở nên hoàn toàn hợp lý. Khi bạn có một khoảng thời gian cố định mà bạn không chắc liệu có thể giao tất cả các yêu cầu hay không (vì chúng sẽ thay đổi và do đó thời gian cần thiết để hoàn thành chúng cũng sẽ thay đổi), phản ứng tự nhiên là ưu tiên các yêu cầu và hoàn thành trước những yêu cầu mang lại giá trị nhất cho khách hàng.
Bạn có thể nghĩ, “Vậy các yêu cầu không hoàn thành trước ngày giao hàng thì sao?” Đó chính là lý do tại sao bạn sử dụng cách tiếp cận dựa trên giá trị. Bạn thừa nhận rằng không phải tất cả các yêu cầu đều sẽ hoàn thành vào ngày giao hàng. Câu hỏi quan trọng cần đặt ra là liệu bạn đã giao đủ các tính năng để hỗ trợ một hệ thống mang lại giá trị cho khách hàng hay chưa.
Tỷ Lệ Thất Bại của Các Dự Án Phần Mềm
Báo cáo CHAOS năm 2015 đã được phát hành gần đây bởi nhóm Standish. Các Báo cáo CHAOS đã được xuất bản hàng năm kể từ năm 1994 và là bức tranh về tình trạng ngành phát triển phần mềm. Báo cáo năm nay đã nghiên cứu 50.000 dự án trên toàn thế giới, từ những cải tiến nhỏ đến các triển khai tái cơ cấu hệ thống lớn. Báo cáo năm nay bao gồm định nghĩa mở rộng về thành công, xem xét một số yếu tố bổ sung đã được đề cập trong các khảo sát trước đó.
Kết quả cho thấy vẫn còn nhiều việc cần làm để đạt được kết quả thành công từ các dự án phát triển phần mềm. Bảng tóm tắt này tổng hợp kết quả của các dự án trong năm qua sử dụng định nghĩa mới về các yếu tố thành công (đúng tiến độ, đúng ngân sách với kết quả thỏa đáng).
Với việc áp dụng các phương pháp phát triển linh hoạt trong những năm gần đây, có thể so sánh kết quả dự án giữa các dự án linh hoạt và dự án thác nước truyền thống. Trên tất cả các quy mô dự án, cách tiếp cận linh hoạt dẫn đến nhiều dự án thành công hơn và ít thất bại hoàn toàn hơn, như được thể hiện trong bảng này.
Vấn Đề Của Cách Tiếp Cận Truyền Thống Là Gì?
Cách tiếp cận truyền thống dựa trên kế hoạch không phải là không hoàn hảo, nhưng nó không phù hợp với ngành công nghiệp phần mềm ngày nay. Cách tiếp cận dựa trên kế hoạch ban đầu dựa trên các khái niệm quản lý dự án truyền thống, bắt nguồn từ ngành xây dựng. Trong ngành xây dựng, cách tiếp cận dựa trên kế hoạch là phù hợp: các bản vẽ kiến trúc, tức là các yêu cầu, là cố định và có thể không thay đổi trong quá trình xây dựng. Bạn có thể ước tính thời gian cần thiết để xây dựng các cột thép, đổ bê tông, v.v.
Lý do tại sao cách tiếp cận truyền thống dựa trên kế hoạch phù hợp với ngành xây dựng nhưng không phù hợp với ngành phần mềm quay trở lại sự khác biệt trong cách chúng ta kiểm soát các hệ thống thực nghiệm (như phát triển phần mềm) và cách chúng ta kiểm soát các hệ thống được định nghĩa (như xây dựng hoặc sản xuất). Bảng dưới đây cho thấy sự khác biệt giữa các đặc điểm của quy trình được định nghĩa và quy trình thực nghiệm.
Sau khi đọc bảng, dễ dàng nhận thấy rằng phát triển phần mềm chắc chắn là một quy trình thực nghiệm, không phải quy trình được định nghĩa. Vấn đề là chúng ta đã tiếp cận phát triển phần mềm trong nhiều năm như một quy trình được định nghĩa — và cách tiếp cận đó không hoạt động.
Tài Liệu Tham Khảo
- Báo Cáo CHAOS 2015 của Nhóm Standish
- Trở Nên Linh Hoạt Trong Một Thế Giới Không Hoàn Hảo — bởi Greg Smith & Ahmed Sidky
Các Tài Liệu Khác Về Scrum
- Scrum Trong 3 Phút
- 5 Giá Trị Của Scrum Là Gì?
- Sự Tiến Hóa Của Scrum Là Gì?
- Quản Lý Dự Án Truyền Thống So Với Quản Lý Dự Án Linh Hoạt
- Tại Sao Scrum Khó Làm Chủ?
- Tốc Độ Trong Scrum Là Gì?
- Agile Là Gì? Scrum Là Gì?
This post is also available in Deutsch, English, Español, فارسی, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, 简体中文 and 繁體中文.