系統用戶故事vs任務

Question

我們正在將我們的門戶P與另一個第三方Web應用程序W集成.W將在我們的門戶中顯示在模式彈出窗口中。

一個明顯的用戶故事（姑且稱之爲US1）

作爲用戶U點擊一個按鈕B時，W應顯示爲彈出並設定特定信息的「是」，應預先 - 填充以便我可以查看設置'IS'的信息。

現在預填信息集，我們需要創建一組API和後端集成到我們的門戶P將信息發送到Web應用程序W.

我的問題是，API的創建應該是系統用戶故事還是任務？

這項工作可以在衝刺完成，但API創建和整合將可能我多任務。此外，完成此集成還會阻止第三方Web應用程序中的後續用戶故事。

所以我應該寫一個系統用戶故事（讓我們稱之爲SUS1）和類似的任務？

作爲門戶P，我應該能夠將信息集IS發送到第三方Web應用程序W，以便用戶U可以查看此信息。

這顯然需要分工作T的創作，如

「創建API A」

或者我應該只是爲用戶創造故事US1子工作T。

的團隊在這裏是更舒適的調用一切的故事，讓他們可以輕鬆地查看自己在衝刺活動燒燬，尤其是溝通，表明後續用戶故事US2是依賴於系統的用戶故事SUS1。 API的

Answer 1

User stories被但從最終用戶的角度編寫，並說明它是什麼，他們希望從產品中獲得。 他們沒有描述如何執行。

您描述的內容不是用戶故事，而是多個實施任務的組合。

用戶故事的一個例子可能是：

，因爲我想看看今天的天氣信息，這樣我就可以知道天氣會像今天

一旦這個門戶網站用戶用戶故事被分配給衝刺，開發團隊很可能將其分解爲若干技術任務。這將包括創建足以提供用戶故事的API 。

Answer 2

創建是一個基礎設施的關注，不應該是利益相關者（或最終用戶）的水平可見。因此，您應該創建一個任務作爲實現用戶故事US1的手段。

但是！

你應該垂直分區您的系統，即任務應該要求執行不超過必要的API，使US1工作。您應該在實施後續用戶故事時實施其餘的API。

一個自然的結果是增量構建的API不會有最佳的設計可能。因此，在每一步你都應該考慮到迄今爲止實現的所有用戶故事。這比BDUF好得多（Big Design Up Front）。