
Use-Case 2.0 - steve371
http://queue.acm.org/detail.cfm?id=2912151
======
BinaryIdiot
So this is going to take some time to read and process but I'm not convinced
people should (I mostly skimmed). It's essentially another methodology for
getting work done that, like all the others, are so close to how each other
work it may not be useful to really understand or switch between any of them.
Even if you use this methodology I'm not convinced it's useful or helpful to
understand all the intricacies of it.

For example their section on how use cases and user stories differ are vague
and generic. It explains how user stories and use cases are similar but how
they differ is simply a list of generic, non-useful tripe such as "flexible",
"better", "easier", "increased understanding", "easy focus", etc.

I left this article not knowing if this is just a slight re-branding of every
other methodology out there nor any compelling information saying why I should
or should not use this one over others. Granted I didn't read the entire thing
but I read the beginning, end and skimmed the middle. You should be able to
convey your value in the first few sentences if you want people to use your
methodology. In my opinion anyway.

I get in big teams you need _some form_ of process but I feel like if your
process takes longer than a page to articulate then it's never going to be
followed and is a waste of time.

~~~
arnorhs
i agree, mostly. i had a hard time figuring out what the 2.0 part about it is.
if it's just about the slice, then i feel like the author is talking about it
from a perspective of where project/feature planning is being done wrong.

i wasn't particularly confused with the terms use case vs user story, but if i
didn't know those concepts already, the article would not have explained them
to me.

(fwiw a use case is a series of steps that a user must take to complete an
action, but a user story is usually a sentence told from the viewpoint of the
user such as "as a user, i want to log in so i can add a new post")

------
aryehof
My take, is that this primarily attempts to address one of the key criticisms
of use cases - the granularity issue. Use cases are often too broadly written
initially. When examined closely, one discovers that that the use case
presented really needs to be broken down into many more detailed (and changed)
cases.

The introduction of "slices" appears to acknowledge that. The problem is that
like functional decomposition in structured programming, constant re-
arrangement of the functional "tree" representing the problem will likely
result.

------
regularfry
To put this in a slightly more recognisable context, Use Case design is where
Bob Martin's Architecture: The Lost Years talk sprung from; you can draw a
line from there to the Hexagonal Architecture ideas that were floating around
at the time.

------
AzzieElbab
We have finally come a full circle. Agile UML and IBM Rational Scrum are just
around the corner

------
melle
See also the whitepaper of use-cases 2.0:
[https://www.ivarjacobson.com/publications/white-
papers/use-c...](https://www.ivarjacobson.com/publications/white-papers/use-
case-ebook)

