（4）尋求快速反饋和持續改進
改善最大的敵人是人類行為：沒有人喜歡被批評，我們指的就是沒有任何一個！
這就是為什么每當我們在做某件事，我們不愿意展示給別人，除非我們認為它已經完成了，我們的觀眾能夠“完全”理解我們所做的。
但正如你可能已經明白，這是反作用于編程的，因為如果我們等太久才得到反饋，我們不可能實現任何變更而不錯過我們的交付目標。
那么，你能做些什么呢？
基本上，克服害怕被批評的心理，作為一種政策要求，在工作中每個人展示給其他團隊成員以及產品行銷人員他的工作過程。
營造一種企業文化讓人都知道如何給予和接受反饋。你通過確保反饋針對的是工作，而不是人，同時讓人反饋產品的好和壞的方面（而不是只集中在需要修復的部分）來可以實現這一目標。
起初，這可能不是一件簡單的事，但它會隨著時間的推移會變得容易，從中獲得的價值簡直是不可思議的。
（5）擁抱變化和有序工作
這可能是敏捷實現的基石，無論你如何努力工作規劃你的項目，無論你有多擅長，最終事物會改變，你需要調整你的計劃。
但是，除去口號，你該怎么擁抱變化呢？
首先，計劃要少，不要深入但是要有，減少長期的，因為你無法準確地預見現實到底是幾個月。
尋求反饋宜早不宜遲，確保，如果你不得不改變功能和計劃，你在2.4周時知道，而不是6至9個月。
為改變做計劃，并確保你的團隊知道，變化確實會來，而且它會被接受，這使得他們當他們面臨著這一現實和需要時，更容易應付它。
小的變化應該是你工作方法的一部分
你可以從敏捷的理解中獲取最好的原則之一，正如產品和需求是不斷變化的，所以你的工作流程應該是動態的，自適應。
能接受被提問關于你是否工作在最好的和最有效的方式，或者是是否你能在過程有或大或小的改進？
能接受反饋，尋求它，甚至獎勵給出反饋的人。一旦你能夠引入接受反饋的企業文化，你將看到如何真正開始改善，甚至是他們自身。
注：
1、Jenkins，之前叫做Hudson，是基于Java 開發的一種持續集成工具，用于監控秩序重復的工作，包括：
I、持續的軟件版本發布/測試項目。
II、監控外部調用執行的工作。
2、Atlassian Bamboo是一款持續集成構建服務器軟件（Build Server）（非開源軟件）。Bamboo 的特點： 簡單的用戶界面容易安裝-順利的話，5 分鐘內就可以讓運行起來！自動檢測你的設置 - 如果你的Server 上使用了Maven，Ant 或者Java 設置， Bamboo 會自動檢測他們； 連續的日志 - 監測你的build 的colour coded 日志；容易顯示所有項目。
3、TeamCity是一款功能強大的持續集成（Continue Integration）工具，包括服務器端和客戶端，目前支持Java，.NET項目開發。
TeamCity 提供一系列特性可以讓團隊快速實現持續繼承：IDE 工具集成、各種消息通知、各種報表、項目的管理、分布式的編譯等等，所有的這些，都是讓你的團隊快速享有持續集成帶來的效率提升、高質量的軟件保障。
使用 TeamCity，你能夠在幾分鐘之內為你的項目配置一個構建服務器，它內建了持續單元測試，代碼質量分析和早期的構建問題分析報告，你甚至可以在IDE 進行。
TeamCity提供平滑的學習曲線，你可以逐步的學習經它的高級特性和功能，你很快就能加強你發布管理實踐。本次發布，在可用性作了大量的改進，更新的IDE 插件支持 CVS 和SVN，另外還包括一些之前版本不具備的企業級的特性。一些專業顧問可能不希望你知道的東西：
你并不需要在你的開發過程中作出重大改變就可以從敏捷原則得到很多好處
如果你花時間去真正了解敏捷（而并不只是在網絡上重復的徘徊于支持和反對中），你就會認識到事實上敏捷開發并不是一種方法論，而是一種可以應用于每個軟件開發的方法。當然，像SCRUM（Scrum 是一種迭代式增量軟件開發過程，通常用于敏捷軟件開發）和 XP（Extreme Programming 極限編程）的方法都旨在制定敏捷原則的具體使用，但這并不意味著你可以通過這些工作方式來獲得的敏捷開發的全部或大部分好處。
一些工作中使用到了敏捷可能你沒有注意到
幾個月前我們在與客戶交談的過程中，客戶告訴我們，想要在工作中使用敏捷方法，但是在他們的團隊中沒有足夠的時間實施SCRUM。該團隊的經理提及曾經與一個SCRUM 顧問談及敏捷開發的的實施，但是在進一步的考慮之后，他決定最好等待，直到當前產品發布，要在接下來6 到9 個月的時間實現所有必要過程的變動。
顧問的建議給經理留下了非常深刻印象，他要求團隊做出小的變化同時開始實施的一些顧問建議的想法。因此，每天早晨在喝咖啡和吃點心之后開15 到20 分鐘小會議以及他們開始組織2或3人的程序員團隊并使其盡可能在短周期內完成任務，而不是讓每個程序員單獨完成這樣可能需要長達6 到8 周的時間才能完成的任務。
他們所做的另一件事是讓測試人員更早的介入工作，更緊密地與開發人員合作，在編碼階段開始，測試人員將對尚未完成的產品執行初步測試，也告訴程序員一些他們如何改善單元測試和集成測試的想法。作為這個過程的一部分，程序員也學到如何在提交修改之前自己進行部分的手工測試作為內部健全檢查的一部分。
最后，經理要求整個團隊在每個月的月底與產品營銷人員安排一個正式的會議，并將演示相關特性功能的開發進展。在這些營銷會議提供的反饋仍然可以實現當前版本發布而不延遲版本發布。經理告訴我們，自從他們開始用這種方式工作，大大提高了團隊的生產力和工作氣氛，他真的很期待他們的團隊實現SCRUM。
他不理解的是，他們的工作方式并沒有做任何革命性的改變，他們就已經實施了部分的敏捷開發并且從中體驗到敏捷的好處。
小的變化和改進之路
這個經理的故事是一個很好的例子。如何在你的整個工程中使用小的改變來實現敏捷就能實現很多你想獲得的結果并不需要開展一場徹底的革命。
以下是一些想法，可以從上面的故事得到證明，我們相信，無論你的團隊目前正在使用哪種開發方法都可以快速實現敏捷。
（1）小/更小塊的工作
把工作分解成更小的，更易于管理的塊，而不是少量的非常大的需求或任務，可以在更短的時間間隔內（數天或數周）完成。通過這種方式確保任務不比你原先分配的占用更多的資源（因為如果你的計劃設想開始在工作中出錯，你會在2周內而不是2-3個月才發現它），最重要的是，你會更快地交付功能給測試人員和產品營銷人員，并得到及時反饋，進行必要的修正和調整，而不會影響你的發布日期。
（2）增加程序員和測試人員之間的協作和溝通
如果這個想法是為了使開發人員盡快得到功能的反饋，那么最好的辦法是更早開始測試，很多時候，即使是在平行開發時也是如此。
你可以通過多種方式實現這一目標，例如通過一準備好部分功能就邀請測試人員直接在開發環境運行其測試，（而不是等到所有部分都完成的時候）。
另一種方法是測試人員與開發人員合作來計劃和寫單元和集成測試的方式，這將有助于測試人員更迅速地捕捉到更多的錯誤。最后，如何能讓我們開始教程序員怎樣運行少部分的由測試人員編寫的手動和自動測試程序，作為他們在提交代碼之前的健全性測試的一部分？我們看到很多的團隊，在開發人員提交代碼的主要分支之前他們需要運行開發自己的測試集進行測試。
（3）有更多的自動化測試以及更多經常運行它們
這是應用敏捷的團隊的首要原則之一，事實上，也是符合每一種類型的項目邏輯。作出承諾，有意識地投資自動化。
首先，指導你的開發人員為每一個新功能或重要的錯誤修復，創建單元測試和集成測試。
你也可以讓你的測試團隊創建自動測試，以覆蓋盡可能多的產品，并指導你的開發人員使用這個功能的自動化更簡單，更強大（例如，通過使用GUI 元素中正確的儀器）編碼方法。
但是，創造你的測試是遠遠不夠的。你需要有一個框架，盡可能多地運行這些測試，并在測試發現缺陷時即時反饋給程序員。
現在，有很多很好的持續集成框架（如 Jenkins1，Bamboo2 或TeamCity3），所有這些都可以利用我們強大的API 集成到實踐測試中。最后，你也將確保你的程序員遵守“你把它弄壞了，立刻你修復它！”的黃金規則。