Use Story方法

關鍵字：Use Story方法胡亂說說，里面肯定存在著不少的錯誤，還請高手指正。 

Use Stories就是系統要實現的功能。它表述起來非常的簡單，一個Use Stories只需要幾句話就可以寫完。之所以這樣是因為用戶需求的細節是非常易變的，而其高層描述卻是相對穩定的。所以我們可以通過使用Use Stories的方法來從高層確定需要開發的內容，這些單純的Use Story相當于系統中可能的點，而由我們通過與用戶交流所得到的所有Use Stories則構成了一個面，它就是整個系統所需要實現的功能。 

深入思考上面這段話的含義就會發現Use Stories在整個項目的初始分析階段起的作用只是一個占位附。他告訴我們這樣功能在實作的時候應該要實現，但是具體需要實現什么，怎么實現則是在迭代過程中的分析階段所需要的事情。所以在寫Use Stories的時候請切記，一定要簡單概括，不可明確描述實現細節方面的問題。 

說到這里就不能不說一下Use Story與Use Case的關系，我個人認為Use Story是一個更高層的分析階段，它的抽象層次非常的高，如前面所說，它是一個占位符，而在具體對一個Use Story進行分析的時候則可以使用Use Case分析技術，將一個Use Story分解成為若干個Use Case。當然上面這段描述的前提是需要開發的系統足夠的大Use Story對相對較大，一個Use Story可以折分一系列Use Case。但是如果項目的規則相對較小，那么可以直接使用Use Case來取代Use Story，這個在開發的時候需要靈活的掌握，不可死板追求到底用Use Story還是Use Case。 

Use Story中除了包含對功能的簡單描述之外，還可以酌情加入對異常情況的描述。雖然在具體分析一個Use Story的時候還需要將其異常情況進行詳細的列出，但是在撰寫Use Story的時候還是有必要的盡可能的將它們列出，其原因在于，對異常情況的描述可以幫助我們發現一些在正常情況下無法體現出來的Use Story之間的關系。這對我們撰寫Use Story的描述部分是有一定的幫助的，另外也可以在這個初始階段提出一些問題，然后等待進入具體迭代的分析階段時再進行解答。 

Use Story內的描述只是開發者系統的一個最初步認識，所以以后開發者在實際開發時參考這些Use Story時一定要持著一種懷疑態度，再重復一次Use Story只是對高層系統一部分的抽象度非常高的描述。用戶在具體開發的時候應該維護一份Use Story列表，如果在實際開發一個Use Story（或者這個Use Story所對應的某一個Use Case）的時候，遇到了對其它Use Story有影響的問題應該在這份Use Story列表當中標出。以便我們在這些受影響功能進行分析的時候可以盡量多的認識到這些影響它的問題。  

用戶在對Use Stories進行優先級的排序后，這個順序雖然不是在未來完成整個系統的過程中實現Use Story的順序（因為需求是易變的），然而一般情況下這個Use Stories的優先級排序，卻決定了第一次 迭代的開發內容。優先級高的Use Story應該先完成，這是直面風險的一種方式，按照XP的描述來看， 用戶認為優先級越高的Use Story所存在商業價值就越大，當然其風險和不確定性也就越大，所以我們應該先實現它。 

在用戶確定了第一次迭代過程中所需要開發的Use Stories后，那么我們就可以將這些Use Stories分解成相應的任務了，注意，用戶雖然為第一次迭代選擇了相應的Use Sotries，但是這些Use Stories卻未必會在第一次迭代當中完成，因為正如前面所說Use Stories的作用只是一個占位符，我們通過Use Stories所了解的系統功能只是極為抽象的內容，單憑這些內容我們是無法估算出完成一個認識所需要的具體時間的，所以在決定開發一個Use Story的時候需要對這個Use Story進行進一步的分析，將這個Use Story拆解成若干個任務。折解的目的是Use Story所被折解成的任務將都是可以進行開發時間評估的（大小基本可知），只有這樣的任務開發人員實際工作起來才會感覺到心里有數，一個Use Story所表示的抽象范圍比較廣，可以先將這個Use Story折解成若干個Use Case或者更小的Use Story（再強調一次，Use Case要比Use Story的抽象極別低），然后再將具體的Use Case折解成具體可以進行評估的任務。而如果我們對一個任務無法進行評估的話，那么可能就說明我們任務還有細分的余地，我們可以將它拆解成更小的任務（當然這里有一種情況是由于團隊內的開發人員都不清楚任務所涉及到的專業知識，所以造成無法對任務的工作時間進行評估，在這種情況下，可能就需要一個此領域的專家幫忙了，或者如果沒有這樣條件的話，那么開發團隊在經過對這種專業知識的短時間學習后再對任務進行評估？，或者重新評估使用此技術所付出的代價是否可以在一定的成本范圍之內）。 

在對Use Story進行拆解的過程當中經常會遇到的一個問題就是可以從進一步的分析過程當中得到一些淺在的Use Story或者Use Case?？梢詫⑦@些Use Story或者Use Case加入到列表，然后評估其是否有必要被加入到本次迭代，如果有的話，那么一并進行分析，如果沒有的話，那么將其安排到其它的迭代中來完成。 

在拆解任務的過程中，我們應該保持對核心問題的注意力，舉個例子來說，比如說我們要處理一個發送信息到指定用戶的Use Case，這個Use Case核心的問題就是將信息成功的發送到指定用戶處，而在拆解這個Use Case的時候我們發現校驗收件人用戶是否有效的操作也是一個相對比較復雜且工作量比較大的工作，因為它涉及到與帳號系統的配合工作。在這個時候我們所采取的策略就應該是將用戶校驗操作視為完成整個發送信息過程操作當中的非核心步驟，不需要對這個問題太過糾纏。在分析的時候只需要把它當做一步操作，而在實做的時候也只需要定義一個用戶校驗的接口，然后使用Mock對象的技術來滿足發送郵件時對用戶校驗系統的需求即可。 

另外在拆解任務的過程當中還應該注意的一點是，不應該讓我們所能夠承受的復雜度和負載度超標，比如說當我們發現從一個Use Story分解出來的Use Case復雜的足以讓我們不能夠一次對付他們的時候就應該明智的將對Use Story的分析改成對某一個或者某幾個特定Use Case的分析。只有使用客中化整為零，各個擊破的策略才能夠使我們在面對大型軟件的時候保持我們的控制力。  
 
Archie的評價  2004.10.07  
雖然不能準確的對故事進行估算，但是還是要進行估算的，而且團隊的速度也是用故事的度量單位來衡量，而不是任務。 
要進行估算就要對故事進行比較詳細的了解，要和客戶進行大量的溝通，了解到什么程度呢？能進行估算了為止。  

原文轉自：http://www.anti-gravitydesign.com