Thác đổ và phát triển lặp
Một sinh viên viết cho tôi: “Khi nào chúng em dùng Thác đổ và khi nào chúng em dùng cách tiếp cận lặp? Làm sao chúng em chọn được cách nào là tốt nhất cho dự án phần mềm?”
Đáp: Cả hai cách tiếp cận này đều tuân theo qui trình được xác định rõ với các chi tiết xác định. Bạn lựa chọn cách tiếp cận thác đổ khi yêu cầu được hiểu rõ và dự án phải tuân theo qui tắc và qui chế nào đó (như dự án mấu chốt lớn hay dự án của chính phủ) nơi nó yêu cầu mức độ chất lượng và tài liệu cao. Bạn hoàn thành mọi thứ trong dự án và đưa ra sản phẩm tất cả một lúc cho khách hàng. Tuy nhiên, có rủi ro nằm trong cách tiếp cận này nếu các yêu cầu thay đổi, nhiều thứ phải bị làm lại; và nếu dự án quá lớn và mất quá lâu để thực hiện, công nghệ có thể thay đổi và làm cho dự án bị lỗi thời.
Bạn lựa chọn cách tiếp cận lặp khi yêu cầu là không rõ ràng và vẫn cần thay đổi; sản phẩm phải được đưa ra nhanh chóng cho khách hàng cho dù nó có thể không được hoàn chỉnh vì họ cần nó. Chuyển giao nhanh hơn cho phép sản phẩm được dùng theo từng phần nhỏ như được yêu cầu. Bởi vì thay đổi vẫn có thể xảy ra, tổ phát triển có thể phản ứng nữa và là chủ đề cho nhiều thay đổi nhỏ, quá nhiều thay đổi có thể làm cho sản phẩm phức tạp và khó hơn cho bảo trì. Thỉnh thoảng chất lượng có thể bị phá hoại do bản chất của chuyển giao nhanh chóng.
Từng cách tiếp cận đều có điểm mạnh và điểm yếu và từng cách nên được dùng dựa trên điểm mạnh của chúng. Tuy nhiên, bằng việc hiểu điểm yếu của chúng, bạn có thể xây dựng các kế hoạch giảm bớt rủi ro để tránh vấn đề tiềm năng.
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
