敏捷模式中「故事」和「需求」的關係是什麼？

1樓：Mia Tang

舉個栗子：開發初期寫了乙個「完整的」需求文件，後來發現遺漏了某重要需求，對話大概是這樣的：

客戶：看到這些特性都做好了，我才意識到我還需要乙個需求文件裡沒有都特性。

開發人員：既然你想要，就該早點寫下來，怎麼沒寫呢？

客戶：可是沒看到產品之前，我並不知道自己需要那個特性啊。

開發人員：你要是事先能多使勁想一想這些，不就不用等到現在才發現需要那個特性了嘛？

事實上在很多場景下，總會有些需求和設計只在產品開發進行中才會逐漸顯現，前期工作再全面也無法避免。因此在使用 Scrum 時，我們不會在前期投入大量成本去描述需求，做乙份完美、詳盡的需求文件，反之，我們為需求建立「佔位符」（PBI），每個 PBI 代表客戶期待的乙個業務價值。

使用者故事就是用來陳述業務價值的一種簡便格式，適用各種 PBI，主要是為了幫助業務人員與技術人員雙方理解需求，提供乙個理想顆粒度的佔位符。

2樓：湯威

需求對應的是結果。故事對應的是幫助使用者得出這個結果的過程。一系列的流程組成乙個介面，一系列的介面組成乙個模組，一系列的模組組成乙個產品。

不同的場景下使用者使用產品的過程可能不同，但是滿足使用者需求的結果卻只有乙個，就是幫助使用者解決乙個問題。

3樓：

大家說的我都同意，所以我的補充強調我認為最重要的最容易被忽視的「區別」

故事story是粗略的勾勒的需求，它是信！號！卡！，指向真正的需求或者叫故事詳情，怎麼說都好。

而需求就是需求。

這裡隱含了敏捷的乙個要素，就是，延！遲！決！策！

當需求不是被細化的擺放著，而是粗略的STORY的時候，才能更好的表達延遲決策。

首先我們並不在一開始就把所有的東西都想清楚，而是僅僅以STORY的方式跟蹤記錄我們未來要做的事情。

當開發前，我們才去細化STORY故事，把他變成需求。

或者，開發前，我們扔掉STORY，因為它已經不重要了。

see。故事可以幫我們更好的做延遲決策。保證所有的事情是在開發前才定下來的，而且保證我們不會遺漏。

所以這裡，就是為什麼敏捷要用STORY而不是需求去進行需求的管理。

4樓：

敏捷裡面的user story是乙個複合體，其本質就是需求，同時是堅固了業務需求和軟體功能需求兩個部分的內容。

一句話描述的user story 更多的是業務需求，其提出了明確的業務目標和業務價值。而對於user story裡面的詳細描述很多就已經到了功能需求層面，即該user story要完整實現需要涉及到的具體的乙個個功能需求點。