【正文】 間允許的情況下可能需要重新修改。修改這種不完善的代碼可以稱為“展開修改” 。開發(fā)人員并不需要立刻還清債務，不過，趁他們對這些捷徑仍然記憶猶新時來估量所需的修復工作，當然是不錯的。一定要發(fā)現(xiàn)要重寫的代碼有什么具體問題，而不只是隨意判斷所需要花費的時間。不要借機偷懶，這是一種嚴肅的、保持代碼庫干凈的有效方法。另外，有越來越多的軟件分析工具能自動幫助識別出現(xiàn)“技術債”的地方，了解代碼覆蓋率、分析耦合性、檢測風格偏離等，這些工具或許都可以在你不知情時工作。把留下“技術債”的地方記錄到問題跟蹤系統(tǒng)，并安排在以后的迭代中解決。只要可以平衡添加新業(yè)務功能的工作量并同時還清這些債務，就有可能既滿足客戶的功能要求又不使這些“技術債”失去控制。軟件難用的原因有很多，但通常都歸結到臨時修改、文檔不足、依賴關系不恰當、快捷方式以及偏離預期設計等問題上。當開發(fā)人員最終舉手投降說他們需要在一個系統(tǒng)上重打鑼另開張時，實際情況極有可能是，許許多多沒有償還的技術債已經(jīng)使他們不堪重負，債臺高筑之下，他們覺得還不如痛快地宣布這套軟件破產(chǎn)了。只有一直堅持識別債務并迅速處理它，你才可能總是用“最低補償”來避免接踵而至的混亂。在向業(yè)務利益相關者進行解釋時，這種比喻說法可謂出奇地管用，能讓他們立刻明白軟件如何會隨著時間的推移而變得無法控制，以及為什么應該投入力量保持代碼潔凈。7. 為團隊增添人才而非技能我過去采用的招聘標準同我們這個行業(yè)里的每一個人的招聘方式都是一樣的：技能，技能，技能。直到有一天，一位來面試的應聘者當頭潑我一盆冷水（這當然是一種比喻的說法） ，這次經(jīng)歷從此改變了我。當時我正期望為團隊招納一個有多年微軟工作經(jīng)驗的能人。仔細翻閱了比爾的簡歷，我覺得他非常適合這個職位。他在所有相關技術方面都有六年多的經(jīng)驗。如果我能開出不錯的薪酬，這將會是一件輕而易舉的事。比爾接受了面試。我們先聊了聊，然后我向他介紹了我們手頭上的一些項目，并對他說他是多么適合這個職位。我信心十足地認為這次招聘會進展得很順利。可是突然間我意識到我會招不到他。我中途停止了面談，問比爾發(fā)生了什么事。我告訴他，他非常適合這個職位，也對他直說我感覺到他不會來。他的答復是： “理查德，如果我還想做過去六年來一直做的事情，我就會留在我現(xiàn)在的單位了。我聽說你們即將開始一些非常酷、非常新的 Java 項目，所以我才會想來這兒工作，因為我把它看成一個學習和成長的機會。 ”就在那時我才恍然大悟。用“按技能挑簡歷”的方式來招聘新人，對一個要創(chuàng)建團隊的經(jīng)理而言，實在是最愚蠢的方法。你知道，我和我的伙伴之所以會進入這個高新技術產(chǎn)業(yè)，正是因為我們希望走在科技的最前沿。我們沒有一個人希望在職業(yè)生涯中重復使用自己在大學學到的那些技能。我們之所以進入這個行業(yè)，正是因為這個行業(yè)所涉及的永遠都是新領域，永遠都要學習新技能和新技術。但不知何時出現(xiàn)了嚴重的錯誤。我意識到我們在員工成長上已停止了投資。我們不是在尋找新的人才，我們一直尋找的只是非常具體的精良技能?，F(xiàn)在我要告訴大家，如果你們看到一個雇主在聘用新人時要求其技能達到精確匹配，那么，這個雇主其實是說： “我們不打算投資你。 ”對于所有努力創(chuàng)建強大團隊的人，我要給出的忠告是：請記住你要聘請的是人才而非專業(yè)技能。當為敏捷開發(fā)團隊招聘技術專家時，我要找的是什么樣的人才？他們需要具備的優(yōu)良技能不過是在幼兒園里就培養(yǎng)的：能和他人融洽相處嗎？ z能主動合作嗎？ z當完成任務后，會把自己的工作整理以做備用嗎？ z會對新事物感到興奮嗎？ z喜歡學習嗎？ z至于技能，我可以教他。事實上在我們的敏捷團隊環(huán)境中，學習技術簡單而迅速。然而，教一個成年人如何主動合作幾乎是不可能的。聘用人才而不是技能，這是組建團隊的一種完全不同的方式。那些滿腔熱情、打算同我肩并肩一起開創(chuàng)激動人心的未來新技術的人，才是我想與之共事的人。8. 西蒙，保持簡單項目的利益相關者往往使事情變得過分復雜，這是軟件項目失敗的一種常見原因。項目組成員一定有能力完整構想該項目的目標并完成實際工作。可那些利益相關者卻臆想，只靠幾個簡單的、不可思議的步驟就能完成這個項目。他們以為實現(xiàn)最終解決方案是輕而易舉的一件事情，哪怕這個項目很復雜。利益相關者不應該把軟件項目建成一個統(tǒng)一、巨大而僵化的怪物，而應該讓信息技術團隊把項目建成一棵洋蔥，每長一層就表示成熟一分?，F(xiàn)實世界中沒有其他可供選擇的余地。不論那些需求有多完善，總是難免會有變動。如果你的軟件不夠靈活，不能迅速適應不斷變化的需求，那么這個項目甚至在開始前就注定要失敗了。為了讓事情保持簡單，需要牢記下列關鍵點。讓需求保持簡單 z 。需求分析人員往往會將自己腦海里冒出的某個解決方案同依據(jù)業(yè)務需要而提出的實際客戶需求弄混淆。雖然實際的需求可能會非常簡單，但是由于需求分析人員和開發(fā)人員之間缺乏真正的理解，會導致雙方的交流并不到位。需求分析人員應該用簡單樹形圖寫出需求。根本需求是總體項目的簡單目標。細小枝葉的子級需求被分門別類組成代表父級需求的枝葉。在整個圖中不斷重復這個過程，直到每項需求都清晰明了?？梢允褂密浖季S導圖工具來依照這種方法記錄需求。只要明確了一個小子集的需求，開發(fā)工作就可以開始了。遵循敏捷開發(fā)過程 z 。一旦確定了一個小子集的需求，開發(fā)小組就可以立刻開始創(chuàng)建原型。只要原型可用，利益相關者就可以測試并提供反饋信息。客戶的反饋信息能夠確保準確的需求，同時發(fā)現(xiàn)需求經(jīng)需求分析員從實際客戶傳遞到項目組時有可能形成的交流差異。讓客戶看到原型，也可以幫助檢查開發(fā)人員設想的相應解決方案是否和客戶所預想的一致。這些差異變成新的需求，于是開發(fā)人員重做原型，接著周而復始重復這個循環(huán)。每個循環(huán)周期應盡可能地短，通常不超過兩三個星期。定義需求的一個小子集，按照陳述的需求創(chuàng)建一個原型，然后獲得反饋信息，這種循環(huán)能夠確保項目的所有利益相關者總能達成共識，且每個人對進展情況都感到很滿意。只要認真地遵循這些簡單的技巧，每一個軟件項目都可以取得圓滿成功。這里說的成功意味著顧客滿意且軟件實用，而且軟件所提供的有效業(yè)務功能完全符合創(chuàng)建初衷。9. 你并不是非比尋常的還記得你媽媽說的話嗎？“你是非比尋常的！你是獨一無二的！”其實，所有的媽媽都會這么跟孩子說。相信那個愛的謊言，結果導致了許多常見的軟件項目問題。我指導了許多不同的團隊。當按照軟件項目的達標情況進行考核時，那些相信他們是“非比尋?！钡膱F隊總是無一例外地落在了后面。因為他們自認為是非比尋常的，所以有著重塑一切的強烈傾向。他們認為： “其他的團隊都不可能開發(fā)出實用的軟件，或至少沒有我們這個團隊創(chuàng)造的軟件這么優(yōu)秀。 ”他們不從其他開發(fā)團隊的錯誤中汲取經(jīng)驗教訓，而是悶頭重復犯著同樣的錯誤。損失都由公司買單。他們把大量時間用在重寫、調試以及把自己的奇怪想法運用到那些已經(jīng)成為行業(yè)標準的軟件和工具①上，以至于他們永遠都無法完成客戶項目，而這些項目才是他們應該出售來賺錢的產(chǎn)品。這些虛幻而神奇的產(chǎn)品本可以像這個團隊一樣非比尋常，當然，前提是這個團隊真的有幸將它們寫出來。聽聽這群獨一無二的開發(fā)人員是怎么說的吧：任何現(xiàn)成的構建系統(tǒng)都不可能處理他們“獨一無二”的需求。因此，他們必須為每個新項目編寫一個新系統(tǒng)。不用現(xiàn)成的對象數(shù)據(jù)庫映射工具，他們要寫自己的。網(wǎng)絡應用程序框架？他們信奉： “我們可以做。 ”持續(xù)集成？行。測試工具？我們也能寫。他們當中那些最自負、最癡迷的人甚至還嘗試自己編寫編程語言。① 工具：軟件開發(fā)人員用來創(chuàng)建、調試、測試、分析、追蹤或以其他方式支持高質量的軟件開發(fā)的簡單程序。那么這些團隊每天都在做什么呢？由于舍棄不用那些通常都可以免費獲得的、功能完善的軟件工具，他們要自己創(chuàng)建那些未經(jīng)檢驗的代碼，由此便出現(xiàn)許多問題，而他們每天就是在解決這些問題。如果是編寫自己的數(shù)據(jù)庫層，他們每天就要追蹤隱藏的缺陷和問題。處理這些邊緣事件①所花費的時間非常多，如果他們能學習或者修改現(xiàn)有的工具，那花費的時間將會少得多。不那么“非比尋?！?（但卻更成功）的團隊之所以會使用現(xiàn)成的工具，那是因為他們準備解決的問題都是很棘手的。他們需要可靠的工具，因此他們的注意力集中在軟件項目的解決方案上，而不是試圖為一個已經(jīng)滿滿的工具箱再裝入一個工具。這和有效的軟件項目管理有什么關系呢？不要讓你的程序員白費力氣做重復工作。如果他們跑來跟你解釋他們的問題是多么非比尋常，你就直接向他們點明，他們的媽媽在做出“你是非比尋?！钡脑u價時可能言過其實了。對可以利用的資源要做到了解透徹、信息靈通，引導團隊使用高品質的開源或商業(yè)工具?！胺俏野l(fā)明不可”綜合癥使許多杰出團隊脫離正軌。千萬不要讓你的團隊也在此出軌了。① 邊緣事件：只在極端情況下（例如，最快或最慢的速度，最多或最少的數(shù)據(jù)量，或者最老或最新的瀏覽器接口）出現(xiàn)的問題或情況。通常是指將精力集中在瑣碎且耗時的事情上，卻忽略了重要的編程業(yè)務量。10. 隨時間滾動12 年前，我的團隊作為某家圖形設計公司的分包商受邀開發(fā)一個網(wǎng)絡應用程序。我們同客戶沒有直接的聯(lián)系。客戶將所有的需求都傳遞給總承包商，然后總承包商再通過一連串隨意的電子郵件將這些信息轉達給我們。 有一封電子郵件和我們的藝術家應該使用的屏幕分辨率有關。以前的標準一直都是 640480，但最近的研究表明網(wǎng)站應該支持高達 800600 的分辨率。今天最常見的屏幕分辨率為 1024768。 ）盡管這是一家經(jīng)驗豐富的設計公司，它卻向客戶陳述了這樣的正式要求（我們從來沒有見過）：每一頁的布局符合固定的 800 像素寬和 600 像素高的標準。如果我們看到了這一要求，肯定會立即進行更正如下： “每頁的布局符合固定 800 像素寬的標準，而支持的顯示器分辨率最高為 800600。 ”我們做過許多網(wǎng)站，知道寬度是最重要的方面。用戶討厭水平地滾動網(wǎng)頁，而垂直滾動則被看做是使用瀏覽器的一種現(xiàn)實情況，甚至是一種有利條件。然而，很顯然，這條寶貴的真理從來沒有被轉達給客戶。這個網(wǎng)站客戶為每個網(wǎng)頁都提供了大量的內(nèi)容。結果，只有極少數(shù)的網(wǎng)頁能夠在分辨率為 800600 的 15 英寸顯示器上被完整地縱向瀏覽。必須垂直滾動網(wǎng)頁。作為終端用戶的客戶并沒有認識到，如果想在單個屏幕上顯示這種超量的內(nèi)容，我們必須是超人才能實現(xiàn)這個奇跡，于是他們非常失望。他們指責我們的主承包商，那家設計公司。反過來，這家設計公司便拒絕付錢給我們。據(jù)他們的說法，我們“沒有滿足書面要求” 。有了這次經(jīng)驗，我認識到粗制濫造的書面要求的危害性，也知道別人怎么利用它來對付你。永遠都要用文檔記錄下你的設想，并堅持與最終用戶而不僅僅是中間人來審查并簽署這些需求，這一點相當重要。幸運的是，敏捷項目管理實踐緩解了這些問題。由于認識到開發(fā)人員和最終客戶面對面接觸的重要性，我們已經(jīng)開始共同創(chuàng)建用戶故事，開始根據(jù)他們提供給客戶的商業(yè)價值而不是需求清單來排定各項功能的輕重緩急。一到兩個星期的迭代過程意味著我們必須有早期和頻繁的反饋意見，意味著我們有機會闡明客戶的期望。12 年后，我?guī)缀跤龅搅艘荒Ｒ粯拥那樾危粋€客戶希望在每個頁面上顯示大量內(nèi)容，但同時也高度關注垂直滾動。幸運的是，按照我們?nèi)缃竦捻椖窟\行方式，再根據(jù)以往的經(jīng)驗教訓，我們沒有重蹈覆轍，而是迅速解決了這個問題，實現(xiàn)了客戶的期望。11. 你們的問題，我不買單我們公司正在使用的培訓軟件已經(jīng)滯后了五次升級，再不及時升級，供應商都不再提供支持。我們的項目就是與這家供應商進行合作，將培訓軟件升級到最新版本，然后培訓我們的用戶使用最新版本的軟件。我們對工作作出了兩項聲明，一項概述了用戶培訓協(xié)議，另一項明確了培訓軟件升級的費用上限。在獲得我們的數(shù)據(jù)后，供應商開始了遠程開發(fā)和測試腳本①的過程，以便轉換數(shù)據(jù)并應用第一次升級。腳本一旦通過供應商的測試，就會遷移到我們的開發(fā)環(huán)境，我們要進行用戶測試。在這五次接踵而至的升級過程中，每次都要重復這個過程。測試期間，我們會把遇到的所有問題都記錄下來，待供應商重寫、重測他們的源腳本后，我們再重新測試這些問題。每次升級工作，用供應商的工作時間乘以聲明中約定的費率，計算升級費用。進行升級時，我們會發(fā)現(xiàn)應用升級程序的錯誤，這些錯誤和我們用來安裝升級寫的客戶腳本并不相關。我們會仔細記錄每一個問題，打印屏幕界面，并提供一步步的細節(jié)，說明我們發(fā)現(xiàn)的是何種問題，也告知了我們是在哪里以及是如何發(fā)現(xiàn)每個問題的。我們還要提供證明文件，說明供應商最早許諾過的軟件功能。該供應商堅持認為軟件是“按設計要求”運行的。后來我們發(fā)現(xiàn)，遇到的這些小 bug 只是冰山一角，它們還有更嚴重的后果。它們暴露出軟件的基本功能存在嚴重的問題，甚至是在升級以后還存在問題。① 腳本是指在計算機編程中由一個程序而不是計算機處理器執(zhí)行的程序或指令序列。腳本可以用來控制軟件應用而不用改變應用程序的核心代碼。過了一段時間，供應商承認我們發(fā)現(xiàn)的問題中有幾個確實沒有“按設計要求”運行，它們的確是 bug。由于約定了“費用上限” ，雖然他們?yōu)榱诵薷淖约旱漠a(chǎn)品，不得不做大量的工作，但是除了合同中約定的“上限”費用，他們并沒有額外收取我們?nèi)魏钨M用。在項目的這個階段，為了滿足關鍵的最后期限要求，我們的注意力完全集中在軟件的安裝上。只能顧及一個問題到底是“按設計要求”運行的還是一個bug。顯而易見，如果我們當初明確記錄了供應商修復每個 bug 所花的具體時間，那么我們可能都無需支付合同約定的上限費用。當與供應商談判合同時，應該明確約定雙方（即供應商和你的項目團隊）的時間要按遇到的具體問題進行追蹤記錄。這樣一來，軟件項目經(jīng)理就能有準確的記錄，如果問題與合同項目要解決的問題無關，而是出在供應商的原產(chǎn)品上時，軟件項目經(jīng)理就能夠減少費用的支出。1