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