[敏捷最佳實務]從玩撲克到軟體開發

 

我一直相信，軟體開發如同協作遊戲，看了 Jay Fields的大作Software Development Lessons Learned from Poker後，對這一點就更深信不疑了！推薦給大家！！

---------------------------------------------------------------------

我以前不是做軟體開發的。在加入ThoughtWorks兩年之前，我主要靠玩撲克為生。當然，如果你曾跟我打聽過我前臂上的紋身，那你肯定已然聽過我的故事了。要是還沒有，等下次我們一起喝一杯時，我可以講給你聽。

我從未因為花這麼長時間玩牌而感到過遺憾，從中我學到了一些放之四海而皆準的知識。開發軟體的時間愈久，我就愈加確信這二者之間具有令人難以置信的相似性。

學習

我學習打撲克和學習軟體開發的方式是一樣的：儘可能多讀書。我用兩年的時間，讀完了所能找到的每一本有關撲克的書。最後竟至39本之多。編程亦如是。此刻，我面前仍然擺著接下來要讀的5本書；而在過去三年ThoughtWorks的工作中，我翻爛的書亦不在少數。

我認為，無論編程還是玩牌，閱讀書籍、部落格與雜誌都是要想有所成就的必備條件；而若要以二者為謀生之業，僅靠讀書卻是遠遠不夠的。也許你可以把書本上的一切知識都裝入腦中，但知道在何時應用何種規則，這才是真正高手的標誌。

誠然，開卷有益。但總要走過萬裡路，方能對應用特定技術的具體環境爛熟於心。書本不可能把所有情況都囊括一空，只有通過親身體會得來的經驗，才能讓你在某些狀況下為自己或是僱主做出快速而正確的決策，而這些決策可能價值幾千乃至數百萬美元。

經驗之寶貴，世間無物可代。

藝術的巔峰

你可以設計出擊敗普通撲克玩家的電腦程式。遵守一些基本規則，自然就可獲勝。但迄今為止，還沒有任何程式可以擊敗最好的撲克玩家。因為撲克技能達到巔峰 時，也就成了一門藝術。軟體開發亦如是。要想成為一個還行的開發人員，只要遵循一系列最佳實務即可。如果按照經典參考指南一類的書籍行事，開發出還不錯的應 用程式應該不成問題，而且效果會勝過其他最常見的做法。有了這麼多失敗的項目作為前車之鑒，我相信，還不錯的應用就足以令大多數管理層甘心掏腰包了。

當然，有些經理有更高的標準。在銀行、創業公司、醫學系統等領域，標準則更為嚴苛。“還不錯”自是遠遠不夠。那些經理會很樂意為最佳選擇買單，他們期待的 是遠超常人的技能。但問題在於，專家級程式員的技能與普通程式員不同。普通程式員知道做事的方式；專家知道做事的目的。普通程式員會僵化跟隨模式書籍中的 指示，就如遵守參考指南一般；專家則明白對模式的創新可能會帶來指數級的效能改善。

他們看到的絕非同一個世界，所以普通程式員很難跟專家對面交流。做藝術評論家易，做優秀的藝術評論家難。

決策技能

在撲克和編程中有一條絕對真理：幾乎沒人能像他自我感覺的那麼良好。有自知之明是不錯的開始，但人們依然很難知道自己與專家之間的差距。程式員接觸專家的 機會並不多，也就無法公正評判自己的技能。在牌桌上，每個人都是為了錦標而來，可大多數人都會過高評價自己的牌技，這總是讓我驚訝不已。

程式員之間亦是如此，而且大多數人可以獲得的資訊更少得可憐。一個從不參加任何大會的技術領導人，只能跟自己的團隊成員一比高下。當然，他可能已經很優秀 了，否則也不會成為技術領導。但如果與整個行業中最出類拔萃的人相比，他又處於什麼位置？如果覺得在自己的圈子裡已經一覽眾山小了，那碰到不同意見時，他 又會作何反應？有些人會視之為學習的契機並為此感到興奮，但絕大多數都會對不同意見嗤之以鼻。

團隊協作

乍看上去，撲克是一種彼此對抗的遊戲。但事實很少如是。即使在賭注最小的牌桌上，通常也至少會有幾個人常打交道。他們不會達成條件一致對付牌桌上的其他人 ——他們也不必如此。大家都明白一條道理：你不是要去跟牌玩得好的人對著幹，贏他們的錢，而是要從水平低的人身上賺錢。專業牌手甚至會像一個團隊一樣協同 工作。有些人彼此利益相關，故而一人得利則眾人均有收益。他們不僅互相瞭解，而且認識很多人。如果出現一局精彩牌局，樓層經理會跟他們打招呼；侍者會為他 們的對手調製酒精度高的飲品；和手（即發牌者）會故意“犯錯”以影響某人心情（很少有人在心情不好的時候能夠打好牌）。每個人都在協同工作，確保大家都能 掙到錢。

頗為有趣的是，程式員的情況也與之相似。很多人都坐在格子裡，完全依賴自己解決問題。他們往往工作在代碼個人專屬制模式之下。我曾親眼目睹，在這種程式員 交付的應用中，整合問題一直都是大家的心病。而更為不幸的是，整合之痛還只是最小的問題。假設IT部門把業務需求鎖定為500頁的需求文檔。如果公司決定 改變業務方向，隨之而來的系統變更需求將令人痛不欲生。數以百萬計的金錢付諸東流，因為程式員開發的特性已不再具備業務價值，而IT部門還沒有找到更好的 方式來應對業務變化。

當然，情況並非總是如此。專家懂得協作。他們會跟其他專家協作，但也不排斥與經理、客戶、業務部門、分析師、質保人員，以及所有可以為成功貢獻力量的人協作。他們胸懷大局：只有協作，才能讓每個人有所收穫。

度量

雄心勃勃的牌手常常討論他們贏了多少手牌，又輸了多少手。他們討論最多的還是本該贏但卻輸掉的那幾手牌。有時人們會犯錯誤輸錢，但他們一般都不會記得這幾 手是怎麼輸掉的。相反的是，如果有些牌局只是因為手氣不好而輸掉，他們就會記得那一局中的每一處細節，他們還會在故事中透露對手必然獲勝的幾率，來證明自 己根本沒有勝出的機會。真正的牌手知道他們輸掉過多少手牌，以及失敗的大概幾率。他們懂得度量。而且專業牌手會專註於重要的度量標準。你贏了多少手，輸了 多少手，這無關緊要；重要的是你贏了多少錢，輸了多少錢。而且，為你的狗屎運（譯者注：bad beat，即開局時輸家比贏家牌好，贏的幾率更大，但關鍵時刻贏家卻來了更好的牌。碰到狗屎運——take a bad beat——用來形容輸家，來了狗屎運——lay a bad beat——用來形容贏家）苦惱實際上等於替你對手的牌運犯愁。既然你的收入來自於對手的錯誤，那你就是在抱怨為什麼對手把錢給了你。

有度量標準是好事，不過專業人士懂得哪些標準重要，哪些只會分散注意力，哪些介於二者之間。

軟體開發也有很多度量標準，而且有很多標準身上的光環已經遠遠超出了它們所應有的範圍。例如，知道程式碼數幾乎不能帶來任何價值。複雜應用需要相當多的代碼，但這個“相當”到底是多少？它得依賴於語言、工具及其他因素。

修複的bug數量也是個很有趣的話題，只是略遜於前一個。為什麼人們會在乎修複了多少個bug？Bug數量也許有其價值，但是修複的bug數目並不能為我們帶來多少有用資訊。

特性完成率是我自己最喜歡把玩的一個標準。除非我們使用特性來評估工作量，否則知道完成了多少特性又有何用？而且，如果已經對工作量做出了評估，那為什麼不把剩餘工作與已完成工作相比較，從而得到工作進度呢？我很難從特性完成率中看到價值所在。

程式碼涵蓋範圍讓我想起了記錄狗屎運。這項度量是有意義的，但很多人都沒抓住重點。程式碼涵蓋範圍低意味著可能有問題存在，但是程式碼涵蓋範圍高只能表示你有一個很大的程式碼涵蓋範圍數值。高程式碼涵蓋範圍與高品質之間沒有必然聯絡。

注意人，而不是邏輯

如果看過有玩牌鏡頭出現的電影，你大概聽過這樣一句話：你不是在與撲克玩，而是與人玩。此言極是。牌手無疑都是心理學家。有時你確實需要某些牌，但拿一手 好牌只是賺錢的一部分而已。一旦有了好牌，你就需要知道怎樣利用好它們。你是應該加註，還是先讓牌然後加註，還是徹底讓牌，還是跟進？這些做法依賴於很多 因素，但關鍵還是要瞭解牌桌上的對手。當你得到一手好牌，首要目標就是儘可能多地從對手那裡贏錢，而達到這種目的的唯一方式則是想辦法讓對手給你更多的 錢。瞭解邏輯可以協助你贏得幾手牌，瞭解人則可以協助你贏錢。

在交付軟體時，人處於同樣重要的地位。如果軟體只是讓一切工作起來，那隻要把它變成自動化的工作，事情就容易得多了。但軟體卻遠非功能組合這麼簡單。在一 場高爾夫球比賽中，人們會賣出軟體包；在全家到迪斯尼免費旅遊時，人們會簽下軟體服務合約；為了避免法律糾紛，人們會履行合約去構建已經毫無用處的軟體； 為了超越競爭者，人們會使用軟體來加快業務響應速度。

人們使用軟體、開發軟體、維護軟體，或是在某種程度上依賴軟體。軟體開發與這個世界有著千絲萬縷的聯絡，要把洋洋洒洒的變數組合成簡單方程，生產出高品質 的軟體，又與登天何異？但是，軟體開發高手需要考慮每個人引入的所有已知與未知的變數，做出他們力所能及的推測。知道應該做什麼會讓你受益，而知道必須做 什麼所帶來的價值卻是難以衡量。瞭解邏輯可以協助你交付應用，瞭解人則可以協助你交付價值。

在殘缺的資訊下工作

有關這點，剛開始打牌的人處理的非常好：打好每一手牌，老老實實押注，從不虛張聲勢。這便是了，新手就應該只做該做的事情，除非你的錢多得沒地方花了。難 點在於如何從初學者的水平提升。大量資訊霎那間紛至遝來，你需要注意牌桌上每個人的每一處細節：他們怎樣交流，你從前跟他們每個人打過什麼交道，他們所鐘 愛的玩牌方式，誰在贏，誰在輸，凡此種種不一而足。而且，你也不可能知道對手手裡的牌是什麼，下一張牌又是什麼。你所擁有的資訊已超出所能處理的極限，而 且這遠非全部。

編程亦如是。領域專家無所不知，但把一切都向你傾囊相授卻毫無意義。何況，你也不一定需要所有的領域知識。你需要熟悉團隊，但同事總有些事情是你永遠無法 知曉，或者不能完全理解的。不過，編程高手能夠把必要的領域知識融會貫通，掌握團隊的動態，並始終提供技術上的真知灼見。他們知道他們永遠無法成為百曉 生，他們知道什麼事情值得思考，哪些應該置之不理。縱使面前洶湧澎湃的資訊仍是殘缺不全，他們也總能做出正確的決定。

即時反饋

普通牌手在反饋資訊少的遊戲中表現最好。因為牌手是根據資訊而贏錢的。在5張牌梭哈中只有一輪押注的機會。各位玩家只有一次機會來分析你給出的資訊，而你 也只有一次機會犯錯。專家級牌手更喜歡多輪的遊戲。遊戲中的回合數越多，他們就有越多機會從低水平的對手身上撈到好處。他們喜歡即時反饋，並根據反饋做出 調整。在有多個回合的遊戲中，每一個回合都可以得到反饋，專業玩家就會根據當前局勢調整打法。

編程高手同樣喜歡即時反饋。從業務人員即時反饋回來的資訊，可以避免你在構建業務應用時走上彎路。從另一個程式員即時反饋回來的資訊，可以在軟體產品化之 前發現bug。持續整合伺服器可以提供即時的整合反饋，從而避免整合之痛。喜歡敏捷的人能馬上說出迭代是一個有著顯著成效的實踐，因為它可以讓程式員和業 務人員得到即時反饋。不過，作為一個編程高手，縱使他不喜歡敏捷，他也能夠意識到即時反饋的價值；即使在非敏捷的環境中，他也會爭取得到更多的反饋，從而 避免浪費時間精力。即時反饋可以讓你瞭解前行的方向正確與否，每一個專家都會珍視這些資訊。

上下文為王

無論撲克還是編程，沒有絕對正確或是絕對錯誤的選擇。如果你有一對K，那麼在翻牌之前你該不跟嗎？也許吧。這要看你是在打比賽還是賭錢、有上限還是沒上 限、你坐在哪個位置上、你是否已經不跟過一次還是已經封頂了等等。我在撲克中學到了一點，那就是在給出答案之前，一定要綜合考慮所有的因素。

在編程中沉浸的時間愈久，同樣的體會在我心裡就愈加深刻。Java在有些時候是不錯的選擇，但它並非萬能。所有的程式設計語言均如此。工具亦然。 Hibernate很不錯，但它不適用的地方還有IBatis，當IBatis也不適用的地方還會出現或自己創造新的解決方案。幾乎沒有一款解決方案能夠 絕對有效，它只有在恰當的形勢下才會發揮應有的作用。在錯誤的環境中，它也許會成為毒藥。

所以，面對一門新的語言或者工具，無論是你是打算棄若敝履，或是愛不釋手推而廣之，不妨先想想它的適用環境，盡量做到對症下藥，量體裁衣。

查看英文原文：Software Development Lessons Learned from Poker

作者 Jay Fields譯者 李劍 發於 www.infoq.com/cn/articles/fields-it-depends