搜集使用者故事

一、傳統方法與敏捷方法的區別：

        傳統方法的特徵是過分強調在項目早期正確地擷取並寫出所有的需求；

        敏捷項目的特徵是沒有一種理想的方法可以在一個單一階段擷取到所有的使用者需求。

二、項目開始時使用者故事整理到什麼程度：

        四個字，夠用就行。可以也要在項目開始前儘可能多的寫出使用者故事，但並不是要在項目開始前要花費幾個月的時間去寫使用者故事，相反，它要求大家展望未來一個 發布時間，故事發布的時間越往後，我們就不在需要詳細的寫這個故事，可以用一個預留位置來表示，比如：客戶說想要一個報表功能。不需要詳細的去描述這個功能 （如：用什麼樣的方式來實現）。

三、捕捉使用者故事：

      不同大小的網用來捕獲不同的大小的需求，第一遍，我們可以用大網眼的網撈一遍需求池，來得到所有大的需求，通過這些大需求對軟體形成整體的感覺，接下來使 用網眼稍微小一些的網再來撈一遍，可以得到中等大小的需求，在開始還沒有必要顧及那些小的需求。（可能會漏掉一些需求，但不要再去花費的時間捕撈了）

四、故事的重要性：

     也許在捕撈的時候會漏掉一些需求，因為這個需求對軟體來說不是很重要，故事像魚一樣，會長大，也會死亡，根據每輪的迭代的反饋，會向事先不可預知的方向發展，有些需求可以會變的不在重要，甚至已經沒有用了；以前漏掉（認為不重要）的需求可能會變的越來越重要。

五、捕捉使用者事故的方法：

1）使用者訪談：這可能是每個團隊都想要的，與客戶面對面的交談。訪談成功的關鍵在於選擇正確的受訪者，儘可能的訪問真實使用者，還應該訪問擔任不同角色的用 戶。與使用者交談時，不要認為使用者想的就一定是對的，也許你的觀點、做法比他想到的要更好，讓他更加的滿意。交談的方式也很重要，我訪問時，儘可能的使用開 放式問題，不要使用封閉式的問題。最好從與背景無關的問題開始問起。如果從具體的問題開始提問，很可能會漏掉很多故事。不要讓受訪者對你提問的問題只有回 答 “是” OR "否" 、“對” OR “不對”、“行” OR “不行”。

2）問卷調查：如果需要等到大量使用者關於某些具體問題的回答時，是非常有用的。但是它局限了使用者的想法。如果可以讓使用者可以自由的回答就很難歸納多個回答。不可以做為捕撈故事的主要方式。

3）觀察：在觀察別人使用自己做的軟體時，自己會獲得很多提高使用者體驗或生產力的想法，不幸的是這種機會少之甚少。所以造成不要錯過任何可以看使用者使用你軟體的機會。

4）故事編寫工作坊：是開發人員、使用者、產品客戶和其它對編寫故事有協助的人共同參加的會議。在工作期間，參與人員儘可能多的 去寫故事（不分優劣好壞），不排優先順序，最後讓客戶去排優先順序。故事編寫工作坊是快速故事最有效方法，至少在開始每個計劃發布前舉辦。這個雖然好，也沒 有必要在整個項目中舉辦太多的故事編寫工作坊。故事編寫工作坊中的討論就在較高層面上，我們的目的在短時間內寫出更多的故事，而不是設計怎麼做，怎麼來實 現。

5）示範：與觀察相同，在為別人示範自己所做的軟體時，可能會感受對其中一些用的不爽的地方，觀看者也可以在第一時間提出對這個功能更好的建議。第一時間獲得使用者的反饋

五、小結：

      1） 能夠引出及捕捉需求這一想法是錯誤的它有兩個有問題的假設：使用者知道所有的需求，需求一旦被捕捉，就鎖定，不再改變。

      2）拖網捕魚的比喻是有用的：它說明了需求有不同的大小，需求會隨著時間的推移變化，需要一些技巧來發現需求。

      3）即使敏捷流程支援需求的後期湧現，依然需要對預期的發布進行展望並開始寫下容易發現的故事。

      4）我們可以通過使用者訪談、觀察使用者、問卷調查、為使用者示範和舉辦故事編寫工作坊來發現使用者故事

      5）使用多種方法比過度使用一種方法更能獲得好的效果。

      6）通過開放式、與背景無關的提問更容易獲得有用的答案，例如：“告訴我你想要怎麼搜尋工作？” 就勝於 “你要通過職位來搜尋工作嗎？”。

六、開發人員職責：

     1）負責理解並使用多種技巧來捕撈使用者故事。

     2）負責知道怎麼使用開放式和背景無關的提問。

七、客戶職責：

     1）負責理解並使用多種技巧來捕撈使用者故事。

     2）負責儘早寫更多的使用者故事。

     3）作為軟體使用者的主要代表，負責和他們多溝通。

     4）瞭解怎麼使用開放式和背景無關的提問。

     5）如果需要關於編寫故事的低碳哥，負責安排並舉辦一次或多次故事編寫工作坊。

     6）負責確保在捕撈故事過程中考慮所有使用者的角色。