Slack

使用 時限迭代 的常見方法是，盡可能將每個迭代分配給多個 使用者故事，以最大化參與人員的利用率。Slack 是故意留出未分配給故事的時間，並將該時間用於非計畫工作。儘管這看起來效率低下，但通常會大幅提升團隊的生產力。

將 Slack 引入規劃的良好方法是，使用它來應對規劃固有的不確定性。平均每個迭代完成 20 個故事的團隊，並非每個迭代都能準確完成這個數量。相反地，我們會看到一個範圍：例如 15 到 22。在這種情況下，團隊可以規劃他們最低的一致數量（15），並將額外時間視為 Slack。

這種方法的好處之一是，它降低了故事完成的變異性。我們不必猜測這個迭代是否會完成 20 個故事分配中的最後五個，而是可以非常有信心地預期完成 15 個。對於規劃和協調來說，更高的信心通常比嘗試最大化產出更有價值。

人們常常擔心 Slack 會導致閒置，但有很多生產性的方法可以使用這些 Slack 時間。最明顯的方法是，將額外的故事視為非承諾的獎勵。這不會影響較低承諾率的可預測性，但可以盡可能完成更多工作。

但做更多故事通常不是最有效率的事。大多數團隊會因為工作環境中的因素而變慢。建置過程中可能存在低效率、程式碼庫中存在垃圾，或不熟悉生產力工具（大多數人在他們的 IDE 中都有各種未發現的寶藏）。將 Slack 時間花費在這些事情上，可以透過提高未來互動的生產力，產生很大的影響。事實上，團隊面臨的最常見生產力問題，是因行程壅塞而導致這些障礙持續存在。

Slack 的另一個好處是能增加與客戶的合作。通常，最大的生產力阻礙是開發團隊並未真正了解如何改善其客戶和使用者的工作。多了解他們，即使只是花一個下午觀察使用者，也能大幅提升其功能的價值。

Slack 能提升團隊對緊急要求的回應能力。團隊通常需要合作，例如為另一團隊的功能擴充 API。沒有 Slack 的話，這類工作需要排入計畫，增加延遲，以及其他團隊的循環時間。小任務可以在 Slack 中處理，快速完成，且無需繁文縟節。請記住，高使用率會增加延遲。

雖然我這裡將 Slack 描述為 時限迭代，但 持續流動 也很重要。這裡的徵兆是，如果持續流動團隊總是忙碌，表示沒有足夠的 Slack，這會讓他們對要求的回應變慢，且無法照顧自己的工作環境。

雖然 Slack 很重要，且常常被低估，但它只是調味品，而非主菜。完全由 Slack 組成的時間表會失去可見性，以及長期規劃。但沒有 Slack 就好像省油錢一樣。