敏捷社區的一些成員強調了反饋循環對于提高敏捷開發流程效力方面的重要性。

　　“反饋循環”是什么呢？簡單來說，如果某個流程的執行結果可以影響到此流程未來的運作方式，那么它就存在反饋循環。

　　在敏捷開發流程中存在哪些類型的反饋循環呢？在Henrik Kniberg和Mattias Skarin的著作《看板與Scrum：把兩者發揮到極致》（Kanban and Scrum: Making the Most of Both）中，他們描述了Scrum和XP中的一些反饋循環。他們提到的一些在較短時間內形成反饋循環的XP實踐，包括：

• 結對編程
• 單元測試
• 持續集成

　　而需要較長時間才能形成反饋循環的Scrum實踐包括：

• 每日站立會議
• Sprints

　　然而，在所有例子中，這些反饋循環背后的主要目的就是迅速提升流程能力。正如Kniberg和Skarin所說的：

做些改變=>搞清楚它的實施狀況=>從中汲取教訓=>再做些改變。一般而言，你會希望反饋循環盡可能短，這樣就能迅速優化你的流程。

　　Rune Sundling最近的一篇博文提到了更多能夠支持敏捷反饋的實踐：

• 代碼審查
• 靜態代碼分析
• 自動集成測試
• 自動驗收測試
• 你與客戶或者業務專家緊密協作，貫穿項目過程
• 高頻率發布（至少發布至測試環境）

　　除了流程和生產力的改進，緊湊的反饋循環還能使團隊成員在工作方面感覺更好。 Lisa Crispin指出：

如果我們實施“持續集成”這一實踐，對每個代碼新版本做回歸測試，在幾分鐘或幾個小時之內我們就可以知道新寫的或者更新后的代碼是否導致別的功能不能工作。一旦我們第一時間發現，修正起來就很容易。問題不會困擾我們，因為我們知道我們能夠及時修正它們，繼續前進。

較短的反饋循環使我們信心倍增。有了信心，我們也就樂在其中。

it知識庫：敏捷反饋循環的重要性，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。