Obligatory comment: waterfall is about a flow of artifacts, not time. The 70’s approach assumes you gather all requirements first, then implement the entire product, and then test is as a whole. It’s just one way to do it, however.
You decide how fine-grained is it. Many projects would benefit from properly gathering requirements from their features rather than working from user stories. They would also benefit from writing specifications of the features: even a single page document can help you make sure everyone involved agrees how it’s supposed to work, and it doesn’t take a long time to write.
A habit of documenting features when development is complete is also helpful.
There’re no universal obstacles for multiple waterfalls flowing in parallel.
Obligatory comment: waterfall is about a flow of artifacts, not time. The 70’s approach assumes you gather all requirements first, then implement the entire product, and then test is as a whole. It’s just one way to do it, however.
You decide how fine-grained is it. Many projects would benefit from properly gathering requirements from their features rather than working from user stories. They would also benefit from writing specifications of the features: even a single page document can help you make sure everyone involved agrees how it’s supposed to work, and it doesn’t take a long time to write. A habit of documenting features when development is complete is also helpful.
There’re no universal obstacles for multiple waterfalls flowing in parallel.
Came in braced for sloganeering and false dichotomy. But no, this one is actually quite thoughtful and nuanced. Thanks!