3 ms·
Agile is designed for that case, but most development methodologies are designed for that case. The idea that requirements are set in stone, or - more specific
by forgottenpass 10y ago
Agile is designed for that case, but most development methodologies are designed for that case.
The idea that requirements are set in stone, or - more specifically - the idea that not setting them in stone is breaking conventional wisdom is just running us in circles.
Requirements are just a name for detailed goals. They change as goals change. Diffs can be applied them just as easily as to the codebase. Maybe a team has them over emphasized and too rigid, maybe too undocumented and in flux. But prescriptive development methodology doesn't give teams tools to figure out what works for their projects.
Development processes aren't really improving with every new trendy thing that comes out, they're just finding new ways to package and shuffle things around.
- taneq 10y ago> but most development methodologies are designed for that case Modern (ie. post-XP) software methodologies, yes. Traditional engineering? Not at all. Software is unique in that it's essentially free to convert your design into your end product. It's one thing to iterate weekly when your build process costs $0.02 of electricity and half an hour of server time. It's another thing entirely when you have to obtain many different parts (some with long lead times, others custom built, and small batches always cost far more per unit) and then assemble them manually before testing a physical object.