對極限編程四個核心的理解（二）

三、反饋

1)       
客戶對軟體的反饋

在極限編程中一個很重要的實踐是有現場客戶，從此也可以看出來對客戶回函的重視。有了現場客戶，就能夠隨時對軟體做出反饋，能夠保證在“瞄準”的過程中不斷調整，保證軟體前進的方向。而且，現場客戶還可以對開發人員在開發過程中遇到的問題隨時做出反饋，那樣開發人員就可以避免由於自己的主觀猜測而出現的錯誤了。而這正是在傳統的軟體工程的編碼階段程式員最容易犯的錯誤，因為在那個階段，已經沒有客戶的參與了，編碼人員只是根據詳細設計來編寫代碼，對業務的不瞭解往往會造成編碼和單體測試都非常困難，甚至於出現嚴重的錯誤，一直到最後驗收測試的時候才能夠被發現，而此時修改的代價是非常大的。由此我們可以看到由於現場客戶的存在，把這些可能出現的錯誤消滅在了萌芽狀態，很多時間、精力以及資金都節省下來了。

但是並非說我們可以從客戶的公司中隨便找一個人來做現場客戶就可以了，現場客戶的選擇也應該是一個可以直接影響到項目的成敗的因素。一個好的現場客戶不僅可以準確的把握軟體的方向，回答業務問題，而且可以編寫驗收測試，保證軟體中的業務資料沒有錯誤。這樣就要求他不僅是一個管理員，而且電腦的水平也要有一定的高度。這可能在國外並不難找到，但是在國內可能會有很大的困難的。

如果一旦沒有現場客戶，那麼我們必須要有相對應的方案來應對。我想一種方式可以是這樣的：保證有一個系統分析員層級的人，他可以少量的參與編碼的工作，因為結對程式設計的過程中他會給大家很多的協助，另外他還有一個更加重要的任務，就是負責與客戶之間的交流，及時的將經過短期迭代的小版本的程式交給客戶，並聽取他們的反饋意見，也就是要他起到開發人員和客戶之間的一個橋樑的作用。

2)       
測試代碼對功能代碼的反饋

在極限編程中提倡的是“編碼未動，測試先行”，也就是說在編寫功能代碼之前就先要編寫測試代碼，測試代碼可以用來保證我們的功能代碼的運行是否正確。一般來說，我們都是使用xUnit作為開發測試代碼的工具的。

有了測試代碼之後，功能代碼的編寫更加像是一個解決問題的過程，什麼樣的問題呢？也就是讓xUnit的那個狀態條變綠的問題。我們需要不斷的調整我們的功能代碼，讓狀態條不斷的從紅色變成綠色，看著那種環保的顏色，我們的心情也會變得好起來。

這個方法在程式需要不斷變化的時候尤其有用，因為我們在一般的情況下，如果修改了功能代碼，那麼以前所作的測試工作都需要重新來一遍，那樣既浪費時間，又容易出錯。有了自動化的測試代碼，我們只需要運行一下Test Case，看它給我們的反饋是什麼樣的就可以了。如果xUnit代碼給我們的資訊是沒有錯誤，我們大可以放心的繼續我們的工作了。

但是，並非是說有了xUnit工具就萬事大吉了，我們必須要很好的利用這個工具才可以。首先，一定要有一定的測試的理論知識，明白需要採用什麼樣的資料作為測試案例，那樣才能夠做到真正好的測試，才能夠保證程式的品質。另外，測試代碼的編寫不是一次就完成了，隨著功能的添加，我們的測試代碼也一樣要隨之而改變，在保證原有代碼沒有問題的前提下，繼續編寫新的代碼。

3)       
管理員對開發人員的反饋

這一點看起來似乎不很重要，但是仔細想一想，軟體最終的完成靠的是誰呢？這個答案大家應該都非常清楚，其實就是所有的開發人員。沒有管理員一個項目可能會延期完成，或者說品質不高，但是如果沒有了開發人員，那麼項目是一定不能夠完成的。所以，為了保證開發人員的滿意度，管理員對開發人員的意見的反饋是非常重要的。

開發人員在工作的過程中一定會遇到各種各樣的問題，比如說休息、待遇、工作的環境、工作使用的工具軟體等等，這些問題可能會直接影響到工作的積極性和效率，所以管理員一定要時刻豎起耳朵來聽取這些意見，並及時的進行反饋，避免開發人員帶著情緒工作，那樣不僅僅會影響到自己，而且由於結對程式設計的特點，那樣的情緒會很快的傳遍整個團隊，等大家都對當前的項目有了抵觸情緒的時候，接下來的結果也就可想而知了。

我想，管理員的任務就是要將開發人員團結起來，使得所有的人真正成為一個團隊，而不是一團散沙。想要做到這一點，就需要時刻瞭解開發人員的要求，似乎看來他們所做的是類似於後勤的工作，但恰恰是這樣的工作往往是最重要的。

二、勇氣

1)       
接受任務的勇氣

在項目開始的時候，一般的情況是由管理員來為開發人員分配任務。但是，這種分配只不過是根據管理員自己心中對每個人的估量來做的，所以很難做到每一個人都很滿意。有些時候某些人希望從事自己沒有做過的任務，從而學習新的知識；同時還有一些人想要從事自己熟悉的任務，那樣可以在更短的時間裡面做出更多的成績。不僅僅是對於每一個人，就是對一個人，可能在不同的時間裡面他們的想法都是不一樣的，所以說，憑管理員主觀的判斷來給大家分配任務一定會有一些人對自己的任務不夠滿意。

在這個時候，我們不妨嘗試這樣的一種方法，將所有的任務公布給大家，然後讓開發人員自己來選擇自己想要做的任務。這樣，由於任務是自己選定的，那麼滿意度會有很大程度上的提高。

在這種情況下，重要的一點就是開發人員要有接受任務的勇氣，如果所有的人都選擇自己覺得容易的任務，而迴避困難的任務，那麼我們的方法就失敗了，因為必定會有一些任務無人選擇。在這個時候，管理員應該採取適當的方式鼓勵開發人員，促使能夠選擇一些對自己具有挑戰性的任務，那樣對於個人的提高也是很有好處的。

其實想一想，作為開發人員，應該都不會有問題。勇於迎接挑戰，正是現在的程式員大多都具有的一種素質。