3 ms·
> There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each o
by frant-hartm 5y ago
> There is a natural process that every issue goes through: Analysis, Specifications, Requirement, Design .. then the Developer takes in the materials of each of these steps, does an Implementation and Testing phase .. then the issue has to be validated/verified with a Qualification step, and then it gets released to the end user/product owner, who sign off on it.
If you do this feature by feature than you have described iterative/incremental development process. Scrum is one example of such process. Yes, Scrum is many little waterfalls.
But with Waterfall you
Do the analysis of the whole project/product, check
Specification of the whole.., check
Design, check
Implementation, check
Internal testing, check
UAT - this is the first time the customer sees the product, it's too late.
If you think it's stupid to do it this way you are right, that's the point. If you haven't seen this in real world then you probably didn't work on a government project or you were very lucky.
- boffinAudio 5y agoI've worked on all kinds of projects, and every single time the project failed, the tooling and methodology were blamed, not the individuals. This is the #1 cause of failed software projects - the inability for individuals to take responsibility for parts of the workflow, for which they are incompetent, and not subsequently working on improving that competence at an individual level. But true, breaking larger problems down into smaller units (Agile/Scrum) is an effective way for a "manager" to help their developers - but I argue this is non-optimal for sociological reasons, not technical: Adherence to a cargo-cult is a function of laziness, not competence.
- lupire 5y ago> Adherence to a cargo-cult is a function of laziness, not competence. Why doesn't this claim apply to Waterfall?
- AnimalMuppet 5y agoSo when waterfall doesn't work, it's the fault of the developers, who are doing it badly? Well, I've seen agile work, too, with really good developers. And plenty of people have seen both fail, if you don't have good enough developers. Hmm, maybe it's not the methodology?