功能需求的用戶故事

Question

由於我們是一家小公司，我既是項目經理又是開發人員。我爲客戶創建的規範包含許多用於描述和定義項目的元素，包括用戶故事以及我認爲需要包括在內的用於定義項目的其他元素（例如，線框，用戶流，站點地圖等）。

如果一個功能說明書「描述產品如何完全從用戶的角度來運作。它並不關心這個事情是如何實現的。它談論功能。「那麼有沒有人看到使用用戶故事來定義網站的功能規範的任何問題？有沒有人真的以這種方式做功能規格？

真的，我試圖提升自己的遊戲的一點點，並且想知道這樣做是否適用於大型客戶，他們可能對功能規範應包含更嚴格的想法，因此可能需要正式的方法。當然，我們的客戶對我們的文檔製作方法有很好的反應。

我有興趣聽取項目管理專業人員對此的看法。

Answer 1

我與其他一些人說過的話不一致。

首先，我認同 - 故事是闡述功能需求的好方法。對於我的錢來說，他們是實際溝通需求的最佳方式之一，最終用戶將會真正接受。我已經看到太多的規格說明，但沒有被閱讀過。

我想說的你可能想追加的一件事是非功能性需求 - 包括性能，安全性，數據量，審計，歸檔等。雖然他們可以用故事來報道，但有時他們可以更好地覆蓋所有故事。

就是否適合大公司而言，這是我不同意的地方。根據我的經驗（我已經爲殼牌，美國運通，多家跨國銀行和其他公司做過項目），他們通常不會比小公司更正式，所以他們會講故事。現實情況是，大公司的用戶在閱讀課程和時序圖時比其他地方沒有更好的配備（或感興趣）。

項目的規模和複雜性可能需要更詳細的要求，但它是項目的規模，而不是公司決定如何記錄需求的重要因素。

對我來說，最好的需求文檔就是適合它的讀者的文檔，對我而言，用戶的故事大多數時間都是頭疼的 - 它們足夠短並且足夠清晰，當它們簽名時它們意味着因爲他們已經閱讀並理解它們（而不是簽署100頁的規範，這總是意味着他們沒有真正閱讀它），但對於開發人員來說也是足夠好的。

Answer 2

是的，您可以使用用戶故事來滿足您的功能需求。我一直這樣做，並且已經有很多年了。在我看來，它工作得很好，比我用過的其他系統更好。

此方法適用於大客戶嗎？爲了總體概括，沒有。他們將有一些用於定義需求的系統，可能不是用戶故事。如果您使用用戶故事，將會與目前的做法脫節，您將不得不努力。

我已經成功地在大型組織中使用用戶故事，但需要雙方共同努力，雙方需要致力於此。

Answer 3

您所描述的是定義功能的用例場景，這是從可用性角度來看所需要的，並且正是客戶理解和同意的內容。屏幕實體模型和流程圖將明確幫助客戶和開發人員。

然後可能需要一個實現規範來指導開發人員需要包含在實際構建中的什麼，深度取決於開發人員的能力，包括他們對房屋結構/框架和方法/慣例的知識並可能包含對應用程序的各個部分有何影響的具體內容。

我們也在小團隊（有時是一個或兩個開發人員）工作，並認爲以上是在這種情況下所需要的。

規模較大團隊的較大型公司可能會使用建模軟件，UML圖表和其他更詳細的規範。如果您是主要開發人員，您仍然應該花時間設計您的應用程序，但如果沒有人會審查設計並堅持所有手續，那麼您的時間最好花在實施軟件上。