整理者：張克強(qiáng)

緣起

@jackyrong 發(fā)了如下一條微博

敏捷中的文檔該寫多少合適，一直是永恒的話題，每個用例故事的設(shè)計(jì)簡要卡片，用例圖，序列圖，類圖，數(shù)據(jù)字典，簡要原型圖，算法補(bǔ)充說明，應(yīng)該是必要的吧，大家可以繼續(xù)探討?@袁斌_AgileDo?@竹十一?@敏捷廣州聯(lián)盟?@火球_Fireball

|?轉(zhuǎn)發(fā)(58)|?收藏|?評論(35) 5月16日

張克強(qiáng)-敏捷307：這些都寫了，那不就是RUP了？?(5月18日 17:37)

? ??jackyrong：回復(fù)@張克強(qiáng)-敏捷307:那倒不一定，看的是寫的側(cè)重和“度”的問題?(5月18日 17:48)

張克強(qiáng)-敏捷307：注意到用例故事這樣的組合，上次@agile123?也提到了用戶故事，源自于何處？目前有什么定義或者說明嗎？?(5月18日 17:51)

? ??agile123：“用例故事”好像是源于特級資深敏捷教練張恂老師的《用例故事勝過用戶故事》這篇文章吧，簡單說用例故事是Use Case的中文別稱，因?yàn)橛美揪褪枪适?#xff0c;比用戶故事出現(xiàn)更早、更成熟的需求故事?http://t.cn/RvwEJ4h?

? ??agile123：#統(tǒng)一用例方法#UUCM提倡在敏捷開發(fā)中用Use Case Card取代User Story Card，卡片上可放用例名稱、用例圖、用例簡述（相當(dāng)于XP用戶故事）、優(yōu)先級等信息，其他如需求文檔、架構(gòu)文檔則是必須的?

焦點(diǎn)問題的出現(xiàn)

火星人陳勇：第一級應(yīng)該是“有什么”圖（建議用例圖，但真心不好用），輔以簡單故事卡描述；還有時間，銀行推薦業(yè)務(wù)邏輯圖（泳道、序列），互聯(lián)網(wǎng)推薦界面原型；還有時間，才畫類圖等與實(shí)現(xiàn)相關(guān)的。不過，與其畫UML，不如加入一些別的東西。比如寫擴(kuò)展流不如寫Gherkin。?(5月20日 16:07)
【注意：@火星人陳勇說的是 第一級】 張克強(qiáng)-敏捷307：回復(fù)@火星人陳勇:贊同勇哥，rup中的業(yè)務(wù)用例以及業(yè)務(wù)用例圖就是真心不好用的典型。還不如最傳統(tǒng)的功能模塊圖，不過uml的活動圖和序列圖優(yōu)于傳統(tǒng)的流程圖。rup中業(yè)務(wù)用例-業(yè)務(wù)用例實(shí)現(xiàn)-用例-用例實(shí)現(xiàn)真是讓人無語，嚇退n多騷年。雅格步森大師自己境界太高了，真是太高估業(yè)界騷年了。?(5月20日 20:58)
火星人陳勇：回復(fù)@張克強(qiáng)-敏捷307:用例圖有幾個大問題：1. 只能用來記錄發(fā)現(xiàn)的用例，不能用來分析出用例；2. 沒有直觀方法看出“已經(jīng)列出了所有必要的用例”，很容易遺漏； 3. 用例七大八小； 4. 用例之間的關(guān)系極其模糊。而且UML并沒有其他配套圖形協(xié)助用例圖解決這些問題。一起大贊序列圖。?(5月20日 21:06)
【按照陳勇和我微博的上下文，我們討論的對象是第一級和業(yè)務(wù)用例、業(yè)務(wù)用例圖】

爭論的出現(xiàn)

agile123：胡說，業(yè)務(wù)用例（相當(dāng)于business process）與功能模塊是一回事么？用例是以用戶為中心分析出來的系統(tǒng)服務(wù)價值單位，優(yōu)于傳統(tǒng)功能分解。兩位學(xué)習(xí)用例技術(shù)其實(shí)還沒入門?? UMLGreatChina：回復(fù)@火星人陳勇:怎么沒有直觀方法？畫在一張用例圖里的就是所有必要的用例，一目了然，還不直觀？如果嫌空間小，可以換A3紙或者更大的屏幕、圖紙，把“所有必要的用例”都裝下???//2. 沒有直觀方法看出“已經(jīng)列出了所有必要的用例”
UMLGreatChina：回復(fù)@火星人陳勇:這也不是什么缺陷。需求本來就有大有小，有粗有細(xì)，用例的分層不過是對這種復(fù)雜客觀現(xiàn)實(shí)的反映，而且通過用例分層技術(shù)可以把大大小小各種不同粒度的需求整理得非常清楚而有條理 //3. 用例七大八小
UMLGreatChina：回復(fù)@火星人陳勇:這根本不是個問題。用例圖（diagrams）只是一個表達(dá)形式和結(jié)果，如何分析出用例要靠用例分析的方法（methods），如UP、Jacobson、Cockburn、UUCM等，你只學(xué)了圖，不學(xué)方法怎行？這邏輯不對 //用例圖有幾個大問題：1. 只能用來記錄發(fā)現(xiàn)的用例，不能用來分析出用例?@張克強(qiáng)-敏捷307?(5月21日 11:08)
UMLGreatChina：回復(fù)@火星人陳勇:解釋起來其實(shí)很簡單，C語言的include、Java類的extends你總熟悉吧意思差不多：包含是公共功能，擴(kuò)展是附加功能。你認(rèn)為極其模糊是因?yàn)槟銓W(xué)用例還沒入門，一知半解，不得要領(lǐng) //4. 用例之間的關(guān)系極其模糊。而且UML并沒有其他配套圖形協(xié)助用例圖解決這些問題。@張克強(qiáng)-敏捷307?(5月21日 11:21)

關(guān)于業(yè)務(wù)用例

@張克強(qiáng)-敏捷307:業(yè)務(wù)用例與功能模塊不是一回事，但業(yè)務(wù)用例與用例也不是一回事，業(yè)務(wù)用例能夠幫助理解用例的背景，但其有@火星人陳勇?說的那些問題。
張克強(qiáng)-敏捷307：回復(fù)@UMLGreatChina:注意我一直說得是業(yè)務(wù)用例與業(yè)務(wù)用例圖有蠻多問題。對用例和用例圖可是很推崇的。真不建議你再去弘揚(yáng)業(yè)務(wù)用例。?(5月21日 11:04)
UMLGreatChina：既然你也推崇用例，那就沒理由反對業(yè)務(wù)用例啊。UML需求用例分析的精妙在于用同一套思路方法同時來做系統(tǒng)和業(yè)務(wù)建模，只不過把boundary擴(kuò)大到業(yè)務(wù)組織。你說BUC到底有哪些問題？ ? ? ? ?@張克強(qiáng)-敏捷307:業(yè)務(wù)用例的關(guān)鍵問題就是邊界極為模糊啊，范圍寫大了浪費(fèi)時間，寫小了可能漏，寫細(xì)了與用例重復(fù)，寫粗了與功能模塊劃分沒區(qū)別,，無論如何寫都不合適。用幾張泳道圖或者序列圖把核心業(yè)務(wù)流程表達(dá)就足夠了。把有限的時間直接放到用例上。 ? ? ? ? ? ? ? ? ? ? ? ?UMLGreatChina：沒這么難吧，scope是從一開始就應(yīng)該確定的，BUC的概念無非是把邊界擴(kuò)大點(diǎn)，除system外把human的活動也考慮在內(nèi)。估計(jì)是你沒掌握技巧，最好舉個困難的例子？
? ? ? ? ? ? ? ? ? ? ? ? ??張克強(qiáng)-敏捷307：關(guān)鍵不是難度，關(guān)鍵在于其意義可以被更經(jīng)濟(jì)的替代。而且其業(yè)務(wù)用例本身沒有合適的規(guī)范，一旦開寫，不同角色可以從不同角度提不同意見，麻煩多多。 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?UMLGreatChina：你的意思是不要寫業(yè)務(wù)用例的文本細(xì)節(jié)？可以，要不要業(yè)務(wù)建模、業(yè)務(wù)用例這都要看項(xiàng)目的實(shí)際情況，的確業(yè)務(wù)建模可以畫圖為主，簡單的用UML活動圖甚至BPMN等就夠了，但是許多復(fù)雜的業(yè)務(wù)流程只畫圖可能不夠。It depends? ? ? ? ? ? ? ? ? ? ? ? ? ? ?UMLGreatChina：是否要寫業(yè)務(wù)用例文本要看項(xiàng)目需要ROI，通常金融業(yè)務(wù)系統(tǒng)只畫圖不夠。至少一個公司內(nèi)部應(yīng)形成需求用例的標(biāo)準(zhǔn)，我的UUCM模板可供參考?? @張克強(qiáng)-敏捷307:我認(rèn)為業(yè)務(wù)用例圖有蠻多不足，但用例和用例圖絕對是uml&rup的精髓。通過用例圖、角色和系統(tǒng)邊界識別用例是行云流水般的思考，遠(yuǎn)遠(yuǎn)優(yōu)于傳統(tǒng)的需求規(guī)格書，我很享受這種過程，能夠充分體會用例之美之優(yōu)雅。

關(guān)于未來

火星人陳勇：應(yīng)該這么說，我（們？）正在嘗試消滅功能模塊，只留下業(yè)務(wù)用例，把業(yè)務(wù)用例作為分析、設(shè)計(jì)、開發(fā)、測試、驗(yàn)收的共同單位（很類似BDD或者FDD吧），因此”留下“的東西要繼承”砍掉“的東西的一些特性。?(5月21日 13:44)
? ? ? ? ? ? ??? ? ?agile123：UP、OUM、Taij/UDD等都是用例驅(qū)動的，而ATDD、BDD加用戶故事的意思其實(shí)差不多，但后者受極限派影響是不敢或不便提UseCase的，這就是科學(xué)家之間的門派之爭? 火星人陳勇：哦，不是這個意思，我是說比如在百度”用例圖“前三張，（作為外行）是否能看出里邊缺少了什么用例？包括他畫在別的圖里邊的。利用一種新的東西（其實(shí)還是用例圖的變形，但配合了FPA、MVP），我現(xiàn)在就能找到缺少的東西，甚至能告訴他缺少的東西叫什么好。這個以后再揭秘。?(5月21日 13:52)
火星人陳勇：如果有一種圖，圖中的元素大小相近，而又能分層把不同顆粒度的……是不是更好？我稱之為有根有葉樹，有根就是你說的整理地非常有條理，有葉則是存在一種大小相似的東西（自然界同種的樹尺寸差別很大，但葉子卻差不多），作為最終需求、估算、設(shè)計(jì)、開發(fā)、測試、驗(yàn)收、度量用。
火星人陳勇：在我們看來，用例和用戶故事史無前例地采用”條目“而非大段文字表述需求，已經(jīng)達(dá)到”歷歷可數(shù)“的狀態(tài)，可惜數(shù)完了卻被告知尺寸不一，因此無法把用例放在分母上得到生產(chǎn)率、缺陷率、測試覆蓋率……等，實(shí)在可惜。若此問題被克服了，將對用例的價值有很大提升。但這就要動用例的一些規(guī)則。?(5月21日 14:00)
火星人陳勇：等回頭看”用例-狀態(tài)圖“吧，10分鐘教學(xué)，10分鐘練習(xí)（之前不用任何UML基礎(chǔ)），6個團(tuán)隊(duì)繪制6張他們的圖，一般有2張圖我找不出漏了什么，2張圖漏東西，1張圖慘不忍睹。?(5月21日 14:03)
火星人陳勇：我做下一個月迭代的時候最關(guān)心的是：”這一大堆用例里邊，哪些拿出來，正好滿足兩個條件：1. 開發(fā)出來的東西完整可交付（不多，不少，MVP）；2. 正好一個月開發(fā)完（可估）。“1. 需要能看到用例之間的一種依賴、內(nèi)聚關(guān)系，包含、擴(kuò)展沒用；2. 需要有相近顆粒度和生產(chǎn)率?(5月21日 14:14)

火星人陳勇：圖先不著急，我可能要自己繪制超過100張才會有足夠穩(wěn)定的圖發(fā)布。但在發(fā)圖之前，我想知道有沒有人和我一樣感受到用例圖的4個問題（或者對現(xiàn)有解決方案不滿意的地方），以及有何嘗試。就像現(xiàn)有的UML會限制思維，我的圖也一樣。?(5月21日 14:21)
火星人陳勇：給個提示：2月份和一個資深朋友聊，我說我喜歡用例，因?yàn)楹陀脩艄适隆⒐δ茳c(diǎn)能做很好的對應(yīng)。他說他會先畫狀態(tài)圖，因?yàn)榭梢圆欢嗖簧俚胤治龀鲇美?#xff08;狀態(tài)圖的線條其實(shí)就是某些用例），我大吃一驚……1個月后，就有了我說的那張圖。?(5月21日 14:27)
火星人陳勇：@UMLGreatChina?@張克強(qiáng)-敏捷307?@敏捷123?我當(dāng)前正在同時使用UML，FPA，用戶故事，BDD四者管理需求。我個人感覺與其討論“哪個更好”（到處都是），不如取長補(bǔ)短。所以要去掉三個，留下一個。所以現(xiàn)在說的“找缺點(diǎn)”，不是說找到缺點(diǎn)把UML扔掉，而是留下并改造它，去掉另外幾個。?(5月21日 16:32)
? ? ? ?UMLGreatChina：這思路不錯，UML、UseCase、UDD完全可取代用戶故事和BDD? ?? ? ? ? ??火星人陳勇：UML的戰(zhàn)線最長，工程化程度最高，因此作為一個基礎(chǔ)在其上擴(kuò)展比較容易（甚至有時候是做減法），其他幾個都是點(diǎn)狀的，無法承載“過程”“模型”等這些詞匯；不過不改造還是有一些不足。
? ? ? ? ? ??UMLGreatChina：的確這是一個技術(shù)路線問題，這些年OO方法技術(shù)一直是主流 火星人陳勇：回復(fù)@張克強(qiáng)-敏捷307:嘿嘿，下次見面我畫個“用例-狀態(tài)圖”，體驗(yàn)一下跟頭云的感覺。不過最近想和精益的MVP（最小可用產(chǎn)品）結(jié)合一下，從外界重新分析一下，也重新命名一下。MVP聽名字就比“用例-狀態(tài)圖“外向地多，商業(yè)地多，有價值的多，視野開闊地多。
火星人陳勇：回復(fù)@張克強(qiáng)-敏捷307:長相更像用例-活動圖，因?yàn)榘l(fā)生在用例之間而非之內(nèi)，所以叫用例-狀態(tài)圖更妥。此圖用來找出用例；繪制完成后會知道”完成了“；兩個人繪制的圖幾乎一模一樣；平均每張圖開發(fā)工作量35人天；看著圖能寫出測試用例（群），還能知道寫完了沒有；每張圖是一個迷你MVP，必須完整發(fā)布……

結(jié)語

張克強(qiáng)-敏捷307：?說了這么多，其實(shí)還沒有直接回答原博主的提問。我來回答下吧：在敏捷環(huán)境下，如果只使用用例表達(dá)需求（不聯(lián)合使用用戶故事），那么圍繞用例必須的文檔是用例圖和用例規(guī)約（不一定要正式的）+數(shù)據(jù)字典。 其它的不是必需的，依賴于團(tuán)隊(duì)對UML和OOAD的認(rèn)識和水平，但就算團(tuán)隊(duì)對UML和OOAD有很高水平, 見續(xù)
張克強(qiáng)-敏捷307：?如果把以上提到的全寫了，覆蓋所有類，而且沒有一個強(qiáng)大的支持正反向工程的UML工具，那么多半是不敏捷了。?(10秒前)

其它

袁斌_AgileDo：我目前在需求的分析中，主要是把需求分為系統(tǒng)級需求、架構(gòu)級需求、開發(fā)級需求，不同級別的需求在不同階段完成，其中前兩個在先啟階段完成，后一個在構(gòu)建階段提前一個迭代完成?(5月22日 09:31)

總結(jié)

以上是生活随笔為你收集整理的关于用例需要多少文档以及业务用例等等的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。