敏捷開發必須要通過用戶故事來溝通嗎？

01-25

我們公司技術老大一直在推行敏捷開發，經常開會跟我們講項目管理，要求產品必須輸出用戶故事，不需要原型圖，寫用戶故事也不能從原型出發。
　　我來公司不久，以前都是出原型圖和需求說明文檔的，一時間還不太會寫用戶故事。有時需求已經明確了，但是由於故事沒通過技術老大的審核，而不斷改故事，比如用詞問題，比如有的故事應該拆開有的應該合併，有的例子沒有夠……
　　推行敏捷開發沒有錯，但是我還是不太明白，敏捷開發跟用戶故事，是有必然聯繫的嗎？一定需要對於文檔要求如此嚴格嗎？

&>&>我們公司技術老大一直在推行敏捷開發，經常開會跟我們講項目管理，要求產品必須輸出用戶故事，不需要原型圖，寫用戶故事也不能從原型出發。

你們老大在瞎扯。

&>&>敏捷開發跟用戶故事，是有必然聯繫的嗎？

沒有必然聯繫。用戶故事是 Kent Beck 發明的，只與 XP（極限編程）有必然聯繫。

其他敏捷方法和流派大多主張用 Use Case（用例故事），如 UP、Crystal、Taij/BP 等等，而 Scrum 對此中立，用戶故事可用可不用。

敏捷開發的框架是針對開發過程來說的，所以其實對於產品來說，在進入敏捷開發流程之前，就應該輸出原型了，UI應該也輸出稿了，並且團隊都過過稿件，對產品有了基本一致的理解。

可以參照《啟示錄》中間有關敏捷開發和瀑布式開發的部分。

是不是用用戶故事作為需求文檔並不重要。重要的是每個需求要清晰的表述出以下幾個內容：

做這個需求的目的，目標和價值
該需求解決了什麼用戶問題
該需求的主要用戶是誰
用戶在使用這個功能的時候遇到不同場景系統會給予什麼樣的反饋

故事目的不是為了取代原型圖，所以沒有說一定要用故事，堅決不用原型。就像用戶故事的格式一樣，as a user, I want ... so I can ...，故事中要說明用戶想要的功能，以及需要該功能的目的。而其中，用戶目的才是關鍵。

原型圖的一個劣勢時沒有辦法清晰的表達出用戶目的，但是原型圖在表達功能時卻比用戶故事要好。兩者是相互補充的。

為什麼用戶目的重要，可以參考《About Face》中關於「用戶目標驅動的設計」的內容。

用戶故事比較粗——注意不是故意把已經細化的需求寫粗寫成故事，而是當需求獲取到價值清晰的時候就停下來，不再追求必須完全細化——當故事傳遞到開發環節的時候，通過開發人員對故事的理解和提問，完善開發需要的細節，產生「拉動」需求的效果，這樣避免了在需求獲取和分析、設計階段的時間消耗，從而達到「快」的效果。

所以，如果已經投入了時間完成了需求獲取分析和設計，回頭為了搞故事而搞故事的確很麻煩。

另外，看上去題主還在煩惱老闆對故事的偏好和要求，其實即使能證明這事兒不靠譜，貌似寫故事這事兒你還是得做。所以倒不如把重點放在「寫出老闆滿意的故事以便於交差」罷了。

遇到一樣的公司一樣的領導，現在也很糾結。

關鍵是不對需求做管理，直接需求過來就錄入Story，沒有產品規劃

敏捷是方法論，有一系列的原則和指導思想提倡你在軟體工程中去遵守。你可以在開發中採用已被廣泛認可的最佳實踐，比如scrum方法中提倡的各種項目管理實踐，XP方法中的TDD，結對編程等實踐。
在需求實踐上目前流行的是用例和用戶故事，但現在國內熱火朝天鋪天蓋地全是用戶故事的討論，並且有一種趨勢就是似乎陷入了敏捷就等於scrum的錯誤觀點中，實際上scrum主要強調的是在項目管理的價值和實踐，在需求、設計和實現上沒有做出更多的指導。
但是需求在項目的計劃和迭代，以及對項目成本的估算上是必不可少的，所以作為在需求上實踐的補充，你可以使用用戶故事，當然你也可以使用用例，只不過在將用例轉化為計劃的時候會有點難度，需要對用例有較為深刻的理解。
我推薦使用用例來捕獲，發現，記錄，組織和跟蹤需求，這也是RUP方法中推薦的，雖然有一定難度，但是是非常值得的。我不推薦使用用戶故事，用戶故事有它的優點，但也有局限性。
結論：敏捷開發不依賴於用戶故事，不是必須要通過用戶故事溝通的。

用戶故事與原型圖沒有衝突，用戶故事與其他需求方法也沒有衝突。

與其他需求梳理方法相比，只是用戶故事的一些特點更適用于敏捷開發適應的場景：需求不是很清晰就需要進入開發；需求變化頻繁。如果較長時間實踐了用戶故事方法，你就會發現用戶故事用在敏捷迭代開發中，作用與成效很大，不止局限於需求方面。

推薦你看下《用戶故事與敏捷方法》這本書，我剛看完，會學到很多知道，我還希望有機會可以用下這種敏捷開發，不要有抱怨也是學習的一種，努習學習吧

我個人覺得，輸出什麼東西並不重要，只要保證大家（產品、開發、測試等）都能看懂並且達成共識就行了。如果對於流程及內部輸出物規定得如此死，還談何敏捷開發呢？