3 ms·
> Requirements change. Every software engineering project will face this hard problem at some point. > There is really only one answer to this: you need to fin
by asplake 7y ago
> Requirements change. Every software engineering project will face this hard problem at some point.
> There is really only one answer to this: you need to find a way to match the requirements-development-delivery cycle to the rate at which the requirements change.
Honestly, I believe that much of the problem is with the word “requirements” and I so wish we could kill this use of the word. Bottom line, for systems built for humans, ploughing through backlogs of requirements is the path to mediocracy (or worse) – as the OP discovered.
A less misleading framing: you need to find a way to match the delivery cycle to the rate at which understanding changes. In other words, your development process is a learning process.
- asplake 7y agoShameless plug (I’m paraphrasing myself in the “mediocrity” line above): Right to Left: The digital leader’s guide to Lean and Agile https://www.amazon.co.uk/Right-Left-digital-leaders-guide/dp/1789555310 https://www.amazon.co.uk/Right-Left-digital-leaders-guide/dp...
- artsyca 7y ago100% agree learning is the core problem people in large organizations really don't know how to learn and the typical corporate environment is the perfect quasi academic environment geared towards pursuing metrics that amount to chasing grades
- notduncansmith 7y agoThis absolutely. As understanding evolves, requirements evolve. Some domains are well-understood enough that this process can be done up-front a-la waterfall, but more often these domains are so dynamical that the only way to understand them is incrementally, one dynamic (or metadynamic) at a time.