The way we develop our systems are probably close to use-case 2.0. We implement of set of stories or use cases every month. Then as users interact with the system, they ask for changes to existing use cases or additions. However, we don't blindly implement every request, but we considering each one holistically. In most cases, we will collect multiple requests before we decide something is worth implementing. Then we may re-frame the use case to provide a more targeted version of what was asked. For instance, the user asks for a new field to identify who is responsible for a course. But after interviewing a couple of different users on this, we decided to implement a "Report a problem with this course" feature instead (which does include the originally requested field too). Because that's the problem they really wanted to be solved.
I think where most development methodologies vary is in degree of design. Big upfront is all about doing a complete design of every piece of the system before building anything. TDD mostly encourages doing no design at all at the system level. Instead, it is at the component or unit level (design small bits of code to be testable). Both of these seem to me too far on either end of the design spectrum. To me the best path is somewhere in the middle. Take the time to do some design, and weigh the trade-offs of that design before proceeding. But don't waste time trying to nail down every detail of the design, because many of those details will be wrong after the first user or tester comes in contact with them.
In my opinion, it's a good idea to ask "why?" or "what for?" when a stakeholder has an overly specific request. As you said, solving the user's problem is often even done best with a different solution (compared to what was originally requested).
Concerning your second point, Agile Manifesto co-author Robert C. Martin has a nice quote on this:
"I do big upfront design. I just don't believe in it." So I guess you are in good company 😁
The way we develop our systems are probably close to use-case 2.0. We implement of set of stories or use cases every month. Then as users interact with the system, they ask for changes to existing use cases or additions. However, we don't blindly implement every request, but we considering each one holistically. In most cases, we will collect multiple requests before we decide something is worth implementing. Then we may re-frame the use case to provide a more targeted version of what was asked. For instance, the user asks for a new field to identify who is responsible for a course. But after interviewing a couple of different users on this, we decided to implement a "Report a problem with this course" feature instead (which does include the originally requested field too). Because that's the problem they really wanted to be solved.
I think where most development methodologies vary is in degree of design. Big upfront is all about doing a complete design of every piece of the system before building anything. TDD mostly encourages doing no design at all at the system level. Instead, it is at the component or unit level (design small bits of code to be testable). Both of these seem to me too far on either end of the design spectrum. To me the best path is somewhere in the middle. Take the time to do some design, and weigh the trade-offs of that design before proceeding. But don't waste time trying to nail down every detail of the design, because many of those details will be wrong after the first user or tester comes in contact with them.
I think you bring up some important points.
In my opinion, it's a good idea to ask "why?" or "what for?" when a stakeholder has an overly specific request. As you said, solving the user's problem is often even done best with a different solution (compared to what was originally requested).
Concerning your second point, Agile Manifesto co-author Robert C. Martin has a nice quote on this:
"I do big upfront design. I just don't believe in it." So I guess you are in good company 😁
I don't consider myself as doing big upfront design. But I appreciate the comparison. :)