在敏捷環境中分離什麼 - 在敏捷環境中設計

Question

在敏捷（Scrum）環境中，如何讓產品管理創建足夠小的積壓項目或故事，而不需要他們完成所有設計，這不是他們的專長？換句話說，您如何將敏捷開發中的（設計）與業務需求分開？

Answer 1

有了scrum，產品管理應該是一個人：產品所有者。

你想要做的是在衝刺計劃期間完成，其中整個團隊（產品負責人，scrummaster，開發人員）應該在場。

的什麼應該被定義爲用戶故事由產品所有者。用戶故事應該是高層次的，限制你的產品所有者在中表達業務需求一句故事應該訣竅。

例如 作爲StackOverflow的用戶，我想看看我的名譽

之一衝刺規劃的目標是，以決定應該在衝刺過程中完成的故事。因此，當產品所有者選擇故事時，團隊可以對其進行細分，並簡要談談設計（如何）並對其進行評估。

簡而言之，該什麼應該由產品負責人來完成，如何被球隊。 如果向產品所有者明確解釋了這一過程，他將不會嘗試設計所有東西。如果他無論如何嘗試，scrummaster會阻止他。

Answer 2

不要忘記，應使用加權系統（素數，斐波納契，..）對產品待辦事項進行重要性排序，以便在您的待辦事項中有相似重要性的項目2項權重爲21），那麼他們理論上應該在13s和8s之前試圖插入衝刺中。

Answer 3

您必須做的第一件事就是讓您的產品管理人員扮演產品負責人的角色，這是導致大量Scrum項目失敗的原因。您必須向他展示他對項目的投資回報率負責，爲此，他負責確定故事/ itens /業務需求/功能的優先順序，或者負責以最有價值的itens有更高的優先級。

我贊成將用戶故事用作產品待辦事項，然後在衝刺計劃中，選擇構成衝刺待辦事項的故事選擇較小的任務。

在寫作或幫助您寫作時，您應始終記住您的用戶故事，故事應該是INVEST。我 ndependent，Ñ egotiable，V aluable給客戶，ë stimatable，小號商場和Ť estable。

我覺得在使用模板波紋管可能有助於保持專注於業務目標的PO開頭：

「作爲一個 - 類型的用戶 - 我想 - 一些目標 - 讓 - 一些原因-。」

一個故事的例子是「作爲一個計算器用戶，我想對答案進行投票，以便可以輕鬆找到最有價值的答案。」

不要忘記讓PO寫或爲Sprint Backlog的每個故事定義驗收測試，因爲它可以用作確定故事是否完全實施的基本標準。

上面的例子中，兩個可能的驗收測試是：

「測試投票了答案」

「測試否決一個答案」

這個故事和兩個驗收該團隊知道用戶可以對答案進行投票，並對故事狀態進行更新，完成後，系統允許用戶在不拋出異常的情況下對答案進行投票。

Answer 4

在積壓（重新）評估（確定優先級後）期間，團隊應該進行建模，以便了解用戶故事的全部範圍並能夠準確評估複雜性。這不是可能發生的建模的全部範圍（團隊可能做更多的事情正在進行開發），但它是一個很好的開始的地方，並且能夠利用客戶/產品負責人到處解答問題接着。

由此產生的討論將幫助您與產品負責人合作將他們的需求分解爲一個有意義且合適的粒度。