Tránh thất bại dự án phần mềm
Một sinh viên hỏi: Tại sao nhiều dự án phần mềm thế bao giờ cũng trễ hay thất bại? Nếu kĩ nghệ yêu cầu là quan trọng thì tại sao nó KHÔNG được dạy trong trường? Tại sao nó thậm chí KHÔNG được dạy trong môn quản lí dự án?
Đáp: Lí do then chốt mà phần lớn dự án phần mềm bị chậm là vì thay đổi trong yêu cầu phần mềm và ước lượng dự án sai. Lí do khách hàng giữ thay đổi yêu cầu vì việc thu thập kém các yêu cầu trước khi bắt đầu dự án. Nhiều người quản lí dự án phần mềm cũng không coi tính hợp thức của yêu cầu của khách hàng là một phần việc làm của họ và chấp nhận các yêu cầu mà không phân tích thêm. Lí do khác có thể gây ra vấn đề lịch biểu là người phát triển muốn “hoàn thiện” bất kì cái gì họ làm. Nhiều người thêm các mã phụ không phải là một phần của yêu cầu gốc để làm cho nó “tốt hơn” mà không xét với tác động lên dự án. Nhiều người viết mã và viết lại mã của họ nhiều lần cho tới khi họ cảm thấy thoả mãn với nó. Những điều này tiêu tốn nhiều thời gian và nỗ lực và làm cho dự án bị trễ.
Kĩ nghệ yêu cầu chủ yếu được dạy trong trường có chương trình Kĩ nghệ phần mềm. Bởi vì đào tạo quản lí dự án thường bắt đầu với đặc tả yêu cầu phần mềm (SRS) đã được làm tài liệu cho nên thu được yêu cầu KHÔNG thuộc phạm vi của chúng. Đào tạo khoa học tính toán giả định rằng khách hàng sẽ viết yêu cầu cho nên người phát triển phần mềm sẽ bắt đầu công việc của họ với các yêu cầu phần mềm đã có tại chỗ. Lúc bắt đầu của dự án, có danh sách các yêu cầu với ngân sách tương ứng (chi phí), con người (tài nguyên), và lịch biểu (thời gian). Do đó bất kì thay đổi nào về yêu cầu mà không thay đổi về chi phí, tài nguyên và thời gian đều sẽ ảnh hưởng tới dự án. Không may, nếu các yêu cầu KHÔNG được xác định tốt, khách hàng sẽ phải thêm hay thay đổi yêu cầu sau khi dự án bắt đầu nhưng họ thường KHÔNG cho phép thay đổi trong chi phí, thời gian hay tài nguyên. Nhiều người quản lí dự án phần mềm không biết cách thương lượng trong thay đổi yêu cầu và chấp nhận nó mà không nghĩ về rủi ro cho dự án.
Người quản lí dự án giỏi có thể tránh được thay đổi yêu cầu bởi:
- Đưa khách hàng và người dùng tham gia sớm vào trong dự án.
- Phân tích kĩ lưỡng các yêu cầu trong lúc bắt đầu dự án để chắc chắn chúng đầy đủ, được làm tài liệu tốt và đáp ứng nhu cầu của khách hàng.
- Thiết lập tổ cho Ban kiểm soát thay đổi (CCB) để đánh giá rủi ro của việc thực hiện thay đổi trước khi chấp nhận chúng.
- Đưa mọi khác hàng tham gia vào mọi pha của dự án (đặc biệt trong pha lập kế hoạch).
- Đưa ra tăng dần phần mềm. Dừng các yêu cầu thêm hay trì hoãn thực hiện chúng cho tới lần đưa ra tiếp.
- Dùng cách tiếp cận Agile (nếu dự án nhỏ) như SCRUM. Danh mục sản phẩm (phạm vi) là động và sẽ thay đổi trong toàn bộ vòng đời phát triển phần mềm chừng nào khách hàng còn cảm thấy rằng những thay đổi đó là quan trọng và chấp nhận trách nhiệm về chúng bằng việc cho phép thêm thời gian.
Tác phẩm, tác giả, nguồn
- Tác phẩm: Quản lý dự án
- Nguồn: Blog của giáo sư John Vu, Carnegie Mellon University.
- Wiki hóa: https://kipkis.com
