關於用例需要多少文件以及業務用例等等
阿新 • • 發佈：2019-02-14
整理者：張克強
緣起
@jackyrong 發了如下一條微博敏捷中的文件該寫多少合適，一直是永恆的話題，每個用例故事的設計簡要卡片，用例圖，序列圖，類圖，資料字典，簡要原型圖，演算法補充說明，應該是必要的吧，大家可以繼續探討 @袁斌_AgileDo @竹十一 @敏捷廣州聯盟 @火球_Fireball
張克強-敏捷307：這些都寫了，那不就是RUP了？ (5月18日
17:37)
jackyrong：回覆@張克強-敏捷307:那倒不一定，看的是寫的側重和“度”的問題 (5月18日
17:48)
張克強-敏捷307：注意到用例故事這樣的組合，上次@agile123 也提到了使用者故事，源自於何處？目前有什麼定義或者說明嗎？ (5月18日
17:51)
agile123：“用例故事”好像是源於特級資深敏捷教練張恂老師的《用例故事勝過使用者故事》這篇文章吧，簡單說用例故事是Use
Case的中文別稱，因為用例本就是故事，比使用者故事出現更早、更成熟的需求故事 http://t.cn/RvwEJ4h
agile123：#統一用例方法#UUCM提倡在敏捷開發中用Use Case Card取代User Story Card，卡片上可放用例名稱、用例圖、用例簡述（相當於XP使用者故事）、優先順序等資訊，其他如需求文件、架構文件則是必須的
焦點問題的出現
火星人陳勇：第一級應該是“有什麼”圖（建議用例圖，但真心不好用），輔以簡單故事卡描述；還有時間，銀行推薦業務邏輯圖（泳道、序列），網際網路推薦介面原型；還有時間，才畫類圖等與實現相關的。不過，與其畫UML，不如加入一些別的東西。比如寫擴充套件流不如寫Gherkin。【注意：@火星人陳勇說的是 第一級】 張克強-敏捷307：回覆@火星人陳勇:贊同勇哥，rup中的業務用例以及業務用例圖就是真心不好用的典型。還不如最傳統的功能模組圖，不過uml的活動圖和序列圖優於傳統的流程圖。rup中業務用例-業務用例實現-用例-用例實現真是讓人無語，嚇退n多騷年。雅格步森大師自己境界太高了，真是太高估業界騷年了。 (5月20日 20:58)
火星人陳勇：回覆@張克強-敏捷307:用例圖有幾個大問題：1. 只能用來記錄發現的用例，不能用來分析出用例；2. 沒有直觀方法看出“已經列出了所有必要的用例”，很容易遺漏； 3. 用例七大八小； 4. 用例之間的關係極其模糊。而且UML並沒有其他配套圖形協助用例圖解決這些問題。一起大讚序列圖。
【按照陳勇和我微博的上下文，我們討論的物件是第一級和業務用例、業務用例圖】
爭論的出現
agile123：胡說，業務用例（相當於business process）與功能模組是一回事麼？用例是以使用者為中心分析出來的系統服務價值單位，優於傳統功能分解。兩位學習用例技術其實還沒入門![[弱]](http://img.t.sinajs.cn/t4/appstyle/expression/ext/normal/d8/sad_org.gif "[弱]")
UMLGreatChina：回覆@火星人陳勇:怎麼沒有直觀方法？畫在一張用例圖裡的就是所有必要的用例，一目瞭然，還不直觀？如果嫌空間小，可以換A3紙或者更大的螢幕、圖紙，把“所有必要的用例”都裝下 ![[嘻嘻]](http://img.t.sinajs.cn/t4/appstyle/expression/ext/normal/0b/tootha_org.gif "[嘻嘻]")
//2.
沒有直觀方法看出“已經列出了所有必要的用例”UMLGreatChina：回覆@火星人陳勇:這也不是什麼缺陷。需求本來就有大有小，有粗有細，用例的分層不過是對這種複雜客觀現實的反映，而且通過用例分層技術可以把大大小小各種不同粒度的需求整理得非常清楚而有條理 //3. 用例七大八小
UMLGreatChina：回覆@火星人陳勇:這根本不是個問題。用例圖（diagrams）只是一個表達形式和結果，如何分析出用例要靠用例分析的方法（methods），如UP、Jacobson、Cockburn、UUCM等，你只學了圖，不學方法怎行？這邏輯不對 //用例圖有幾個大問題：1. 只能用來記錄發現的用例，不能用來分析出用例 @張克強-敏捷307(5月21日 11:08)
UMLGreatChina：回覆@火星人陳勇:解釋起來其實很簡單，C語言的include、Java類的extends你總熟悉吧意思差不多：包含是公共功能，擴充套件是附加功能。你認為極其模糊是因為你學用例還沒入門，一知半解，不得要領 //4. 用例之間的關係極其模糊。而且UML並沒有其他配套圖形協助用例圖解決這些問題。@張克強-敏捷307(5月21日 11:21)
關於業務用例
@張克強-敏捷307:業務用例與功能模組不是一回事，但業務用例與用例也不是一回事，業務用例能夠幫助理解用例的背景，但其有@火星人陳勇 說的那些問題。張克強-敏捷307：回覆@UMLGreatChina:注意我一直說得是業務用例與業務用例圖有蠻多問題。對用例和用例圖可是很推崇的。真不建議你再去弘揚業務用例。 (5月21日 11:04)
UMLGreatChina：既然你也推崇用例，那就沒理由反對業務用例啊。UML需求用例分析的精妙在於用同一套思路方法同時來做系統和業務建模，只不過把boundary擴大到業務組織。你說BUC到底有哪些問題？ @張克強-敏捷307:業務用例的關鍵問題就是邊界極為模糊啊，範圍寫大了浪費時間，寫小了可能漏，寫細了與用例重複，寫粗了與功能模組劃分沒區別,，無論如何寫都不合適。用幾張泳道圖或者序列圖把核心業務流程表達就足夠了。把有限的時間直接放到用例上。 UMLGreatChina：沒這麼難吧，scope是從一開始就應該確定的，BUC的概念無非是把邊界擴大點，除system外把human的活動也考慮在內。估計是你沒掌握技巧，最好舉個困難的例子？
張克強-敏捷307：關鍵不是難度，關鍵在於其意義可以被更經濟的替代。而且其業務用例本身沒有合適的規範，一旦開寫，不同角色可以從不同角度提不同意見，麻煩多多。 UMLGreatChina：你的意思是不要寫業務用例的文字細節？可以，要不要業務建模、業務用例這都要看專案的實際情況，的確業務建模可以畫圖為主，簡單的用UML活動圖甚至BPMN等就夠了，但是許多複雜的業務流程只畫圖可能不夠。It depends UMLGreatChina：是否要寫業務用例文字要看專案需要ROI，通常金融業務系統只畫圖不夠。至少一個公司內部應形成需求用例的標準，我的UUCM模板可供參考 @張克強-敏捷307:我認為業務用例圖有蠻多不足，但用例和用例圖絕對是uml&rup的精髓。通過用例圖、角色和系統邊界識別用例是行雲流水般的思考，遠遠優於傳統的需求規格書，我很享受這種過程，能夠充分體會用例之美之優雅。
關於未來
火星人陳勇：應該這麼說，我（們？）正在嘗試消滅功能模組，只留下業務用例，把業務用例作為分析、設計、開發、測試、驗收的共同單位（很類似BDD或者FDD吧），因此”留下“的東西要繼承”砍掉“的東西的一些特性。 (5月21日 13:44)agile123：UP、OUM、Taij/UDD等都是用例驅動的，而ATDD、BDD加使用者故事的意思其實差不多，但後者受極限派影響是不敢或不便提UseCase的，這就是科學家之間的門派之爭 火星人陳勇：哦，不是這個意思，我是說比如在百度”用例圖“前三張，（作為外行）是否能看出裡邊缺少了什麼用例？包括他畫在別的圖裡邊的。利用一種新的東西（其實還是用例圖的變形，但配合了FPA、MVP），我現在就能找到缺少的東西，甚至能告訴他缺少的東西叫什麼好。這個以後再揭祕。 (5月21日 13:52)
火星人陳勇：如果有一種圖，圖中的元素大小相近，而又能分層把不同顆粒度的……是不是更好？我稱之為有根有葉樹，有根就是你說的整理地非常有條理，有葉則是存在一種大小相似的東西（自然界同種的樹尺寸差別很大，但葉子卻差不多），作為最終需求、估算、設計、開發、測試、驗收、度量用。
火星人陳勇：在我們看來，用例和使用者故事史無前例地採用”條目“而非大段文字表述需求，已經達到”歷歷可數“的狀態，可惜數完了卻被告知尺寸不一，因此無法把用例放在分母上得到生產率、缺陷率、測試覆蓋率……等，實在可惜。若此問題被克服了，將對用例的價值有很大提升。但這就要動用例的一些規則。 (5月21日 14:00)
火星人陳勇：等回頭看”用例-狀態圖“吧，10分鐘教學，10分鐘練習（之前不用任何UML基礎），6個團隊繪製6張他們的圖，一般有2張圖我找不出漏了什麼，2張圖漏東西，1張圖慘不忍睹。 (5月21日 14:03)
火星人陳勇：我做下一個月迭代的時候最關心的是：”這一大堆用例裡邊，哪些拿出來，正好滿足兩個條件：1. 開發出來的東西完整可交付（不多，不少，MVP）；2. 正好一個月開發完（可估）。“1. 需要能看到用例之間的一種依賴、內聚關係，包含、擴充套件沒用；2. 需要有相近顆粒度和生產率 (5月21日 14:14)
火星人陳勇：圖先不著急，我可能要自己繪製超過100張才會有足夠穩定的圖釋出。但在發圖之前，我想知道有沒有人和我一樣感受到用例圖的4個問題（或者對現有解決方案不滿意的地方），以及有何嘗試。就像現有的UML會限制思維，我的圖也一樣。 (5月21日 14:21)
火星人陳勇：給個提示：2月份和一個資深朋友聊，我說我喜歡用例，因為和使用者故事、功能點能做很好的對應。他說他會先畫狀態圖，因為可以不多不少地分析出用例（狀態圖的線條其實就是某些用例），我大吃一驚……1個月後，就有了我說的那張圖。 (5月21日 14:27)
火星人陳勇：@UMLGreatChina@張克強-敏捷307@敏捷123 我當前正在同時使用UML，FPA，使用者故事，BDD四者管理需求。我個人感覺與其討論“哪個更好”（到處都是），不如取長補短。所以要去掉三個，留下一個。所以現在說的“找缺點”，不是說找到缺點把UML扔掉，而是留下並改造它，去掉另外幾個。 (5月21日 16:32)
UMLGreatChina：這思路不錯，UML、UseCase、UDD完全可取代使用者故事和BDD 火星人陳勇：UML的戰線最長，工程化程度最高，因此作為一個基礎在其上擴充套件比較容易（甚至有時候是做減法），其他幾個都是點狀的，無法承載“過程”“模型”等這些詞彙；不過不改造還是有一些不足。
UMLGreatChina：的確這是一個技術路線問題，這些年OO方法技術一直是主流 火星人陳勇：回覆@張克強-敏捷307:嘿嘿，下次見面我畫個“用例-狀態圖”，體驗一下跟頭雲的感覺。不過最近想和精益的MVP（最小可用產品）結合一下，從外界重新分析一下，也重新命名一下。MVP聽名字就比“用例-狀態圖“外向地多，商業地多，有價值的多，視野開闊地多。
火星人陳勇：回覆@張克強-敏捷307:長相更像用例-活動圖，因為發生在用例之間而非之內，所以叫用例-狀態圖更妥。此圖用來找出用例；繪製完成後會知道”完成了“；兩個人繪製的圖幾乎一模一樣；平均每張圖開發工作量35人天；看著圖能寫出測試用例（群），還能知道寫完了沒有；每張圖是一個迷你MVP，必須完整發布……
結語
張克強-敏捷307： 說了這麼多，其實還沒有直接回答原博主的提問。我來回答下吧：在敏捷環境下，如果只使用用例表達需求（不聯合使用使用者故事），那麼圍繞用例必須的文件是用例圖和用例規約（不一定要正式的）+資料字典。 其它的不是必需的，依賴於團隊對UML和OOAD的認識和水平，但就算團隊對UML和OOAD有很高水平, 見續張克強-敏捷307： 如果把以上提到的全寫了，覆蓋所有類，而且沒有一個強大的支援正反向工程的UML工具，那麼多半是不敏捷了。(10秒前)