在所有聲稱遵循敏捷流程的團隊中

minaminamina555

他們距離流程足夠遠，只是陷入了無法從敏捷中獲得優勢的情況。 先決條件 如果您了解敏捷方法論 並且您的團隊已經在使用敏捷流程，那麼本文對您很有用 。 敏捷流程可能無法為您帶來預期結果的原因 敏捷方法論 讓我們看看公司和團隊在遵循敏捷方法論時犯的一些錯誤。如果您對以下任何一個問題的答案是肯定的，那麼您就需要努力改進團隊遵循的敏捷流程了。 您是否在沒有考慮先前的 SDLC 階段的情況下直接進入實施步驟？ 敏捷方法論 小迭代並向客戶發布變更是敏捷的關鍵點之一。這提供了客戶快速回饋的巨大好處，因此，如果期望與結果之間存在任何差距，都可以在早期階段發現。 然而，有時團隊會誤解這一點，並認為由於他們有能力快速獲得回饋，因此他們應該開始實施，而不需要在需求收集、分析和設計階段投入太多精力。 隨著時間的推移，專案變得難以管理，沒有人知道需要做什麼、還剩下多少工作以及已經完成了多少工作，這會導致一場災難。 設計思維 免費下載設計思維指南 改進建議： 敏捷的 SDLC 規則是： 史詩必須有明確定義的需求文檔， 除了 Spike 和 POC 之外，所有其他使用者故事都必須有設計文件的支援。

使用者故事的 DOD 必須明確實現設計文件或需求文件的一個或另一個目標。 負責人是否決定該任務的任務和故事點？ 敏捷方法論 儘管這看起來似乎是一件很小的事情，但不標準化故事點不僅會影響您的專案交付時間表，還會從根本上損害您團隊的工作文化。 許多團隊認為任務負責人知道完成任務所需的努力，因此他們是為任務分配故事點的合適人選。雖然乍看之下這似乎是正確的，但它也會引起問題。讓我們透過其中的一些來理解這一點。 由 印度车主电话号码列表 故事點不適用於另一個人，因此此類分配會在任務和點分配者之間產生高度耦合。 可能存在這樣的情況：A 可以在一天內完成一項任務，但 B 需要 5 天才能完成該任務。因此，人 A 的表現是人 B 的 5 倍。但是，如果他們都可以自由地為他們正在執行的任務分配故事點，那麼人 B 分配的故事點將是人 A 的 5 倍。人 A，如果如果你不仔細檢查，你永遠無法發現A和B之間的表現差異。 專案的完成很大程度上取決於專案的負責人，而不是專案的複雜程度。 改進建議： 分配故事點不是一項單獨的任務。這是一項集體活動。 最好的方法是讓整個團隊（或至少是關鍵團隊成員）參與並要求他們提供點估計。



獲得點估計後，團隊可以選擇取所有估計的最大值、最小值或平均值。 您是否認為密切監控故事/任務的創建和結束是浪費時間？ 敏捷方法論 如果產品所有者和工程經理不監控新增至 Epica 的新任務，那麼可能會導致 Epica 的混亂和無方向的進展。如果故事沒有正確的完成定義（DOD），那麼它們只會有助於隱藏團隊的低效率。 讓我們了解為什麼您應該在創建和結束故事時進行跟進。 團隊中的每個人對 Epic 的理解程度不同，未經分析的故事可能沒有正確的背景、與其他故事的連結以及對事實的有意義的定義。這樣的故事只會在準備推遲評估 Epic 的地位時造成混亂。 如果多個人在沒有協調的情況下創建史詩中的故事，則可能會使用重複或重疊的 DOD 創建故事。這將導致團隊成員重複工作。 儘管在理想的世界中，我們相信最好的意圖，並認為每個人都希望為團隊和專案的成功而努力，但讓我們持保留態度地接受這一點，因為並非團隊中的每個人都會有同樣的積極性。故意創建沒有明確 DOD 或重複 DOD 的故事的情況並不少見。