迭代計劃

Question

我們正在嘗試一些計劃迭代的新方法。早些時候，leaddev決定了哪些功能在迭代中由哪個（哪一對）來完成。他初步猜測該功能需要實施多久。現在我們在迭代計劃中對每個功能進行了一次團隊討論，團隊決定我們需要多長時間來實現任務。然後我們決定誰來實施它。這需要很長時間。

你如何做你的迭代計劃（規劃遊戲）？

Answer 1

首先，如果你想更好地控制你花時間做事的時間，請使用時間拳擊。在Scrum中，每件事都是時間框式的，我認爲這是件好事。根據我的經驗，4個小時對於2周迭代的迭代計劃會議來說是一個不錯的持續時間。然後，計劃會議通常分爲兩部分，時間爲2小時。第一個用於從待執行的待辦事項中選擇項目。第二個用於將選定的功能分解爲任務並創建Spring待辦事項。

對於規劃會議的第一部分：

• 用相對單位估計的故事（故事點，T恤大小等）。使用Planning Poker來估算故事，這是一個非常有效的技巧。
• 挑選速度達到你的速度（你上次在故事點上做了多少工作）。選擇具有最高價值/努力比率的故事。

對於計劃會議的第二部分：

• 分解故事寫成任務。以幾個小時估計這些任務（任務不應超過16小時）。有了這個詳細程度，整個團隊就可以準確理解要做什麼，任何人都可以從列表中選擇一項任務。
• 不要事先決定誰將實施什麼，讓團隊自動組織。衝刺積壓任務永遠不會分配;相反，任務由團隊成員根據需要根據設定的優先級和團隊成員技能進行註冊。

Answer 2

我們將每個大故事分解成任務，以便每個人都可以更容易地估計，因爲大故事往往有許多更小的步驟，作爲一個團隊，更有信心能夠估計這些步驟。一個重大故事可能是建立一個網站的一部分，例如，關於公司或展示公司銷售的產品，或者獲得一些新組件並運行，例如，搜索功能或產品註冊。相比之下，任務通常是可以在2天或更短時間內完成的事情，這樣我們就不會有大的黑洞，並且在衝刺期間牌可以在列之間移動。

一旦衝刺的任務列表已經確定，Excel電子表格的電子郵件發送給每個人在團隊中增加他們的估計，併發送回的Scrum Master。 Scrum Master取得所有估算的平均值，以便衡量任務所需的時間。如果存在一些很大的差異，那麼可以與每個極端的人討論爲什麼他們認爲事情會花費那麼長時間。

Answer 3

傳統上，我們採取下一個優先級最高的故事卡片從我們的積壓/發行計劃（高層次的「故事點」估計「），把它們分解成任務，都有人估計他們，並記下這些內容在一張紙上無論接下來哪一對都可以選擇他們想要的任務，這通常不會花太長時間（一週迭代）。

最近，我一直在將我的團隊轉向一個看板系統，其中重點是流而不是迭代。高水平的估計對於發佈計劃仍然很重要，但否則我們只是確保故事的優先順序是正確的。人們將故事從狀態拉到狀態，任何障礙都會在早上或全天提醒（如果這是阻礙工作的事情）。

如果您正在開發一個項目，該項目適合部分持續部署（例如包含網站或自動更新最終用戶軟件，而不是安裝過程繁瑣的事情），您可以考慮不要做了太多的估計。對於一些投資回報率的事情（即花在這上面的工作是否會超過收益？），可能仍然是必要的，但是通過消除估計並在準備好時釋放事物，您可以進入更多的流程。這實際上遠離了迭代，但這意味着需要花費更多時間在連續過程中完成工作，而不是規劃，細分任務等。看板系統對此很有用。這是我們目前用於維護/ FastTrack版本的技術 - 當我們完成了足夠的錯誤修復/增強功能後，我們就會發布。小版本的價值遠高於大版本。

Answer 4

儘量保持迭代的長度不變，以便知道實施所需的時間。修復您的資源並計算其可用時間，並確保您有足夠的資源來覆蓋整個持續時間。根據可用資源，他們的專業知識和任務的優先級將資源分配給任務。繼續添加任務，直到有足夠的資源用於迭代