- Mike Cohn： 用戶故事不是用例
- Alistair Cockburn： 用戶故事之於用例就像瞪羚之於涼亭
- Extreme Programming.org： 用戶故事與用例的目的相同，但並不相同。
如果你在網上搜索關鍵詞“用例 vs 用戶故事”，你會發現一長串關於用例方法的缺點、問題或陷阱的文章，而與用戶故事相關的好處甚至更長。 . 有趣的是，IT 行業的變化如此之快，對於人們從過去的“時尚”事物轉變為現在的“較新時尚”事物的人來說甚至更快。
- 敏捷 = 用戶故事或敏捷 = 用戶故事 + Scrum
- 用戶故事 = 恰到好處 & 及時
- 用例 = 前期詳細需求捕獲
- 用例 = <<include>> + <<extends>> = 功能分解
- 用例 = 舊式和過時
As a tool vendor, we are pretty neutral in methods, tools and techniques. Personally, I want to stress clear that I am a big fans of Agile development, user story and scrum process. Particularly, the underlining principles and best practices related to concepts such as:
- Requirement discovery rather than requirement delivery
- Under the principle above that yields two important properties in Agile development process
(I will write more posts related the principles above with my own opinions, that is closely related to my PhD research area in 1992-1995 – metamodel & schema transformations)
Now, let’s go back to the topics “use case vs user story”. Well the heavy weight Agile Sages already casted the vote for that, am I so stubborn trying to overturn their “votes by arguing they are similar or even the same?
Let’s me show you an example to illustrate whether user story is “so different” from user case:
Good user stories are much more than just statements. A standard user story consists of three parts, commonly referred to as the three C’s.
The first “C” of each user story should follow the standardized format of:
As a [role], I want [to do something], so that [benefits]
which is the minimal content of a user story to be put into the card.
The Conversations is the contents of the second “C” of a user story which represent the discussion between the end-users, project owner and the development team. In these conversion, it records the verbal discussion, or many other useful information such as, emails, wireframes or any other related contents for project.
The final “C” of a user story is confirmation which is the acceptance criteria used to confirm that the user story is implemented corrected and successfully delivered.
Let me elaborate a little bit further on how to develop the confirmation part of a user story. In here we use the most well-known template called Gherkin which adopts the Given-When-Then formula to guide the writing of acceptance tests for a User Story:
- (Given.. and) some context
- (When.. and) some action is carried out
- (Then.. and) Perform some actions
Tools such as, Cucumber and Jbehave testing frameworks encourage use of the Given/When/Then template for conducting automated testing, though it can also be used purely as a heuristic irrespective of whether a tool to be used.
Let’s gather all the information for the “register course” user story and put it in the 3Cs format:
I adopted the commonly used 3 Cs format for representing the “register course” user story. Likewise, I also adopted the most widely used format for describing for the same “register course” use case elaborated by a use case description. I numbered the steps of the confirmation section (the last C) of the user story which is associated with the step number that I put in the use case description. They are the same “nine-step” of the scenario to be put in each of the approaches with different order. I believe both of the model representation is acceptable for their corresponding sages and followers. Then, the question again, is user story is very similar to user case and yet they are different or the order of the steps causing all sort of criticism for use case approach?
Semantically Equivalent with Different Meaning?
Let’s investigate whether there is similar case in the modeling domain, so that compare against the situation here, or it might help us to cast our own vote on “user story vs use cases”, but not either blindly follow the crowd or repeating what the sages said like a parrot talk.
Example: Semantically Equivalent
In UML we can describe a use case scenario with a sequence diagram, but we usually don’t use a collaboration diagram for the same purpose; even through both of the diagrams are semantically equivalent. In other words, both sequence diagram and collaboration diagram are having the same number of objects participating in a scenario with same number of messages passing around the same set of objects for performing a task of a scenario. However, the former one is time focus and the latter one is space focus. Sequence diagram is more intuitive when using it with scenario modeling, while collaboration diagram is appropriate for modeling structural relationship among objects. i.e. you want to represent the scenario of participated object structurally into MVC framework (model/view and control layers).
Personally, I don’t think using user story will make my team become agile, and use case will cause my team to be “upfront”. Most important is how we apply and use those tools with what kind of mindset and best practices behind. I am not too worry about people considering me to be “old style” or outdated when I actually act agile.
I still recall in the structured analysis and design days, perhaps we can use Abstract Data Type in ADA to apply the object oriented analysis and design principles without having the support of OOP in 198x, right? Unfortunately, you might not even come across the concepts of the Abstract Data Type at all! Oh! My God I accidentally disclose – I am old? Or, I should think positive – experienced?
What do you think? What is your vote on this? Let me know or correct me if I am wrong.