在他的文章What's in a Story BDD創始人Dan North似乎使用Story來代替Feature，而且這不是我見過的用戶故事/以前可互換使用的功能。爲什麼這對我來說尤其令人困惑的是，我在一個使用Jira/Greenhopper的團隊工作，所以我們使用Scrum來進行看板。 Scrum有它自己的術語，用戶故事正好在這個術語集中。Scrum用戶故事與功能相同
所以我的問題是：Feature/UserStory Dan North是指與Scrum中的UserStory相同嗎？
如果它不是那麼（修辭）「爲什麼這樣使用它」？
我想這是有爭議的，如果用戶故事是（或應該）總是緊密相關的功能，反之亦然。
但是，根據定義，用戶故事是而不是的一個功能。他們是不同的東西。
在軟件開發和產品管理，用戶故事是在一個系統的最終用戶或用戶的日常或商務語言中的一個或多個句子，抓住什麼是用戶確實還是需要做他或她的工作職能的一部分。
「一個軟件項（例如，性能，便攜性，或功能）的一個顯着特徵。」
這是真正開放和模糊軟件功能如何可以被描述，而不是一個用戶故事。一個用戶故事應該尊重目的的特定格式：可先回答什麼，當，其中，誰和/或爲什麼在用戶故事（取決於你認爲哪種格式）。
IMO，如果你已經在使用用戶故事，你不應該打擾這種關係，只要確保你的用戶故事寫得很好。
我們一直在撰寫用戶故事，但由於BDD，我們想要進一步確定我們撰寫的故事還支持某些功能。但正如我所說：即使是BDD的創造者似乎也可以互換使用兩者。 – 2013-03-06 20:24:35
此外，我同意你提供的鏈接，我相信一個實際的功能應該是一些簡潔的（1-3個字）描述系統或軟件級別的功能。在我看來，像「數據持久性」這樣的描述性特徵。因此，無論我正在處理的是什麼業務域對象，如果需要以某種方式持久保存，它們的場景將與數據持久性功能相關聯。那個聽起來是對的嗎？ – 2013-03-06 20:26:38
這可能是爭論的焦點，但我會考慮一個功能是分組一個或多個故事的一種方式。例如，你可能有一個特點「圖片上傳」它由兩個故事：
我一般認爲這個'特徵'就是企業/顧客最初如何描述行爲。一旦你接近構建它，然後你將它分解成故事，以便優先考慮和估計。
那麼您是否使用用戶故事在Kanban板或類似的項目管理工具上顯示爲您的WIP？ – 2013-03-06 18:46:23
是的，故事應該是工作單位。如果您使用的是時間盒式過程，那麼您通常會在每年春季發佈多個故事，但它們可能是從不同功能中選取的故事。 – 2013-03-06 19:21:15
這是你所做的一個有趣的陳述。我認爲這就是Scrum中的Epics有用或被使用的原因。從我所瞭解的Scrum Epics聚合用戶故事（其中，正如您所說，可能與幾個「功能」相關）。 – 2013-03-06 20:29:06
如果你看看Scaled Agile Framework，那裏的傢伙把各種不同類型的工件放在一起，包括Epics，Features和Stories。它也映射到組織內的不同級別，這非常酷。
在我的使用中，功能比個人故事更大，在組織的更高層次上進行跟蹤，並且通常會參與發佈計劃以指定給定發佈中的內容。
故事是我們用來描述該功能將被使用的場景，以便我們可以構建功能以支持與功能相關的所有故事。
我認爲這跟我昨天在這篇文章（http://blog.mattwynne.net/2010/10/22/features-user-stories/）中讀到的內容相符：「用戶故事是一個規劃工具。它們存在直到它們被實現，然後它們消失，並被吸收到代碼中。「這與您所說的內容有關，因爲它確實是實現該功能的場景，但我們需要一些顯示包含場景的WIP的方法，這些場景本身代表要執行的功能。 – 2013-03-07 15:24:47
不要迂腐，但最新版本的Scrum指南不提及用戶故事。它指的是產品待辦事項項目。用戶故事是從XP借用的術語。 – 2013-03-07 11:39:36
@DerekDavidsonCSPCSMCSPO無論如何，要迂腐。德里克，你已經爲此付出了很大的努力。至於我，我來自XP的商店。我負責更多地瞭解BDD以及如何與Jira一起使用。所以我正在與我的小三人團隊一起進入Scrumban領域。根據你的個人資料，我知道這對純粹主義者來說可能是不能容忍的）。乾杯。 – 2013-03-07 15:40:31
我投票結束這個問題作爲題外話，因爲它是關於項目管理和詞的意思，而不是編程。 – TylerH 2017-11-03 01:33:15