遇上用例驅動的團隊

作者：江南白衣，原文地址：http://blog.csdn.net/calvinxiu/archive/2007/03/26/1541106.aspx，轉載請保留。

    就像小說裡那些早慧的少年，很早就嘗試過用例驅動的需求文案，結果與客戶，一個愁默默，一個恨綿綿。 

    最狂熱的用例編寫者也承認，用例對客戶與需求人員都是一種heavy的相互折磨。
    客戶看用例時總要收攝心神來閱讀整個互動的流程，還有那些該死的擴充流異常流，沒經過程式員專業抽象訓練的客戶，對著這些虛擬碼一般的情景指令碼，剛開始的一兩個還好，看多了，就是白天也能睡去。客戶只是看都如此了，負責寫的人當然也不會好過。

    但heavy的工作總有heavy的好處，否則早被唾棄於舞台的背面。
    在使用者的角度，用例比模稜兩可的功能點描述要清晰，也更直白於系統的價值。
    在Team Dev角度，RUP的核心方法論之一---用例驅動的口號，明白人自然明白它的妙用。
    設計人員的新設計手段：“用時序圖分析用例的實現，在描述過程中確定構件或類，分配它們的職責和方法”，通過對用例覆蓋率的追蹤，需求與設計之間的資訊損耗這個famous problem大大降低。
    測試人員和文檔人員，更可以直接把系統用例笑納為《測試案例》和《使用者手冊》。

    來到億迅後，被這裡的用例文明給震住了，每個項目的軟體規格說明都是屯門清一色的幾百頁的前景，用例規約，商務規則，詞彙表，補充規約組成.......難得有情郎啊。

    昨天又看到了一批新的用例誕生，但實在有好些明顯的不足啊，忍不住舊事重提的記下一批經典的錯誤。不過.....只要能和客戶達成需求共識，就是一份好的用例了，也不用花太多時間在學術性的討論上。

    1.客戶沒有能力閱讀用例
      如果客戶實在沒辦法撐住困意看完用例的細節，即使草草簽了名，得不到使用者真正確認的用例，依然無法用來驅動設計和測試。
      解決方案：放棄編寫用例，改回使用者容易看的傳統方式。

    2.團隊沒有能力實現用例驅動
      如果Team Dev在設計與測試時，根本不依照用例細節驅動，那用例對Team Dev就只是個擺設，花瓶。
      解決方案：對設計、測試人員進行用例驅動的培訓，如果事不可為就乾脆放棄，怎麼省事怎麼做。 

    3.在用例中描述系統內部工作
      經典錯誤，開發人員把用例當作設計文檔來寫，如“系統將銷售資訊寫入資料庫”，實際上應該寫的是“系統記錄銷售”。
      解決方案：站在客戶的角度，把系統視為黑盒，刪除所有內部設計描述。

   4.在用例中描述介面
      另一個經典錯誤，不說了，如果在意使用者資訊包括了姓名和密碼，可以在詞彙表裡記錄，而用例寫成--顯示<使用者資訊>。

    5.在用例中越出系統邊界描述整個商務程序
      要建立的系統只是整個商務程序裡的一部，善良的需求人員為了大家清楚來龍去脈，將系統外的處理步驟也寫進了用例的情景。
      如：
      1.使用者去營業廳開戶
      2.使用者撥號接入
      實際上去營業廳開戶不屬於寬頻接入認證系統的職責。
      解決方案：開戶的描述應該放到用例的前置條件中。前置與後置條件是說明系統邊界外的商務程序的好地方。 

  6.過多的用例，讓人暈菜
      國外的慣例，一個用例一般有半個以上人月的開發量。
      解決方案：
      1.開戶，銷戶這樣的CRUD型用例可以合并成一個管理用例，以四個主情境分別表達。
      2."老闆問：你每天做什麼阿?"，"我每天登陸系統"。這就是用例沒有提供足夠價值的明顯標誌。
      3.用例中的每一個步驟，其實都可以寫成一個獨立的用例，分 or  不分？這是個問題。
      4.用例的打包組織是一門藝術，混合的按照功能包、頂級目標用例，Actor，Team Dev或者版本號碼等等。

   7.過多的擴充事件和例外狀況事件流，讓人暈菜
      即使是受過訓練的程式員，2a, 3b1看多了也要暈掉，記住閱讀者是人而不是機器。    
      解決方案：
      1.如果邏輯不多，可以一句話講完，不影響主情境的，不建議新起一個事件流。
      2.可以使用活動圖表來輔助說明。在RSM7.0的模版裡，每個用例都會帶上一個活動圖表。

    8.過多的關係，繼續讓人暈菜
     “不要花一個月的時間去討論應該include還是extend”。大家對include, extend and generalize都不熟悉，那就乾脆都不要用了。   

參考材料：
    《編寫有效用例--Wriging Effective Use Case》Corkburn 2001，大家現在使用的用例模版都是他創下來的，此書無可替代。
    《用例模式與藍圖--Use Cases Patterns and Blueprints》我覺得比另一本名字相近的《Patterns for Effective Use Cases》要實用一些。