用戶故事與用例兼容嗎？

Table of Contents hide
1 在網上搜索，敏捷賢者認為用例和用戶故事是兩個不同的東西：
1.1 Example
1.2 Semantically Equivalent with Different Meaning?

在網上搜索，敏捷賢者認為用例和用戶故事是兩個不同的東西：

用例驅動方法是需求捕獲最熱門的技術之一，現在有些人認為它是一種過時的舊式技術，它與許多問題相關聯，導致您的團隊由於用例問題而不是“敏捷” ：

  • 前期需求——試圖定義前期所有方面的細節將導致大量的精力和時間的浪費，因為很多工作都需要重做。
  • 功能分解：用例的功能性質自然導致系統在具體和抽像用例方面的功能分解，這些用例通過擴展關聯並包括用例關聯。

如果你在網上搜索關鍵詞“用例 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
    • Just-in-time
    • Just-enough

(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:

Example

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:

confirmation

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.

use case description - user story

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.