【破門點滴】敏捷究竟需要什么？

“簡單、清楚的目的和原理引起了復雜、智能的行為，
復雜的規則和制度引起了簡單、愚蠢的行為”
——（Dee Hock 1994）Visa International 前CEO，
他在職期間使Visa全年收益由7.5億美金增長到650億美金。

從貫徹敏捷原理的角度來說，過度強調對敏捷實踐的嚴格執行其實反而會與敏捷背道而馳。因此任何一個團隊準備引入敏捷方法之前，必須要從最本質的角度即敏捷原理來考察自己的項目（客戶、團隊和資源），確定是否要執行敏捷方法以及具體采用那些敏捷實踐。那么敏捷方法所依據的核心原理是什么呢？實踐敏捷究竟需要做到什么呢？本文談談敏捷原理以及一些實踐應用體會。

破門

2007年5月17日

1        交付有用的產品

敏捷團隊必須時刻提醒自己，軟件項目的目標就是向客戶交付有用的產品。如果沒有能上線的系統產品，無論你怎么強調你的團隊實力、項目的進展，從最本質的角度來看，沒有可用的產品，項目就是失敗的！“必須把紅旗插在山頭上！不然，死多少人都沒有用！”——這是我在一個項目中客戶領導對我說過的話。

因此，敏捷方法學首先考慮這個原理提供了一系列非常有用的實踐。

1.1 現場客戶

在集成公司做過項目的朋友們絕大多數都應該經歷過現場開發了，客戶總是希望能夠與開發人員面對面的交流，并且他們希望能在出現問題的時候第一時間找到能夠解決問題的人。現場開發讓客戶以為能夠很好地解決上面兩個問題。但實際上，效果可能并不如客戶所想像。

這里的問題其實就是軟件項目最初遇到的難題，需求獲取和實現。現場開發項目往往將全部的精力放在滿足用戶需求方面了，但是誰又能保證說滿足項目中說了算的那個客戶提出的需求就是對產品最有用的呢？

這個實踐就是要解決如果最快速提供有用的產品，必須滿足需求你不滿足肯定不行，但是全部的需求都去滿足也肯定不行。因此，敏捷方法在這里要求現場客戶的用意就是要時刻保持與客戶的溝通，以便確定最合適的需求范圍，讓團隊能否高效運作，用最小的代價提供出有用的產品。

1.2 小發布

敏捷方法要求最短時間內發布可用的產品，小發布是十分有效的實踐。要實踐小發布就必須有大幅裁剪需求的能力，結合現場客戶實踐，可以更有效地定義小發布需要實現的特性，并且保證每次發布的產品都包含有實際可用的用戶價值。

因為小，所以簡單。如何將大的需求和系統變小卻是一門需要經驗和膽量的學問。當你沒辦法決定的時候，直覺也許是最可靠的了。沒有什么需要擔心，反正每次的發布都很小，所以改變方向起來也容易J

小發布是敏捷方法響應和控制需求變化的有效機制，第一時間將系統發布給現場客戶或是最終用戶，就可以在第一時間獲取反饋，從而降低需求變化對系統帶來的沖擊。

1.3 測試優先

測試優先是敏捷方法廣為接受的實踐了，先按照測試框架編寫單元測試，再為系統添加實現的代碼，可以有效防止過度設計。讓程序員們自然而然的把注意力集中到提供客戶價值上，而不是將精力泛濫在無邊無際的代碼技巧之中。

完善的測試也為系統重構提供有效的屏障，檢驗系統的重構是否成功的標準仍然是系統是否有效地提供用戶價值。

1.4 持續集成

持續集成為項目提供了基線，為小發布提供便捷。每時每刻項目都有保障通過測試并且可以運行的系統。再也不需要為準備發布而辛苦地熬夜、匆忙地測試、混亂地運行，然后準備迎接無數的系統bug的煎熬了。持續集成讓這些過程每時每刻都在項目中自動有序地進行著。

發布只需要從集成服務器上取出最新完成的版本就可以了。

2        依賴于人和協作

軟件項目的成功依賴于人和協作，在這點上沒有人能否認。傳統軟件方法也是想盡一切辦法來加強協作的效率以及消除人對項目的負面影響。敏捷方法則從另一角度來強調要發揮人的積極因素以及強調直接的交流來提高協作效率，傳統的標準化管理流程和基于文檔的協作對于快速變化的項目要求已經明顯不能適應。因此，敏捷方法重新回到了發揮人和團隊潛力的方向。任何系統和過程的適應能力都無法與人來比，因此，充分發揮團隊的個人和協作能力，就能夠得到最高的效率和最好的效果。

2.1 白板

白板是敏捷項目團隊必備的利器，沒有白板的團隊是無法想像的。

在白板前面站立著的時候就是思維最活躍的時候，因為誰也。敏捷團隊最常采用的方法就是所謂頭腦風暴法，大家針對目標主題在白板前討論，將所有能想到的概念、方法、詞句統統寫到白板上，很快行之有效的解決方案就會突然之間出現在大家面前了。

2.2 站立會議

站著開會往往效率更高，目標更加清晰。每天團隊之間需要時時刻刻保持高效的交流。夸張點說，敏捷團隊的工作室往往更像一個熱鬧鬧的市集。安靜的環境并不一定就是軟件開發最高效的環境。

2.3 PP

結對編程是提高個人效率非常有效的實踐，人們往往說做什么都最好有個伴。巡警執勤，飛行戰斗編隊，拉力賽車，都是兩兩組合的生動案例。軟件開發中的結對編程要求更高，兩個人同時坐在電腦前面完成一個任務，一個人負責實際操作，另外一個人負責即時審查，任何需要的時候兩人都可以互換角色。在PP對不同角色的名稱來說，更類似拉力賽車手。

即時審查、點對點壓力、即時溝通、目標導向、知識傳播，結對編程的好處不用在這里一一細數了。結對編程是將協作效率發揮到極致的實踐，不過認真執行它還真需要勇于嘗試，甚至需要強制性的約束。

2.4 不加班

加班是否真的無法避免？至少我經歷的項目還沒有不加班的時候，有時候是必須，有些時候則是自愿，反正我個人是沒辦法做到每天8個小時滿負荷運轉然后每周只工作5天。作為一個典型的中國程序員，我進入工作狀態以及從工作狀態中退出都需要不少時間。不過身體狀態的確是一天不如一天，這也許是中國程序員的編程生命周期普遍比歐美短的重要原因吧。

這個實踐，只有真正的高手才能做到罷。用中國的古語來說：靜如處子，動如脫兔。能夠有效地控制自己工作狀態的人，誰敢說他不是高手？因此，對于這個實踐，我的建議是反過來考慮，努力不斷地嘗試控制自己的狀態，應該算是向高手邁進的一個有效途徑吧J。

3        做盡可能簡單的事情

我個人認為敏捷原理中最核心的原理就是簡單了。一句話，簡單可不簡單！復雜、厚重的方法自然是稱不上敏捷的。因此，敏捷就是做盡可能簡單的事情。簡單的事情才有把握和可能去做好。當項目中無數簡單的事情都被做好以后，它必然就是一個不簡單的成功項目了。

3.1 將盡可能多的工作丟棄不做的藝術

簡單是將盡可能多的工作丟棄不做的藝術。在開始動手之前，要問問自己和團隊，如果我不做這件事情，會發生什么情況呢？會失去什么呢？

敏捷方法會幫助我們來確定哪些工作是可能丟棄的，反過來說，丟棄盡可能多的工作，你所使用的方法就盡可能地趨于敏捷了。這也是一個不斷迭代和進步的過程。

3.2 更少的文檔

敏捷方法最先倡導的一個實踐就是丟棄繁重的文檔，只用最少的時間和代價來記錄需求、設計和會議。文檔的目的也是為了交流，當團隊或者客戶能面對面交流的時候，我們就不要寫文檔，直接面對面討論，然后用簡單的方法記錄下結論，盡快去落實執行。

3.3 簡單設計

簡單設計的目標依然是為了減少工作，在沒有清晰地理解需求和目標之前，我們不去做那些前置設計工作。換句話說，只針對已知的需求設計和實現。這是敏捷方法能夠快速適應的重要實踐經驗，設計的不足可以用不斷的重構來彌補。重構設計的驅動過程也是針對變動的需求來的，只不過是針對進一步了解的更多已知需求來設計和實現，為此我們要對原先的設計進行調整和優化。

3.4 目標和特征驅動

敏捷方法中需要不斷調整的內容就是階段目標，因此我們采用快速迭代的過程，每次迭代都針對特定的功能需求和系統目標，在這點上敏捷也是特征驅動的。這同樣也符合交付有用的產品原理。

4        結語

敏捷方法學提倡是知之而用的實踐精神，所有的敏捷方法都是實踐驅動的。因此認真地學習和理解敏捷原理才有助于我們理解敏捷實踐規則背后的相互關系。我們僅僅是引入幾條敏捷實踐不能說就是實踐了敏捷方法，而要看我們項目實施是否時刻貫徹了敏捷原理的精神，針對項目的實際需要選擇甚至創造出最適合團隊和項目環境的敏捷實踐，每個敏捷團隊和敏捷項目都擁有自己獨特的敏捷方法。