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.
—-English version—-
Waterfall and Iterative development
A student wrote to me: “When do we use the Waterfall and when do we use the Iterative approach? How do we select which is best for software project?
Answer: Both of these approaches follow a well defined process with specific details. You select the Waterfall approach when the requirements are well understood and the project must follow certain rules and regulations (i.e. large critical project or government projects) where it requires high level of quality and documentation. You complete everything in the project and release the product all at once to customers. However, there are risks involved in this approach if the requirements change, many thing have to be reworked; and if the project is too big and takes too long, technology may change and make the project obsolete.
You select the Iterative approach when the requirements are not clear and still need to change; the product must be released quickly to customers even it may not be completed as they need it. Faster delivery allows product to be used in small parts as needed. Because changes can still happen, development team may be too reactive and subject to a lot of small changes, too many changes can make the product more complex and difficult to maintain. Sometime quality may be compromised due to the nature of deliver quickly.
Each approach has strengths and weaknesses and each should be used based on their strengths. However, by understanding their weaknesses you can build risk mitigation plans to avoid potential problems.
