2.3 敏捷軟件開發的精髓

2.3.1 人與實踐

本質上，軟件開發是人類的一種智力活動，是一種藝術性和科學性相結合的工作。不關注人的因素，軟件開發就會失去控制。

要關注人的因素，最實際的辦法就是注重以人為本的實踐。我認為，敏捷軟件開發思想的精髓就在于人與實踐。

與很多傳統行業不同，軟件開發行業匯集了高度密集的智力活動。眾所周知，智力活動是一項非常特殊的工作。

多年的實踐告訴我：追求人的主動性，是智力活動密集型企業的最高目標。追求主動性的原因在于，評價智力活動的成果是一件非常困難的事情，如果缺少了人的主動性，一切工作都會流于表面，組織的目標就會無法實現。

有一家頂尖的高科技企業，對員工采取軍事化的管理，企業的規模和技術能力以驚人的速度在發展。

這種現象超出了我的理解。軍事化管理只有在狂熱的理想主義支持下，才能激發人的主動性?？駸岬睦硐胫髁x在一個商業化企業中是無法持久的。

我寧愿相信這是個特例，其中有很多我不了解的特殊機遇和背景。

為了說明主動工作的重要性，我想舉個例子。

在建筑工地，一堆建筑材料要搬送到指定的地點。工地上的項目經理，指派了兩個建筑工人，要求他們在下午5點前完成這項工作。項目經理下午來看了看，建筑材料都已到位。好，任務完成了。就這么簡單。

軟件開發就不同了。Robert C. Martin在Agile Software Development: Principles, Patterns and Practices一書中詳細介紹了一次編程實踐。

Bob Koss和Bob Martin為了編寫一個保齡球記分小程序，進行了長時間的討論和嘗試。盡管在思考不成熟的階段就進行頻繁交互是錯誤的，但是，我不得不指出，主動性在這一次編程實踐中發揮了極其重要的作用。

沒有主動性，他們也可以完成這個程序——一個不那么精煉、合理、穩健，而且沒有經過全面測試的程序。他們可以把表面上沒有問題的程序交付給用戶。接下來，就是眾所周知的故事，那些隱藏著的維護成本，一定會在計劃之外的某個時刻冒出來。

主動性很重要，它是提升組織生產效率的關鍵因素之一。但是，僅僅強調個人的主動性還不夠。作為一項社會性的工作，軟件開發還需要更多地考慮團隊這個整體。

軟件開發人員聚集在一起工作，他們有著各自的性格、文化背景、信仰、好惡、做事風格、能力和利益。像所有的社會性活動一樣，各種復雜的關系會逐漸在團隊中形成。在這樣一種復雜的社會關系中，要保持個人的主動性，是一件很微妙的事情。我們會在后續的章節中，詳細討論團隊的話題。

在軟件開發組織中，應該設立一個專門的部門。它沒有建立秩序的職能，而是專注于調整社會關系、提供心理指導、服務于個人。這個部門的目標，是在保持個人主動性的基礎上，充分發揮個人的技能。

為了提高軟件開發人員的主動性，通常有兩種方法。一種方法是，傳播信仰，使團隊成員成為同志；另一種方法是，建立一系列以人為本的實踐方法集，用習慣和文化融合組織成員。敏捷軟件開發致力于第二種方法。

我希望有一種更準確的表述。在我看來，通過方法或手段來提高軟件開發人員的主動性是錯誤的。從理想主義者的角度來看，軟件開發人員和企業之間的關系是平等的，他們以一種契約的形式，相互服務于對方。一切都建立在“內驅力”之上。

Alistair CockBurn在Agile Software Development: The Cooperative Game, 2nd Edition一書中，從西方人的角度，對人的因素進行了分析。我總結了一下，在他看來，軟件開發中的人主要有以下的缺陷：

• 人的溝通永遠是不完全的，完全的溝通是沒有必要的；
• 人是古怪的；
• 人們通常寧可保守地失敗，也不冒險用不同的方式追求成功；
• 人們喜歡臨時創造而不喜歡積累；
• 人們不能始終如一。

從東方人的角度來看，這些缺陷也是存在的，而且遠遠不止這些，在2.4節中我還會繼續展開這個話題。

Alistair Cockburn在《敏捷軟件開發》一書中，還提到一個故事。

Dave A. Thomas是Object Technology International的創始人，這是一家擁有很多成功項目記錄的公司。一天，他向我總結了他的成功公式：“有些人能交付軟件，有些人不能。我雇傭那些交付過軟件的人”。

這是一種結果導向的方法，繞過了所有復雜的過程，就像看云識天氣。但是，我們這里要討論的是一些更普遍的問題——討論云如何形成。

敏捷方法的擁躉針對軟件開發中人的缺陷提出了很多解決方法，包括那些眾所周知的方法集，像XP，Scrum等。與CMM的境遇完全相反，這些方法集在業界大受歡迎，不僅僅受到了軟件開發組織管理者的歡迎，也受到了廣大軟件開發人員的歡迎。

這種現象一點也不奇怪。首先，敏捷方法是舊秩序的反對者。在新秩序建立之前，人們期望改變的想法，會給反對者加足分數。其次，敏捷方法以人為本的思想，是符合時代潮流的。人們渴望被尊重，不喜歡約束性強的事物。

盡管我見過的很多軟件開發組織都聲稱自己使用了敏捷方法，但是真實的情況是怎樣呢？與沒有真正發揮CMM的作用一樣，聲稱的敏捷方法實施大多都成了失去控制的代名詞。

意外的想法仍然產生了。AlistairCockBurn指出了一些敏捷方法實踐者的誤區：

• 迭代必須簡短；
• 敏捷團隊必須駐扎在一起；
• 敏捷團隊不需要計劃；
• 架構已死，重構是你全部所需要的；
• 我們不需要什么經理；
• 敏捷開發在紀律上要求很低；
• 敏捷只適合最優秀的開發人員。

有趣的是，盡管沒有外部的指導，很多人卻不約而同地陷入相似的“誤區”?？瓷先?，人們過于期待那些可以把自己從約束中解脫出來的方法了，所以，人們往往走向了約束的反面。這些誤區的存在，說明很多人還沒有真正理解敏捷方法的本質。

我們來看看敏捷軟件開發宣言：

在這份敏捷軟件開發宣言中，表達了一些思想，但是沒有具體的實施細則。這給了我們更多的實踐空間。從一個實踐者的角度，我更愿意用一種靈活的眼光，來看待軟件開發中的事物，比方說，項目經理的職責問題。

在我看來，項目經理最重要的工作，應該是為軟件開發提供服務。他是那個掃清路障的人、積極進言者、精神鼓舞者，而不是那個拿著時間表、沖著軟件開發人員發火的人。要保證軟件開發的進度，項目經理的頻繁干預，不是一件好事。組織必須培養有責任、有追求的團隊。這類團隊，應該圍繞著一位主刀醫生角色的軟件開發人員展開工作。

我的想法并沒有違背敏捷軟件開發宣言。

和CMM相比，敏捷軟件開發欠缺了一些系統性，運用時顯得更加隨意，或者說，靈活。Alistair Cock Burn在反駁實踐誤區時，還隱約表明了一種態度，對敏捷方法來說，任何有利于目標實現的實踐，都是不反對的。

敏捷軟件開發不是一個有著固定套路的方法論，這有點像風清揚的獨孤九劍。但是，它非常重視實踐方法。這些實踐方法，被有意識地匯集在一起，然后通過“手冊”和“指南”，向大眾傳播。敏捷軟件開發希望人們快速展開行動。

和RUP這類以結果（文檔和報告）來約束的方法論不同，敏捷方法以可供模仿的實踐為核心。

敏捷方法中的實踐就像導演提供的劇本。在影片拍攝期間，導演總是會要求你完成那些設計好的動作和臺詞，從而快速進入角色。相比而言，敏捷方法中的“劇本”更加簡單，它給人們留下了巨大的發揮空間，當然，與此同時，它也對人們的能力提出了較高的要求。

XP要求的工作方式是這樣的。

開發隊伍和幾個客戶一起工作，兩個人使用一臺電腦。三周為一個周期，每個周期都要交付可運行的、已通過測試的、用戶可以直接使用的代碼，2到5次周期后有一次發布。需求以故事的方式表達。程序員估計一下完成一個故事的時間。客戶根據需要定義優先級，調整范圍，盡量在周期內完成最有價值的故事。開發過程中，每天舉行例會，陷入困境的人可以在這個時候找到幫助。最后是不斷地簡化和重構代碼。

敏捷方法，以人與實踐為核心，有一定的積極意義。在“劇本”的幫助下，我們可以在認清事物本質之前就展開行動。同樣，在“劇本”的約束下，我們即使犯錯誤，也不會走得太遠。當我們有朝一日恍然大悟的時候，會發現自己還是在同一個“劇本”下工作，但認識已完全不同。

最后，在敏捷方法中，一項計劃用兩個月完成的任務，可能在兩周內就交付了，原因是選對了一個關鍵的軟件開發人員。而在CMM中，所有的人，都被假定不具備這樣的能力。每個人幾乎都要通過過程的審查。這也許是二者之間另一個比較明顯的差異吧！