OOPAA

    前一段時間讀了Matt Stephens 與 Doug Rosenberg 合著的《Extreme Programming Refactored: The Case Against XP》（以下簡稱《Refactored》）。該書雖然是針對 Kent Beck 的《Extreme Programming Explained: Embracing Changes》（以下簡稱《Explained》）第一版進行闡發，然后 Kent Beck 在《Explained》第二版里面也修正了一些 XP 的理念和態度，但是《Refactored》書中提到的一些見解和看法現在讀來還是挺有意思的。
   
    比如作者一開始就講了個“皇帝的代碼”的故事新編，把皇帝比喻成迷信開發方法的客戶，然后 XP 者就是兩個騙子，利用不具體的過程標準來欺騙現場客戶以及審查的其他人，并贏得最后的release，卻最終被小孩子揭露出來的故事。不可否認的是作者在其中做了過多的假設和有失偏頗的類比，最終使得故事顯得過于荒誕和不切實際，但 XP 在那個急于推廣自己的年代用一些過激的宣傳詞，從而引起這樣那樣的誤解，也是正常的。這也是 Kent Beck 在《Explained》第二版里面修正的主要方面，使得 XP 更具可操作性，概念不顯得那么的突兀而容易誤解了。
   
    撇開這些不談，覺得特別有意思的是作者在書中把 XP 和馬克思主義來做對比，得出一些共同點，也頗讓人若有所思。這里閑話不多講，直接貼上書中幾處 XP 和馬克思主義進行對比的地方。
   
    1. XP 里面的代碼共有與馬克思主義提倡的集體所有制
    Just for fun, we did a little research on the subject of collectivism, outside of an XP context. It came from Marxist “power to the proletariat” sociopolitical theory (more on Marxism later). Here are a couple of interesting quotes that we found:
    Karl Marx -- “Since the supreme aim of collectivism is the abolition of that capitalistic regime which enables one man or one corporation arbitrarily to exploit the labour and the necessities of many men, it obviously does not—in theory at least—imply equal compensation for all individuals, nor the destruction of individual initiative, nor the establishment of a bureaucratic despotism.”
    然后引用 Robert C. Martin 的話就是：
    “The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and comfort do not supercede the delivery of quality to the project, or your parcitipation [sic] in the team.”
   
    2. XP 里面自組織團隊與馬克思主義提倡的人民專政
    Karl Mars -- Power to the Peeps
   
I was recently interviewing a programmer for a potential contract, and he happened to mention that he had worked on a project in which his team had attempted XP (but found it too difficult for various-reasons—in particular, that management wouldn’t buy in to the new way of working. Eventually they abandoned the “experiment” [which it quickly became known as], keeping unit tests but not much else).

I asked him what he most liked about XP, and he immediately perked up with, “It empowers the programmers! Puts us on an equal footing with the management. . . .”

    可以看到的是，這里面有些確實是 XP 沒有解決好的問題，或者 XP 沒有明示的東西。萬幸的是，XP 不是一個固步自封的軟件開發方法學，而是更注重它所強調的價值和原則，比如簡單、溝通、勇氣和反饋。所以，在實際開發過程中，不同的項目組在不同的項目環境下會裁剪出合適項目、合適組織的方法學。所以，前面兩個問題其實在 XP 的框架內也都是可以解決的。
   
    我們來看第一個問題：代碼共有導致個人失去成就感和幸福感。其實這個問題的更深層次是：
    1. 敏捷團隊如何評價個人performance？
    2. 敏捷團隊如何激勵個人創造？
   
    其實這個問題也是我們在做培訓的時候，學員們問得最多的問題。在傳統的文檔式開發過程中，開發人員的工作量被量化成代碼行數或者 bug 修正數，雖然大家都知道這其實并不能反映真正的工作量，但畢竟可以作為他們衡量開發團隊成員的 performance 的一個參考值。而 XP 一方面宣揚 pair programming 以及代碼共有，另一方面又宣揚增進設計和重構，這樣統計個人的代碼行數或者修改的 bug 數對于績效考核就沒有任何幫助。那么，在敏捷里面是怎么解決這個問題的呢？
   
    我想，在檢查個人performance在項目組內部通常都會有自己的辦法，符合公司文化和價值的評審方法。以我們公司為例，通常是由每個人找4－5個項目同事來給他寫 feedback，提供對這個人在項目里面表現的反饋。因為 XP 提倡勇氣和反饋，所以，每個人也是會基于一個比較客觀的態度來對同事進行評價。這樣，從項目同事的反饋里面，就能得到比較全面的個人 performance 信息了。
   
    如何激勵個人創造？對，因為 XP 提倡簡單設計，通過重構來增進設計，所以在設計里面考慮更多的是設計是不是滿足當前的業務需求，是不是容易讓項目組其他成員所理解。但是，這并不意味著敏捷就不允許引入新技術，不允許進行大范圍設計。這里不舉我們公司的實踐，在《透析敏捷編程》一書中提到了在項目組中使用“金卡”實踐來激勵個人創造，就是允許項目成員申請金卡來進行新技術研究或者大范圍設計。因為 XP 提倡溝通和勇氣，所以只要開發人員有具體理由，并且項目組同意個人在某方面花費時間精力，那就是應該尊重和允許的。

    所以，從上面來看，XP 并不會導致個人失去成就感，重點在于項目組是否足夠 XP，足夠敏捷來讓每個人都達到自己的幸福感和成就感。如果沒有，建議通過團隊 retropective 來找出有效的改進方法。
   
    我們再來看第二個問題：在項目組內，程序人員地位不比項目管理人員差。其實這個問題的更深層次問題是：
    1. 程序人員應該聽從管理人員的指揮，怎么能提出異議呢？
    2. 如果程序人員有自己的想法，那管理還能進行下去么？
   
    那么，我想大部分擁有這個疑慮的人應該是傳統的項目經理。但是自從在 javaeye 里面看了一篇把開發團隊比喻成正規軍的比喻之后，我發現有些開發人員也傾向于接收管理人員的命令，而不是更積極主動地提供自己的建議，去和管理人員進行更有效的溝通。其實，我們在做培訓的時候，和一些項目經理也談過這方面的問題。開發人員不善于與他們溝通，導致他們對開發團隊的真實狀態不清楚，他們覺得非常不放心，于是反過來進一步要求開發團隊提交更多的文檔來反映他們的狀態。這樣，開發團隊文檔任務增重了，怨聲載道，項目經理就更得不到項目團隊的真實狀態了。于是，惡性循環就形成了。

    在開發過程中，隨時都有可能會發生影響項目交付的問題，比如原來估算的工作量有偏差、客戶對某一處需求提出了修改等等。很多事情項目經理是不可能事無巨細都會察覺的。這些問題在傳統軟件方法學里面都是作為風險來管理的，于是項目經理在預防各種各樣的風險中忙得焦頭爛額，“兵馬未動，糧草先行”，不到最后一刻不敢讓開發人員進行開發。因為一旦進行開發，而開發人員不積極主動反饋項目狀態的話，項目經理對于項目就是完全失控了。這是項目經理無論如何不敢面對的。可是，“防民之口，甚于防川”，項目開發過程的風險，是能完全堵死的么？如果開發人員可以有機會，也無風險地發表自己的看法，項目管理就可以是更輕松了的。而且，一個人的智慧總是有限的，當客戶逼著你做決定的時候，你不希望項目團隊的人能站出來，助你一臂之力么？把全部責任都一肩扛，只會對項目不利，而談不上有益。從另一個方面講，每個人都是希望有一個上升的職業生涯，希望能不斷提升自己。軟件組織也是希望能不斷涌現表現優秀的員工，從而有利于組織的成長。那為什么要打壓開發人員積極參與管理的興趣和付出，最終影響組織的成長呢？
   
    在培訓中，大多數項目經理也能認識到項目團隊溝通的重要性，但對怎么建設這樣的團隊仍然顯得方法不多。XP 作為充分照顧了人性的方法學，也是提出很多原則允許或者鼓勵開發人員積極溝通，表達自己的想法。所以，運用 XP，建設好簡單、勇氣、溝通和反饋的良好氛圍的團隊，不僅對于每個團隊成員，對于項目經理，對于其他管理人員都是有百益而無一害的。為什么不嘗試一下呢？
   
    馬克思主義說過“集體所有制”、“人民專政”，毛澤東思想也說過“實事求是”，鄧小平理論更是說“不管白貓黑貓，抓到耗子就是好貓”。在《Refactored》提到的一些誤解，其實都不能作為反對實施敏捷的理由。我想，如果果真是阻力重重，或者不知道如何開頭，或許可以考慮請求于一些專門提供敏捷咨詢的第三方組織了。