敏捷：處理已實現功能的新用戶故事和錯誤

Question

在最近的幾次迭代中，我始終意識到，在客戶開始使用APP之後，我們錯過了某些實現功能的用戶故事細節。

例如：

原來的要求是：「可以增加產品的迷你車（...增加產品的規則）」

原來的用戶故事是：「可以增加產品的迷你車（...增加產品的加工）「

實際實現的功能是：」產品可以加入到微型車的需求，但它重置所有過濾條件和ref加入產品後頁面「

客戶希望它像：」產品可以添加到微型購物車作爲要求。爲了保持當前的過濾條件，刷新頁面中添加產品後，」

這些要求被我們收集。 這些用戶故事被我們的外包團隊寫道。

難道我認爲這是一個錯誤或新的用戶故事，或者我應該簡單地重新打開老用戶故事和編輯它佔了新的要求？什麼是「最佳實踐」，什麼是每種方法的利弊？

非常感謝！

從我的理解是，企業的要求總是很簡單， 用戶故事總是小而抽象。 有些時候，我們無法意識到上述問題，直到開發人員開始編碼和開發人員告訴我們。 它是功能過程和技術問題，它應該在開發階段提交給開發人員討論。所以我認爲這是錯誤。

Answer 1

用戶故事故意保持簡單和抽象。原因是它被認爲是'邀請對話'。這意味着隨着團隊接近處理他們與產品負責人談話的故事，開始充實故事的細節。這可能發生在積壓優化中，或者可能作爲衝刺計劃會話的一部分發生。

這個想法是在恰當的時間在故事上獲得恰到好處的細節。因此，當開發人員開始處理故事時，他們確信自己足夠知道如何完成產品所有者請求的工作。

如果在用戶故事中沒有足夠的細節，那麼認爲它不適合衝刺。這就是爲什麼開發團隊和產品負責人如此密切合作，以及時獲得細節的原因。

即使開發人員開始編寫故事，他們仍然會與產品負責人進行交流。例如，他們可能會將產品添加到迷你手推車中，並將其展示給產品負責人並進行檢查以確保其符合他們的要求。

這個過程對於Scrum來說至關重要。如果你發現故事需要重新工作，那麼這是一個跡象表明這個過程無法正常工作。在你的回顧中談論它，並試圖找出如何最好地減少這個問題。

Answer 2

我看到這裏我們所說的「現成的定義」一個故事一個問題，所以一個故事需要有才能的標準要考慮的規劃和執行（例如INVEST：https://en.wikipedia.org/wiki/INVEST_(mnemonic)）。 我想對故事的一個適當的qa從未做過。在並置的團隊中，這不是必需的，因爲事實上故事的目的是建議與產品所有者進行對話，但對於離岸或外包開發，驗證準備好故事的定義總是一個好習慣。

在你的具體情況下，假如你不在ISO認證的組織中，那麼我不會那麼在意方法論（錯誤或新故事），你需要做的事情就像你說的那樣做:)但是更多關於什麼是向客戶提供承諾價值的最快方式。如果發現一個bug，修復它並部署修復程序，就是讓客戶滿意的方法。後來把這個回溯過來並且找到根本原因並且修復那個。