我正在處理一個非常複雜的集成需求的項目，特別是接收和發送EDI數據以及發生在兩者之間的所有「有趣」內容。我肯定可以將精力集中在數據處理（驗證，必填字段，轉換）上，但我遇到的問題是如何構建積壓的故事和史詩來規劃和跟蹤工作。在Scrum中集成的用戶故事
很容易說「作爲經理，我可以否認假期要求，這樣我就可以確保我有足夠的工作人員來履行我的承諾。」實際上，我非常擅長這一點，但我對這種整合工作非常陌生。
對於一個大型集成項目，指出用戶是誰以及價值是什麼更加困難。 EDI集成僅僅是接口（非功能）需求，但實現是一項很大的工作。
任何人都可以提供一些指導，說明如何在我正在創建的產品待辦事項中構造/構造這些類型的需求？
Mike Cohn有話要說這一點，我想這最後一段是非常相關的
但是，你要小心不要讓癡迷與該模板。這只是一個思維工具。試圖在這個模板中加入一個約束是一個很好的練習，因爲它有助於確保你瞭解誰想要什麼以及爲什麼。如果最終的措辭容易混淆，請放棄模板。如果你找不到約束的方法，只需用任何方式寫出約束條件即可
感謝您的迴應。你具體哪裏得到這個（我有一船書籍）。我實際上希望有人在他們如何處理這個問題並構建他們的故事方面有一些真實世界的經驗。最終，我會做任何有意義的事情。到目前爲止，我還沒有找到有關該主題的真正優質資源。 – noplay 2013-03-01 16:05:05
我把這句話說得很清楚，因爲它表達了我在使用scrum和寫出大量故事名稱時所看到的每個sprint，並表達了它比我更好。它來自於我在回答中提出的鏈接 – 2013-03-01 16:11:17
我同意你的觀點，「作爲用戶」模板確實不太適合。相反，簡單的函數語句（如「接收EDI文件」）可以正常工作。接受標準仍然可以定義故事的範圍，以便在多次迭代中分解出來，但嘗試使其合理化並不合理。最重要的一點是，你可以調整它的大小，測試它，並使其適應短跑。 – noplay 2013-03-02 00:04:04
Scrum沒有指定需求應該寫成用戶故事，你應該使用什麼技術最適合用於您。如果您正在與「AS A」類型故事作鬥爭，請嘗試「按照我想要的方式」。如果不使用，請使用用例建模。
需求不是合同，而是通信的佔位符。這裏的關鍵是要有足夠的信息用於規劃目的，從而使團隊知道必須完成的工作。細節可以在sprint中討論。
謝謝，這似乎是一個普遍的主題，只有在必要時才使用「AS A」。最終，它可以追溯到用戶價值，因爲用戶可以從服務中獲得價值的唯一方式是通過特定的界面（EDI），這是一個更具操作性的限制（如果您願意的話，這是一個必要的罪惡）。 – noplay 2013-03-05 23:35:21
我在這樣的情況下，做的是：
1）請拿出我們可以實現爲一體的終端到終端的功能，最簡單的一點。
2）試着拿出一個用例是整合
3）翻譯成故事（可選步驟：故事是不是物理定律可以使用，即使他們是有用的。 ）
例如：
1）好了 - 看起來認證是實現一切觸摸最瑣碎的事情。
2）嘿 - 驗證本身是有用的。我們可以用它來知道這組用戶是否可以訪問這些數據。
3）「作爲站點管理員我想，以確保只有經過授權的東西，有機會獲得符，以防止有價值的信息被公開訪問」
這樣，你總是有一個工作的EDI系統 - 它只是涵蓋功能的一個子集。您可以隨時間增長的一個子集 - 希望按照功能對您業務的重要性。然而
我真正偏好是爲什麼的EDI正在做的有點進一步挖。一般不會因爲「EDI」是人們想要的功能。這是因爲EDI是必要的對於系統中的某些其他功能。
在這種情況下，我寧願使用任何需要EDI的東西來驅動EDI層的開發，而不是使用單獨的EDI項目。上面（3）中的故事將來自一個實時項目 - 而且你將更有可能建立你所需要的並避免浪費。
謝謝，是的，我有相同的思維過程，導入和轉換一個更簡單的EDI文件很簡單，或者可能不包含第一個故事的邊緣案例。您將以更快的速度獲得端到端的整合，更重要的是，您可以更快地開始測試下游系統。稍後構建異常情況，其他驗證和複雜映射。 – noplay 2013-03-05 23:33:45
這個問題是無題的，因爲它不在本網站的範圍內，正如[我可以問什麼主題？]（// stackoverflow.com/help/on-topic）中所定義的那樣。我應該避免提問的問題類型？]（// stackoverflow.com/help/dont-ask）您可以在[另一個Stack Exchange站點]（// stackexchange.com/sites#name）上提問，例如[ pm.se]或[softwareengineering.se]。請務必閱讀幫助中心中針對您打算髮布問題的任何網站的主題頁。 – Makyen 2017-10-01 01:55:50