使用者例事
使用者例事（user story）用於描述使用者通過系統完成其乙個有價值的目標。使用者例事只是以客戶能夠明白的方式，描述了乙個系統的外在行為。而像產品採用何種語言實現、採用何種架構、哪種資料庫等則不應該包含在其中。使用者例事不應該太長太大，乙個籠統的使用者例事可以和一些作為補充的使用者例事聯絡起來。只要乙個使用者例事最終覆蓋所有需要的細節，那麼它就不需要再進行分解。
建立乙個使用者組來隨時跟蹤和確認使用者的需求，應該包含測試人員、開發人員、專案經理、客戶代表、ui設計師等。使用者例事由使用者組來完成，在編寫使用者例事的時候，應該採用頭腦風暴的方式，盡可能多的編寫例事。之後，由程式設計師對每個使用者例事進行評審，確認例事的尺寸（乙個使用者例事應該能在半天到兩個星期內完成）。
由使用者組和開發者一同指定每一次迭代的週期。在本次迭代結束的時候，開發者負責交付所有的**、開發文件和測試用例，而使用者組負責確認本次迭代是否朝著預期的目標在前進，一次迭代完成整個系統的一部分。
例事點
專案開始的時候，會由開發者**一次迭代可以完成的工作量，並把這個工作量叫做「velocity」。每次迭代完成的時候，都需要根據實際完成的情況對velocity進行調整，一次迭代中實際包含的使用者例事個數也需要根據velocity進行調整，確保每次迭代中包含的使用者例事都能夠完成。如果無法完成，則將無法完成的例事調整到下一次迭代中，甚至調整到下乙個版本中。下次迭代中包含的例事數量也需要根據velocity的值進行動態調整。
每次迭代開始的時候，由開發者和使用者組一起確認那些是重要的必須優先實現的例事，並將這些例事優先放入當前的迭代中。三種情況下的使用者例事是應該被優先實現的：
大部分使用者廣泛需要的。
少數但是是重要使用者需要的。
其他高優先順序例事依賴的。
在提高乙個使用者例事的優先順序的時候，必須仔細考慮這個使用者例事的成本，這個成本用例事點（story point）來表示，衡量這個例事本身的複雜性，以及和其他例事之間的依賴度，值越高表示實現這個例事需要花費的成本越高。注意，不要將乙個例事點大於專案組velocity的例事分配給乙個專案組。
例事卡
用來記錄乙個使用者例事及其例事點的卡片叫做例事卡（user story card）。例事卡上應同時註明使用者對於這個例事工作時的期望，例如能否和如何處理輸入異常。這些期望可以用來作為測試和程式設計的指導。
例事卡上只需要乙個簡單的描述，具體涉及到的細節應該在同使用者的討論中得出，以注釋的方式記錄到例事上（也許是背面），這些細節討論出來後應該形成測試使用者。注意，注釋不要太多，假如乙個例事擁有太多的注釋，那麼將注釋中的內容抽取出來形成新的例事；或者將此例事拆分。
用例2 0及敏捷軟體開發
正在構建大型複雜系統的企業正在逐漸遠離傳統的瀑布式開發，轉而採用敏捷流程。這使我們想知道用例如何適應敏捷過程，特別是敏捷關注使用者故事。由ivar jacobson，ian spence和brian kerr開發的use case 2.0是使用者故事和scrum和kanban的敏捷方法開發的新一代用...
敏捷實踐 使用者故事和用例的選擇
使用者故事描述了對軟體 或系統 使用者或客戶有價值的功能。使用者故事包括三方面內容 書面描述 用於計畫和備忘 交談 細化故事細節 以及測試用例 驗證故事實現 使用者故事描述的傳統形式是手工書寫的使用者故事卡，ron jeffries 稱如上三方面內容為 card 卡片 conversation 交談...
UML軟體開發與建模工具用例模型
什麼是uml？該物件管理組織 omg 規範規定 統一建模語言 uml 是一種圖形化語言，用於視覺化，指定，構造和記錄軟體密集型系統的工件。uml提供了一種標準的方式來編寫系統藍圖，包括業務流程和系統功能以及具體內容，例如程式語言語句，資料庫模式和可重用的軟體元件。這裡要注意的重要一點是，uml是用於...