Use Cases 和 User Story 不同之處
Use cases - User Stories: so precious but not the same !
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/
以前在做object oriented/UML 時, 談的都是user cases, 現在在做agile時, 開始改談user story.
可是一開始覺得user story的描述和user case很像, 只是user story長了一點. 然後user story也不會像user case一樣要寫, scenario, pre-condition, post-condition...等等.
總覺得兩者, 說像不像, 總是同中有異.
在網路上找到有人比較兩者之間的差異, 讓我們一起來看看有什麼不同:
1. A user story is a brief description of functionality as viewed by the user (Role → Goal).
- It doesn’t model the interaction between the actor and the system, what the use case does.
- A user story is not a sequence of actions.
2. A user story is short and consist in one or two sentences written in the language of the user
- Example: As a recruiter, I can submit job vacancies. A role and a goal, then it is discussed.
- A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
4. User stories are used for planning.
- They play a major role in project estimation and planning (via story points and velocity).
- Use cases are not used for planning, even if you can use “use cases points” technique to estimate project size.
5. User stories emerge faster than use cases; use cases require more time for analysis and writing
6. User stories are more readable than use cases
- Use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
7. User stories are easier to maintain than a 150 pages Use cases Document
8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details
- Use case is a textual model (associated with diagrams): every thing is written !
9. User stories are in theory written on cards
- Remember the 3 C rule: Card, Conversation, Confirmation
- They’re not intended to be archived unlike use cases.
10. A user story must be implemented and tested in one iteration
- A specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
11. User stories can be more easily written by a user or customer
- Most of the time use cases are written by user proxies (BA, Consultants …)
12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
14. Finally, Use cases and user stories are usually associated with two different methodologies (Unified Process vs eXtreme Programming).
- But you can do user stories in a Unified Process environment !
作者雖然已經有十年使用use case經驗, 但是現在他覺得user story是他的最愛, 原因呢?
* User stories focus on what is really important
* User stories are more appropriate for collaboration
* User stories can perfectly be combined with UX(User eXperience) activities (Personas, Storyboard, Wireframes):
User stories + UX artifacts = Just enough
看起來user story是比use case, 更有效率想要找出user真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?
Use cases - User Stories: so precious but not the same !
http://www.agile-ux.com/2009/01/23/use-cases-user-stories-so-precious-but-not-the-same/
以前在做object oriented/UML 時, 談的都是user cases, 現在在做agile時, 開始改談user story.
可是一開始覺得user story的描述和user case很像, 只是user story長了一點. 然後user story也不會像user case一樣要寫, scenario, pre-condition, post-condition...等等.
總覺得兩者, 說像不像, 總是同中有異.
在網路上找到有人比較兩者之間的差異, 讓我們一起來看看有什麼不同:
1. A user story is a brief description of functionality as viewed by the user (Role → Goal).
- It doesn’t model the interaction between the actor and the system, what the use case does.
- A user story is not a sequence of actions.
2. A user story is short and consist in one or two sentences written in the language of the user
- Example: As a recruiter, I can submit job vacancies. A role and a goal, then it is discussed.
- A use case is heavier, richer in information: goal, summary, actor, precondition, trigger event, main success scenario and extensions (alternative paths, errors …). Use case is (too much) detailed.
3. A user story is smaller and can finally be seen as a part of a specific use case: the main success scenario or an extension
4. User stories are used for planning.
- They play a major role in project estimation and planning (via story points and velocity).
- Use cases are not used for planning, even if you can use “use cases points” technique to estimate project size.
5. User stories emerge faster than use cases; use cases require more time for analysis and writing
6. User stories are more readable than use cases
- Use cases usually belong to a large word document, often poorly written and difficult to read even in a structured template
7. User stories are easier to maintain than a 150 pages Use cases Document
8. User stories are based on verbal communication and rely on collaboration, discussion and proximity to clarify details
- Use case is a textual model (associated with diagrams): every thing is written !
9. User stories are in theory written on cards
- Remember the 3 C rule: Card, Conversation, Confirmation
- They’re not intended to be archived unlike use cases.
10. A user story must be implemented and tested in one iteration
- A specific use case can be implemented in several iterations: main success scenarion on iteration 1; extensions in Iteration 2 and 3 …
11. User stories can be more easily written by a user or customer
- Most of the time use cases are written by user proxies (BA, Consultants …)
12. User stories contain acceptance tests (validation criteria) written on the back of the story card; use case not: tests cases are created in a separate documentation
13. Use cases provide a more holistic view of the system: precondition, UC diagram, sub use case. Linking user stories is less obvious. This is also a reason why UX and IxD activities are so important in agile contexts !
14. Finally, Use cases and user stories are usually associated with two different methodologies (Unified Process vs eXtreme Programming).
- But you can do user stories in a Unified Process environment !
作者雖然已經有十年使用use case經驗, 但是現在他覺得user story是他的最愛, 原因呢?
* User stories focus on what is really important
* User stories are more appropriate for collaboration
* User stories can perfectly be combined with UX(User eXperience) activities (Personas, Storyboard, Wireframes):
User stories + UX artifacts = Just enough
看起來user story是比use case, 更有效率想要找出user真正的需求, 更著重有效溝通. 不知各位看倌你們的感覺如何?
文章標籤
全站熱搜
David, 有些問題想私下請教..方便提供您E-Mail嗎? TKS~
oops, 打完了Post了卻不見了，還是需要檢查過才可以？
應該沒有吧
打了兩次都貼不上, sigh.. 打了不少的, 有其他溝通方式嗎?
Hi David, Thank you. Post 或者不Post相對不重要，討論才是重點 :) 關於Use Cases 和 User Story 不同之處： - Use Cases 也有Agile的支持者, e.g Alistair Cockburn - Story card 加上 acceptance tests 其實差不多就是 Use case - Use Cases 相比 User Stories 最大好處是可以用作交給客戶的文檔 之前小弟也譯過一篇相關文章，並加入自己觀點： http://www.infoq.com/cn/news/2008/08/use-case-or-user-story 關於Scrum + Manual Testing methodology: Scrum 一直提倡Cross-Functional Team，根本不存在定立一個固定叫 作"Tester"的角式，不是反對有"Tester"，只是視乎實際情況而定。 還有 "Give up manual testing"，這點很奇怪，其實好的團隊應該可以 知道如何去測試，或者有什麼要測試，要不要手動測試不會因為有自動化 測試和使用Scrum而被忽略。 "give up agile principle of quick feedback and test one iteration behind. " 也很奇怪，問題出於什麼叫做「完成」，團隊有需 要定下什麼叫「完成」，這所謂每個項目都可能不一樣，但至少不是把測 試忽略，或者留到下一個iteration http://www.infoq.com/cn/news/2008/10/PowerOfDone 有本叫 "Agile Testing" 的書，值得參考，討論QA在Agile方法下如何運作。 Thank you, Steven
上篇是我代人post的, 感謝Steven的回應
Hi Steven Sorry for late response. I am too busy recently 關於"Give up manual testing"這點, 我的參想是因為agile的團隊大多 提倡test automation, 像是TDD, XUnit, FIT等等, 認為很多東西是可以 用test automation來解決的 但是也有些人認為, test automation是有盲點的, 還是無法抓到很多 scenario所產生的bug. 所以就有人提出exploratory testing, 來彌補 test automation的不足. 你可以參考explortory testing相關的資料, 你可以知道他想解決什麼方面的問題 所以有可能作者只是想強調這件事吧!!
Hi 關於 "give up agile principle of quick feedback and test one iteration behind. " 我想對於有些剛run Scrum的team, 因為他不熟悉或是不擅長的緣故, 導 致他無法作完testing, 因此之後他就採取one iteration behind的策略. 所以這樣的team可能也不是故意要不定好做完的準則, 只是他沒有能力做 完他想作的, 可是又想follow up agile的 principle, 就會有這種狀況 發生, 會自己想一些變形出現 我現在就遇到一個這樣的team
華醫中草藥研