For a lot of people, the term use case is either completely vague, or associated with big upfront specification.
I think Use Case Driven Development can be very valuable, when rightly applied. Even in agile development. What are your experiences & thoughts?
Links for background information:
EPF definition of Use Case Driven Development
Use Case 2.0 eBook
Top comments (7)
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. :)
I'm not familiar with this technique, but at a first glance its focus is on the "golden paths" and requirements, so the downside will be all to lose focus as a developer on the rest of the paths (not so happy). I see it as the opposite of the "defensive programming", after just reading the first pages, so I may be wrong. With which other techniques is usually combined in real-world scenarios?
Hi. To clarify this a little bit: each use case consists of a set of flows. Each flow is a series of interactions between a user and a system.
There is one "basic flow". That is the "golden path" that you describe. It is very important, as it lets the user reach her desired outcome. So for the use case "buy product", the use case would probably start with the user browsing products, and end with the user confirming the purchase.
That's the moment value is created for the user.
But apart from the basic flow, there may be many so called "alternative flows". An alternative flow is either an alternative path to reach the desired outcome, or a path that ends with an error/error handling.
Another topic is how detailed you document the flows. That can go from a bullet point list of the basic flow's step and enumeration of the alternative flows, to describing all flows in details. That depends on your development process and context.
Hope that helps.
Without being formal about it, this maps pretty well to our approach. Formalization of how we work may be a useful exercise in the future, so thanks for sharing this reference material 😁
Cool. I am glad it's useful. 😀