用戶故事與敏捷方法第一章

第1章  概覽

      軟件需求是一個溝通問題。需要新軟件的人(使用或銷售軟件的人)必須與開發新軟件的人進行交流。一個項目的成功，依賴於很多不同的信息，這些信息來自各有不同的人員：一方是客戶和用戶，有時還有分析人員、領域專家和其他從業務或組織視角來審視軟件的人；另一方是技術團隊。


一旦任何一方在溝通中把持絕對地位，項目就會遭受損失。如果業務方把持絕對地位，他們就會關注軟件功能和交付日期，卻很少關注開發人員是否能夠同時滿足這兩個目標，或者開發人員是否確切地瞭解需求。如果開發人員把持絕對地位，技術術語就會代替業務語言，從而導致開發人員無法傾聽業務方的實際需求。


      我們需要一種協同工作的方法，讓雙方都不佔絕對主導地位，共同面對感情用事和辦公室政治化的資源分配問題。若資源分配問題完全落在一方，項目必定會失敗。如果只讓開發人員來承擔這些問題(他們通常會被告知"我不關心你們怎麼做，但請你們在6月份之前完成")，他們可能會犧牲質量來換取額外的特性，也可能只部分實現一個特性，或者自行做出一些本該在有客戶和用戶參與情況下才能做出的決定。如果只是客戶和用戶承擔資源分配的責任，那麼我們通常會在項目開始時看到一系列漫長的討論，項目中的特性逐漸減少。之後，在最終發佈軟件時，只剩下很少的功能，甚至少於被減掉的功能。


至此我們已經瞭解到，我們不能完美地預測軟件開發項目。當用戶看到軟件的早期版本時，他們會想出新的點子，從而改變他們的觀點。由於軟件的這種不可控性，大部分開發人員都會遇到衆所周知的艱難時刻，估計需要多長時間才能完事兒。因爲這些因素及其他一些因素，導致我們無法勾勒出一幅完美的PERT圖 來展示項目中所有必須完成的事情。


     那麼，我們該怎麼辦？


     一般情況下，我們根據手頭的信息來做決策。我們經常這麼幹。不要在項目開始時就做一套包羅萬象的決策，我們要把各個決策分散在項目過程中。爲此，我們要確保有一個獲取信息的過程，越早越好，越頻繁越好。用戶故事由此應運而生。


     什麼是用戶故事？


     用戶故事描述了對用戶、系統或軟件購買者有價值的功能。用戶故事由以下三方面組成。


     一份書面的故事描述，用來做計劃和作爲提示。


有關故事的對話，用於具體化故事細節。


     測試，用於表達和編檔故事細節且可用於確定故事何時完成。


     由於用戶故事的描述信息以傳統的手寫方式寫在紙質卡片上，所以Ron Jeffries(2001)對這三個方面起了一個非常好的以相同英文字母開頭的名字：卡片(Card)、對話(Conversation)和確認(Confirmation)。卡片可能是用戶故事最明顯的表現，但它並不是最重要的。Rachel Davies(2001)說過"卡片代表客戶需求而不是記錄需求"。這是對用戶故事的最佳詮釋：卡片包含故事的文字描述，然而需求細節要在"對話"中獲得，並在"確認"部分得以記錄。


     故事卡1.1是一個用戶故事的例子，這張故事卡來自假想的職位發佈和搜索網站BigMoneyJobs。


     故事卡1.1  寫在卡片上的用戶故事雛形


     用戶可以在網站上發佈簡歷。


     出於一致性考慮，本書其餘部分的很多例子都將使用BigMoneyJobs網站作爲例子。其他BigMoneyJobs示例故事可能包括下面幾個。


     用戶可以搜索職位。


     公司可以發佈新職位。


     用戶可以限制瀏覽其簡歷的人。


因爲用戶故事代表對用戶有價值的功能，所以下面的例子對於這個系統來說就不是理想的用戶故事。


    這個軟件將用C++語言來編寫。


    程序將通過連接池連接到數據庫。


第一個例子對BigMoneyJobs來說不是一個理想的用戶故事，因爲它的用戶不需要關心繫統是用什麼語言編寫的。然而，如果這是一個應用程序編程接口(Application Programming Interface，API)，那麼系統的用戶(她自己也是程序員)寫下"這個軟件將用C++編寫"的用戶故事則比較恰當。


第二個用戶故事例子在此案例中也不是一個很好的用戶故事，因爲系統用戶沒有必要關心應用程序如何連接數據庫之類的技術細節。


讀完這些故事後，你可能會馬上覺得"但是，等等--在我的系統中，使用連接池是需求之一！"如果這樣，請停一下，關鍵在於故事應該以對客戶有價值的方式寫下來。還有很多其他方法來表示對用戶有價值的故事。第2章將提供相關例子。