從這個例子我們可以想象到，這個頁面可能存在兩個文本框，用于輸入用戶名和密碼，有一個按鈕來登錄，并且不登錄就不能看到個人資料，另外，如果用戶輸入錯誤需要提示"登錄失敗請重試"。這就是可見性，也可以稱為可測試性。我們可以根據這樣的可見性寫出功能測試，從而驅動這個用戶故事的開發，這被稱為 Acceptance Driven Development。
用戶故事的作用有兩個，一個是作為進度跟蹤的依據，一個是作為與人交談的備忘錄。用戶故事卡片并不是很精確的需求，因此不需要把事情描述的非常清楚。將需求的詳細分析推遲到實現前夕來完成，這是敏捷需求分析的精華所在。任何提前做好的東西都會導致浪費，敏捷過程提倡足夠就好，避免浪費。
不少人對用戶故事和用例的區別感到疑惑。用戶故事的作用是備忘功能，而不是文檔。而用例需要詳細的描述其操作步驟，以及每個異常路徑，因而起到了文檔的作用。用戶故事是可見的商業價值，而不是功能描述。每個用戶故事的粒度和工作量都相差不多，這和用例有很大的區別。用戶故事是小粒度的，可測試的，可見的，并且是有價值的。
ThoughtWorks有個項目組作的是一個網游物品交易 平臺。該平臺是典型的 互聯網項目，在開工的時候客戶對功能需求還不明確，但需要快速推出搶占市場，正是最適合敏捷過程的項目。
在項目伊始，商務分析師和客戶做了深入的談話，了解他的商業構想，他的盈利模式，搞清楚宏觀的結構，然后思考并整理獲得的結果，花1-2天時間將客戶需求大略整理為幾十個用戶故事。這些用戶故事并不完善，不足以做好整個系統。但對于我們開始項目的前一陣，已經足夠了。我們可以從這里開始項目。
敏捷方法希望快速交付可用的軟件。實現軟件的快速交付是通過迭代來完成。在迭代開始前，由一組有經驗的開發人員大致評估一下用戶故事，標記出不同的難度和 風險，并提出問題供商務分析師來獲得更詳細的信息，商務分析師會和相關涉眾去討論。然后商務分析師將推薦優先級最高的一組用戶故事給客戶來挑選，客戶可以選擇這些用戶故事，或者指出從他的視角看到的優先級更高的用戶故事。這些將成為下一個迭代的內容。
客戶看到每個迭代交付的可運行的軟件后或者得到用戶反饋后，常常會有新的想法冒出來。有些想法是好的，有些想法就屬于看到別家網站有這個功能，不假思索的提出的功能。這些不同的需求都需要經過認真的分析，找出哪些是值得我們立即考慮的，哪些是不用急迫的去實現的。
有一次和客戶談話時，他說到希望增加拍賣功能。那么，我們為什么需要拍賣呢？客戶說希望讓用戶拍賣物品以獲得最高價格。經過考慮，我們發現，網游物品的實時性和唯一性決定了系統不適合使用拍賣機制。拍賣的時效性無法滿足實時交易的要求，因此，用戶最終放棄了這個特性。
另一次，客服人員提出增加一個查詢用戶交易的功能，而此時我們有其他更加重要的功能需要先去考慮，查詢用戶交易功能可以由技術人員臨時通過數據庫直接代為查詢，因為項目運營初期交易不是很多，暫時還不需要專門的后臺功能來支持客服的工作。所以把這個需求卡片一直貼在墻壁上，始終沒有排到最高的優先級。
客戶一開始也不是很能夠接受敏捷需求中強調商業價值和優先級的做法。但經過幾個月的磨合，客戶也逐漸適應了許多敏捷思想，甚至我在和客戶討論時，偶然提起了后期的某種可能的情況，他們還能夠幫我糾正應當考慮目前的情況，為近期的情況作計劃。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
