程序員度量（改善軟件團隊的分析學(xué)）

程序員度量改善軟件團隊的分析學(xué)目錄\h第一部分概念\h第1章概述\h第2章測量程序員的工作\h度量的目的\h案例分享：局部地揭露魔力三角\h模式、異常點和離群點\h理解度量的限制\h案例分享：意料之外的成功因素\h有價值的數(shù)據(jù)\h案例分享：度量和懷疑論者\h第3章合適的數(shù)據(jù)\h度量可以幫助回答哪些問題\h案例分享：賽季的最有價值球員\h度量數(shù)據(jù)\h案例分享：雙隊記\h第二部分度量\h第4章技能度量\h輸入數(shù)據(jù)\h進攻度量\h防守度量\h精度度量\h技能度量計分板\h如何度量各種程序員類型\h第5章響應(yīng)[譯注1]度量\h輸入數(shù)據(jù)\h獲勝度量\h輸場度量\h動量度量\h響應(yīng)度量記分卡\h基于項目類型的觀察\h第6章價值度量\h輸入數(shù)據(jù)\h貢獻度量\h評價度量\h價值度量記分卡\h關(guān)于團隊在不同階段的一些觀察\h第三部分過程\h第7章使用度量\h著手開始\h案例分享：7%規(guī)則\h在開發(fā)過程中使用度量\h案例分享：轉(zhuǎn)機\h在績效評估時使用度量\h進一步采用度量\h案例分享：相同與不同\h第8章打造軟件團隊\h目標(biāo)和描述信息\h角色\h案例分享：兩次通宵\h人事\h案例分享：沒有完美團隊這回事\h第9章結(jié)論第一部分概念該部分涵蓋關(guān)于度量、模式分析、數(shù)據(jù)采集和數(shù)據(jù)元素的常見概念。第1章概述讓我們不要太確信，我們沒有錯過一些重要的東西。——比爾詹姆斯（棒球統(tǒng)計學(xué)家和作者），摘自"UnderestimatingtheFog"這是一本關(guān)于程序員、軟件開發(fā)團隊的度量和模式的書。本書的一些想法源于我在多年前開始的對軟件開發(fā)團隊構(gòu)成的思考：無論好壞，所有細(xì)微貢獻以及無名英雄的辛勤汗水都是項目成功的關(guān)鍵組成部分。近二十年里，我一直在負(fù)責(zé)設(shè)計師、程序員和測試團隊的組建與管理工作。這些年，我意識到一個軟件開發(fā)團隊就像一支球隊一樣，需要有各種角色的球員和不同的技能的專業(yè)人員才能成功。我同樣認(rèn)識到成功和失敗的模式未必像我之前所設(shè)想的那樣簡單。我見過一個簡單的模式，或許你也看到過：我曾經(jīng)所在的每個成功的軟件開發(fā)團隊中，總是至少有一位同事無怨無悔地去做一些瑣事，比如創(chuàng)建安裝程序，改善編譯腳本，或者修改一些其他人的錯誤來幫助團隊實現(xiàn)產(chǎn)品功能。如果團隊里沒人去做這些瑣碎的事情，那些項目就總是無法完成，或者至少是做得不夠好。另一種模式是：我見過很多經(jīng)驗豐富的軟件開發(fā)團隊，其中一般都有一到兩位程序員在充當(dāng)明確的技術(shù)領(lǐng)導(dǎo)和關(guān)鍵人物，雖然他們未必?fù)碛信c之對應(yīng)的頭銜。這些關(guān)鍵的程序員不僅解決問題，而且他們對其他人產(chǎn)生了強大的影響力，比如其他的程序員技能飛速發(fā)展，越來越接近技術(shù)領(lǐng)導(dǎo)者的水平。其最終結(jié)果就是，一到兩個牛人提高了整個團隊的水平。這里還有我在曾經(jīng)親身參與的一個長期項目中觀察到的一個模式，這種模式尤其常在處在創(chuàng)業(yè)階段的小團隊中發(fā)現(xiàn)：當(dāng)項目進展到80%的時候，項目團隊往往就“撞墻”了。像馬拉松運動員跑到20英里標(biāo)志點一樣，項目團隊經(jīng)過幾個月的努力奮斗，每一個人都身心俱疲。有時候當(dāng)團隊遇到困難時，我們就停滯下來，并且無法重獲生機。這樣項目剩下的20%工作量似乎永遠(yuǎn)也完不成，最后，我們基本上都是跌跌撞撞地走向終點。但有時某些團隊可以穿越那堵墻，重新恢復(fù)生機，再次調(diào)整好步伐。在任何情況下，能夠重獲生機源于團隊中一些人的優(yōu)秀品格，他們能夠減輕團隊的工作負(fù)擔(dān)，營造輕松的工作氛圍，鼓舞團隊士氣，并讓每一個人都感覺良好。感謝團隊中那些愛開玩笑的伙計，他們讓團隊中的每一個人重新找回（多數(shù)是）積極的心態(tài)，準(zhǔn)備沖刺到終點。一旦我們看到這些，成功的模式似乎是顯而易見的，但要看到它們，我們必須學(xué)會相應(yīng)的方法。當(dāng)我開始思考這個問題的時候，我就在琢磨我們是否可以建立一套指標(biāo)，以便給我們一個明確、客觀的方法來識別、分析并討論軟件開發(fā)團隊的成敗以及全方位地看待程序員的技能和貢獻。這并非只是一種評判績效的方法，而是一種有助于我們更好地理解和獲得成功的關(guān)鍵因素，并且它指明了從哪里和如何提高。我在自己的團隊中進行了一些嘗試，并取得了優(yōu)異成果。令人鼓舞的是，這些方法對其他人也同樣適用。本書是我對這些想法和實踐進行分析的一次嘗試。在這一方面，很少有關(guān)于軟件開發(fā)團隊度量的材料——無論是書面的或其他方式的。我們有關(guān)于面試、技能測試、項目估算、項目管理以及團隊管理的大量書籍，還有關(guān)于敏捷和其他更有效提高開發(fā)流程的方法學(xué)之類的書。但是，我們從未有過討論或探尋一種量化分析方法，該方法通過理解個體程序員的技能和工作來提高軟件開發(fā)團隊的效率。目前絕大多數(shù)軟件開發(fā)團隊所使用的度量，一般是項目估算或項目管理過程中的一個簡單的計數(shù)集合。我們使用bug數(shù)量、任務(wù)數(shù)、時間增量（時/天/周）以及敏捷團隊中的故事點數(shù)（storypoint）和速率（velocity）來度量。項目估計中也有些更復(fù)雜的系統(tǒng)和工具，如使用千行代碼量（KLOC）和功能點之類的數(shù)據(jù)進行規(guī)模度量。但我們常用的度量標(biāo)準(zhǔn)沒有提供足夠的深度來回答我們所面對的很多關(guān)鍵問題，例如：·我們的軟件開發(fā)團隊可以變得多么優(yōu)秀？·什么樣的團隊成員才能有助于團隊的成功？·哪種能力的提高有助于團隊取得更大的成功？如果我們不能很好地回答這些看似簡單實則深刻的問題，或者缺乏一種清晰的方式來討論和思考這些問題的答案，那么作為個人和團隊成員，我們并未竭盡所能去取得成功。當(dāng)然，我們必須從根本上探究成功究竟是什么，以及如何衡量軟件開發(fā)團隊的成功，而不是想當(dāng)然地認(rèn)為這些可以得到充分解決，而事實上這些問題還存在。在接下來的內(nèi)容中，我將嘗試建議一些全新的、與眾不同的方式，來幫助我們更好地理解這些問題以及得到可能的答案。我是個體育迷，因此在本書的很多地方，我選擇用體育來作類比。然而，這并不意味著為了理解本書中的這些概念，你需要喜歡或者懂得體育運動。像所有的類比法一樣，其目的只是幫助我們更好地領(lǐng)會及更容易記住一些概念。就個人而言，我認(rèn)為采用體育類比來探討軟件開發(fā)團隊是恰當(dāng)且饒有樂趣的。我把軟件開發(fā)團隊想象成一支球隊。通常，軟件產(chǎn)品是通過團隊而不是單個人開發(fā)出來的，盡管有單個程序員獨自完成工作的例子，但此時那位程序員一個人扮演了一個團隊里的各種角色。我們知道，在體育比賽中，成功的球隊需要球員之間能夠互補，而不需要也不應(yīng)該要求每個人具備同樣的技能。球隊里除了需要擅長跑動、傳接球的球員，也同樣需要擅長防守和搶斷的球員。不是所有的人都擅長做同一件事。事實上，所有球員都擁有相同優(yōu)勢的一支球隊，不管這個優(yōu)勢有多強，大多數(shù)時候都比不上擁有不同的優(yōu)勢互補技能的球員的球隊。因此，只有球隊中的每一個球員都做好自己的本職工作，球隊才能取得成功。通過使用統(tǒng)計分析來度量程序員的初步想法來自于體育活動中有組織的量化分析法。計算機和軟件已經(jīng)帶來了職業(yè)球隊隊員統(tǒng)計數(shù)據(jù)分析的巨大變化，以及幫助他們確定隊員的哪些技能可以最直接地幫助球隊獲勝。比爾詹姆斯和其他的記錄分析家已經(jīng)建立了一個圍繞棒球運動員進行統(tǒng)計分析的學(xué)科，稱為“賽博計量學(xué)”。通過作者MichaelLevis的書《Moneyball》、《TheBlindSide》和他在《紐約時代雜志》以及其他出版物上的文章，這些新的方法已普及到球隊的管理中。將這些新方法應(yīng)用到球隊管理中的先驅(qū)在數(shù)據(jù)分析領(lǐng)域都接受過較多的訓(xùn)練，比如DarylMorey（NBA休斯頓火箭隊總經(jīng)理）在美國西北大學(xué)主修的是計算機科學(xué)，PaulDePodesta（MLB紐約大都會隊副董事長，前洛杉磯道奇隊總經(jīng)理）在哈佛大學(xué)主修的是經(jīng)濟學(xué)。這個應(yīng)用于體育中的新方法，相對于占大多數(shù)的、基于主觀和直覺判斷的人才評估和球隊建設(shè)的方法，經(jīng)常被看做一種應(yīng)變和遷移。多數(shù)球隊現(xiàn)在都屬于很大的企業(yè)，擁有大量的資金。在這個新時代里，球隊的管理者花費更多的時間來收集和分析度量數(shù)據(jù)，用更合理和可預(yù)測的方式來幫助打造獲勝的球隊（就像《Moneyball》描述的，用更有效的成本效益和盈利的方式）。度量并不是要代替?zhèn)€人的直覺和創(chuàng)造力，而是幫助我們增進了解。這個新方法中所遵循的關(guān)鍵步驟包括：·發(fā)現(xiàn)測量獲勝球隊和失敗球隊差異的方法?！ぐl(fā)現(xiàn)測量單個球員對球隊貢獻大小的方法。·確定那些決定球隊勝負(fù)的關(guān)鍵球員的特征。發(fā)現(xiàn)體育中有意義的度量指標(biāo)和公式的過程不是一成不變的，而是一個持續(xù)演進的過程。很容易理解，許多重要而細(xì)微的技能難于測量和分析，比如防守型球員能發(fā)現(xiàn)帶球球員的本能，或者在壓力下進行比賽的能力。例如，比爾詹姆斯在關(guān)于棒球的連載文章和年鑒中所介紹的新的度量指標(biāo)和思路，一些被人采納和使用，一些被改進了，也有一些用處不大，逐漸消失了。和公開的演進相同，度量指標(biāo)也在悄悄地演進。體育運動是一個競爭性領(lǐng)域，因此球隊實際采用的統(tǒng)計數(shù)據(jù)和公式是保守的機密。很多分析師在公開撰文的同時，也為單個球隊充當(dāng)私人顧問的工作。TheoEpstein（MLB紅襪隊總經(jīng)理）以及BillyBeane（MLB奧克蘭運動家隊總經(jīng)理）可能會彼此分享一些信息，他們也都可從大社區(qū)中眾所周知的度量指標(biāo)中獲益，但最后他們都在試圖戰(zhàn)勝對方，因此，屬于他們方法中的某些元素，他們組織之外的人是無法知道的。有別于大體育聯(lián)盟的競爭壓力，我們的軟件開發(fā)領(lǐng)域不那么公開化，大多數(shù)程序員也不在公眾的視線范圍內(nèi)。我們沒有或者從來就不會有粉絲關(guān)注我們的統(tǒng)計數(shù)據(jù)，或者把我們的海報貼在他們家墻上（有點兒可怕的想法）。頗具諷刺的是，我們所在的這個領(lǐng)域，在許多方面使體育（以及其他行業(yè)）的深層的統(tǒng)計分析成為可能，但我們自身并沒有擁抱或者完善地考慮量化分析在我們軟件開發(fā)領(lǐng)域中潛在的益處。像其他工作者一樣，我們可能很自然地懷疑是否可以找到一個好的度量指標(biāo)，是否存在一個真實有效的例子，并且也可能擔(dān)心這些統(tǒng)計數(shù)據(jù)會被管理者錯誤地運用到績效考核中等。然而，本書的前提是，在我們的領(lǐng)域中，有多種技能和結(jié)果是可以真正地測量的。從那里我們能夠針對我們自己和團隊獲得有意義及有用的見解。這些數(shù)字不是非黑即白，并且依靠個別的幾個數(shù)字無法說明全部。知道DerekJeter的平均安打率（battingaverage）或者TimDuncan的投籃命中率，只能告訴你他們作為一個高效的球員或者隊友的一個很小的部分，但當(dāng)我們看到多個統(tǒng)計，我們就可以識別個體和團隊的模式，有時我們的發(fā)現(xiàn)甚至是意外的而且富有啟發(fā)性的。讓我舉例告訴你一個我曾管理了多年的軟件開發(fā)團隊的故事。注意：關(guān)于本書中的一些故事的說明：這些故事來自我之前的工作經(jīng)歷，但在很多案例中，這些故事做了簡化或概述，以傳達要點。為了保護個人隱私，我將不使用姓名，包括我本人。這個示例發(fā)生在一個風(fēng)險投資創(chuàng)業(yè)公司，這個團隊有6位程序員和3位測試人員（本書重點關(guān)注程序員，因此在這個例子中，我將著重描述他們）。我們前兩年的經(jīng)歷中有三個關(guān)鍵階段：1.0發(fā)布版的最初開發(fā)工作，大概花了9個月的時間；1.0版本發(fā)行之后，我們花了6個月的時間支持第一個客戶和開發(fā)1.1版本；接下來又花了大概9個月的時間來開發(fā)2.0發(fā)布版。這個團隊擁有3位資深程序員，每個人都擁有超過10年的開發(fā)經(jīng)驗和優(yōu)秀的領(lǐng)域知識，還有3位初級程序員，擁有很好的教育背景及大約兩年的商業(yè)軟件開發(fā)經(jīng)驗。在這兩年中，所有的資深程序員依然留在團隊中，但其中兩位初級程序員在完成第一年的工作之后就離開了這個團隊，之后我們又招聘了兩位新的程序員。我們的執(zhí)行委員會和投資者認(rèn)為我們最初的1.0版本取得了巨大的成功。我們在一個關(guān)鍵的行業(yè)展覽中贏得了大獎，并且收到了許多正面的產(chǎn)品評價。許多中間商對我們感興趣，客戶評估的數(shù)量兩倍于我們的預(yù)期，以至于我們的銷售人員忙得不可開交。該預(yù)制（on-premise）的軟件解決方案運行在客戶的環(huán)境中。在產(chǎn)品發(fā)行后的第一個季度，收入也同樣好于預(yù)期。這有足夠的理由使得我們的軟件開發(fā)團隊感覺良好，每一個人都在夸獎我們。但是，我們的1.0版本真的成功嗎？我們花了一些時間才意識到這個問題，通過探查當(dāng)時的數(shù)據(jù)，應(yīng)該能夠發(fā)現(xiàn)一些嚴(yán)重的問題。關(guān)鍵而糟糕的事實是：當(dāng)我們成功地獲得了知名度，強化了客戶興趣的時候，每個試用的客戶平均要來7個電話尋求客戶支持。盡管每個客戶事實上都收到了安裝程序和安裝幫助。這7個電話使得需要平均3整天與客戶一起工作來調(diào)查問題，而且結(jié)果證明每個客戶平均在產(chǎn)品中發(fā)現(xiàn)了從前不知道的3個新bug。花在支持客戶試用（包括輔助支持的時間和修改重大產(chǎn)品問題）的程序員時間是以周為單位來計算的，而不是以小時或者天為單位的。那些看似積極的收益也在誤導(dǎo)著團隊。由于幾單大的生意，我們超出了早期的收入計劃，但是我們從評估者到真實客戶的整體轉(zhuǎn)換率及轉(zhuǎn)換所花的時間遠(yuǎn)不能滿足達成一個成功業(yè)務(wù)的要求。這種情況至少部分是因為從支持工作量和發(fā)現(xiàn)bug的數(shù)量上反映出的可用性和質(zhì)量問題。換句話說，雖然局外人可能認(rèn)為我們的初始發(fā)布版取得了巨大成功，但是事實上它充其量不過是部分成功。圖1-1里的數(shù)據(jù)揭示了新用戶與bug和支持問題相比是多么微不足道。圖1-11.0發(fā)布版的關(guān)鍵指標(biāo)所揭示的關(guān)鍵問題一覽還有另外一個大問題。隨著時間的流逝，團隊里的一些程序員遇到了麻煩。花在刺激的新功能上的時間越來越少，花在乏味的問題調(diào)查和bug修改上的時間越來越多，加上初創(chuàng)階段緊張的支持工作，成員間和團隊內(nèi)開始顯露出裂痕。個性差異被放大，某些程序員慢慢地開始彼此回避，甚至在工作場所大喊大叫也常有發(fā)生。在1.0版本發(fā)布后的6個月，即在團隊提供支持和開發(fā)1.1發(fā)布版的這段時間當(dāng)中，團隊內(nèi)充滿了混亂，甚至是災(zāi)難，盡管團隊之外的人依然覺得一切都很好。每個程序員的大部分時間都花在了bug的修改上，我們不得不延遲大多數(shù)的產(chǎn)品增量改進。1.1版本修復(fù)了所有嚴(yán)重的bug，依然還有很多問題留到了發(fā)布之后，支持工作的負(fù)荷和轉(zhuǎn)換率并沒有實質(zhì)性改變。接著，突然有一天，團隊里所有的事情都變得好了起來。盡管客戶支持的工作比率依然還是那樣，團隊卻開始更有效地處理軟件中的問題。每個軟件問題涉及了更少的人，更多的時間被解放出來，用于新功能的開發(fā)和問題集中領(lǐng)域的重大改進。1.1發(fā)布版幾乎沒有任何功能的提高，卻花了6個月的時間。2.0發(fā)布版包含了許多新功能和產(chǎn)品的重大改進，相同規(guī)模的團隊僅花了9個月的時間。隨著2.0版本的發(fā)行，轉(zhuǎn)換率和軟件問題率有了顯著的改善，基于這一點，我們可以清楚地說2.0發(fā)布版本取得了更大的成功。到底發(fā)生了什么？是不是所有的人都習(xí)慣了解決問題，或者軟件問題開始重復(fù)或者不太嚴(yán)重了？從某種程度上說，確實如此。但關(guān)鍵的變化是兩位初級程序員的離職和兩位新的初級程序員的加入。兩位離職的程序員是基于自己的決定離開的。盡管在1.0版本的開發(fā)工作中他們很高興，但他們并不喜歡版本發(fā)布后的大多數(shù)支持工作。如果他們遇到不清楚的問題或代碼，他們總是習(xí)慣于尋求其他人，特別是資深程序員的幫助。隨著時間的流逝，其中一個人脾氣越來越大，并且變得好斗起來。新加入團隊的程序員在教育背景、工作經(jīng)驗或者才能方面，與離開的那些人并沒有明顯的不同。不同的地方在于，在第一個產(chǎn)品發(fā)行之后，有兩個關(guān)鍵技能變得非常重要和有用：強烈的愿望和樂意獨立解決問題，以及冷靜地甚至是開心地處理緊急狀況的能力。圖1-2展示了一個替補者是如何比他的前任做得更好的。圖1-2前任（程序員A）與替補者（程序員B）的比較展示了團隊成功的一個關(guān)鍵因素因為新的程序員擁有合適的技能，所以他們能夠獨自承擔(dān)和解決更多的問題。并不一定是我們花了更少的時間在客戶支持和修改具體問題上，但我們可以讓更少的人涉足其中從而使其工作更少被打斷。這樣，其他的團隊成員就可以把精力集中在其他的工作上。最后，我們時來運轉(zhuǎn)。因為我們曾經(jīng)與離職的兩位程序員有一些個性上的沖突，所以我們有意識地偏好和選擇那些不同個性的應(yīng)聘者。但我們并沒有意識到，這給我們整體的生產(chǎn)力和團隊成功帶了多么大的好處。在這些事情發(fā)生的時候，我們并沒有密切關(guān)注我們的度量指標(biāo)?；仡^看，我認(rèn)識到，如何關(guān)注團隊的關(guān)鍵度量指標(biāo)，能夠幫助我們在第一個產(chǎn)品版本之后更快速和更有效地做出反應(yīng)。當(dāng)人們正在為好的事情接受局外人的祝賀的時候，很難讓每個人相信存在問題或者認(rèn)識到問題的重要性。讓團隊滋生自滿的情緒很容易，或者相反，在沒有得到應(yīng)得的贊賞時士氣低落也很容易。關(guān)注產(chǎn)品開發(fā)的全過程，團隊的度量可以平衡你所得到的奉承或者批評，并且圍繞你的真實狀態(tài)和所要做的事情提供一個新的視角。圍繞著自力更生和善始善終的測量和討論，能夠幫助我們培養(yǎng)這些技能，并且保證擁有這些技能的程序員因為他們對團隊作出的貢獻而獲得他們應(yīng)得的信任和認(rèn)可。本書旨在介紹一些方法和度量指標(biāo)集（也就是程序員度量），它們覆蓋與個人開發(fā)者以及軟件開發(fā)團隊相關(guān)的多個領(lǐng)域。這些方法旨在挑戰(zhàn)我們的假設(shè)，希望借此我們能夠更好地發(fā)現(xiàn)通向成功的可能模式中哪些是可行的。為了讓它們更易理解和記憶，本書介紹的度量指標(biāo)遵循了體育中類似的統(tǒng)計指標(biāo)的命名。這些度量指標(biāo)意在提供一些術(shù)語，以便于更好地溝通，也希望我們能覺得，這些度量在我們的軟件開發(fā)領(lǐng)域是有用的。最后，可通過它們在多大程度上幫助我們回答了那些關(guān)鍵問題來衡量其價值，諸如我們面對的關(guān)于“勝利”意味著什么以及怎樣可以改善自己和團隊的關(guān)鍵問題來衡量。我希望本書中的概念能夠幫助程序員、團隊組長和管理者之間形成更有成效的對話（組織內(nèi)的或組織間的）。毫無疑問，這里介紹的許多個人度量指標(biāo)可以改進，或者將會得到改進；其中的一些想法也可能會放棄，也可能會有更好的度量有待發(fā)現(xiàn)。就我而言，我已經(jīng)認(rèn)識到以下行為的巨大價值：在團隊中定義多樣的度量指標(biāo)，識別如何度量個人與團隊的活動度量并將它們連接到組織目標(biāo)，然后在團隊內(nèi)部對這些數(shù)據(jù)進行分享與討論。即使你可能不太樂意使用度量指標(biāo)，我也希望你可以從中找到有價值的東西，并且希望本書里的一些想法能夠積極地影響你思考一些關(guān)于程序員和軟件開發(fā)團隊的問題。如果有人開始考慮這些概念，并且或許能使用本書里列出的一些方法來對程序員貢獻和軟件開發(fā)團隊構(gòu)建進行更寬、更深的理性分析，我就覺得本書成功了。必須注意，軟件開發(fā)流程中的很多參與者和技能并不在本書的討論范圍之內(nèi)。本書僅涵蓋了一部分，這是因為在一本書里很難涵蓋全部的參與者和技能，更是因為我本人并沒有為其他技能定義相應(yīng)的度量指標(biāo)。也許在將來，我們可以為設(shè)計師、測試人員、管理者或其他角色開發(fā)出度量指標(biāo)，或許也會有關(guān)于這些方面的著作。第2章測量程序員的工作不要混淆活動和成就?！狫ohnWooden，1946~1975年間擔(dān)任UCLA男籃教練度量關(guān)心哪些方面？它們有什么樣的用途？它們怎樣才能運用于程序員和軟件開發(fā)團隊中，它們又如何在其他領(lǐng)域使用？本章將開始探討度量的一般用途，以及和某些度量相關(guān)的有用特性及其他非相關(guān)特性。我將會討論不同的模式，以及度量能幫助你識別和理解的一些顯著信息。我也會關(guān)注那些我們可能使用的各種各樣的數(shù)據(jù)類型，以及那些用來確保數(shù)據(jù)精確和一致性的數(shù)據(jù)收集方法。這里提及的一些概念為度量中的關(guān)鍵概念提供了一個基本的介紹，并作為后續(xù)章節(jié)討論的基礎(chǔ)。度量的目的收集和使用度量有3個目的。當(dāng)然，目的可以更多，但我在本書中只關(guān)注這3個。度量的第一個目的是幫助你跟蹤和理解發(fā)生了什么。盡管對事件的主觀觀察有時是非常具有洞察力的，但也經(jīng)常帶有個人偏見和經(jīng)驗色彩。在觀察時，人們常被自己注意的細(xì)節(jié)和習(xí)慣的方式所左右，而且易于錯過一些自己未曾注意到或識別的事情。例如，如果你去看了一場棒球比賽，之后有人問你還記得什么，你可能會描述比賽中非常精彩的部分?？赡苁且粋€本壘打，或一次激動人心的防守。但你會忘掉更多的細(xì)節(jié)——即使這些細(xì)節(jié)就發(fā)生在幾個小時以前。有些只是你不記得了，有些也許是沒有注意到，也有些你根本就沒有看到——因為當(dāng)時你可能正在賣熱狗的小販那兒。同樣，你能記得多少以及你能描述什么，取決于你有多熟悉棒球、你之前觀看過多少次比賽，也取決于你對這場比賽的各個方面有多了解。另外，如果你看到比賽關(guān)鍵統(tǒng)計中的得分統(tǒng)計，不論你有沒有去看比賽，你都可以了解到比賽中發(fā)生的許多事情。并且，如果你看到那些完整的統(tǒng)計數(shù)據(jù)分解，包含完整的進攻及防守統(tǒng)計和所有得分方面的細(xì)節(jié)，而且如果你也知道那些統(tǒng)計數(shù)據(jù)的意思，那你就能夠看出關(guān)于那場比賽的大量信息、球員的貢獻，以及那些決定勝負(fù)的關(guān)鍵因素。統(tǒng)計，或者度量，是過去發(fā)生的事情的詳細(xì)檔案。對于球員或者球隊所做的事情，以及為什么球隊能夠取得成功或者失敗，他們提供了一個更科學(xué)的、實證分析的歷史記錄。度量也保留了歷史。日月如梭，時間不可避免地增強或者模糊了你所記得的以及你覺得重要的事情。擁有越多的統(tǒng)計數(shù)據(jù)，你就越不容易忘記或者曲解過去。例如，當(dāng)我還很小的時候，我爸爸帶我去看過UCLA的很多次籃球比賽。我記得BradHolland是我在20世紀(jì)70年代后期喜愛的球員之一，他是個很棒的得分手，但我無法記得具體的細(xì)節(jié)。然而，如果我在書中或網(wǎng)站上看球員統(tǒng)計，很多細(xì)節(jié)都會浮現(xiàn)出來。去年發(fā)生過的事情同樣會忘記，就像忘記30年前發(fā)生的事情一樣。擁有的統(tǒng)計記錄允許我們回顧以及在某種意義上再次體驗曾經(jīng)發(fā)生過的事情，并且平衡一下我們選擇性的記憶。度量的第二個目的是幫助人們溝通發(fā)生的事情。度量本身成為術(shù)語的一部分，允許一組人在討論一些情境的時候，對大家討論的同一件事有一定的信心。定義和命名度量迫使你澄清你用于溝通的語言。沒有這樣的定義和清晰的術(shù)語，在溝通的時候，你會更容易進入誤區(qū)，或者甚至都不能夠很好地討論那些事實上非常要緊的問題。例如，在棒球比賽中，眾所周知的投手投球的統(tǒng)計是投手責(zé)任失分率（EarnedRunAverage,ERA）?！巴妒重?zé)任失分”指的是在對方的得分當(dāng)中因為投手的投球所造成的部分，ERA又表示一個投手在每9局投球中（意味著一個完整的比賽）的平均責(zé)任失分?jǐn)?shù)。對理解和描述而言這意味著很多東西。但是，如果你說“那位投手的ERA是4.29”，對于熟悉棒球的人來說，你就可以快速簡潔地傳達豐富的信息。度量的第三個目的是幫助人們關(guān)注那些他們真正需要改善的事情。度量記錄了你所做和所完成的事情，并且給出了一個關(guān)于你的期望水平和實際水平的比較。缺少參考點將使得你很難知道目前所處的水平，到底還有多長的路要走，是否已經(jīng)實現(xiàn)了目標(biāo)。美式橄欖球運動員測量他們在場上和場下的表現(xiàn)。他們測量在比賽中的推進碼數(shù)、達陣得分和攔截?fù)屒?。但同時他們也測量40碼沖刺次數(shù)和225磅杠鈴臥推重復(fù)的次數(shù)，而這些事實上都不是球賽的一部分。他們之所以這樣做，是因為他們知道速度和力量是贏得比賽的重要因素。他們同樣擁有多年的數(shù)據(jù)來顯示對不同位置（如角衛(wèi)、線衛(wèi)、跑衛(wèi)和前鋒）對速度和力量的要求范圍。記錄測度來顯示球員目前所處的水平，可以幫助球員關(guān)注他們最需要提高的部分。度量不是評級在初中、高中和大學(xué)，你會得到對你學(xué)習(xí)的評級。評級應(yīng)該反映了你對一門課程的掌握程度，和你相對于班級中其他人進行的一個排名。他們可能與你的客觀測驗的成績緊密關(guān)聯(lián)，雖然很多時候測驗或者評級的其他元素包括了老師的主觀評價。在早期，評級給你提供了反饋以幫助你確定哪些方面需要提高，但是，在后期，評級漸漸地演變成了夾雜著排名及獎勵的一種競爭。由于在制度上和傳統(tǒng)上的一些原因，不論好壞，學(xué)校不僅負(fù)責(zé)教育學(xué)生，而且負(fù)責(zé)給學(xué)生進行排名。如果你打算接受度量，建立并且理解度量不是評級這一概念非常重要。度量測量特定個體的技能和貢獻，并且像我在本書中將檢驗的，一般沒有固定的“好”或“壞”分界線。成功的團隊由不同的個體組成，這些個體之間可能并且也確實存在著非常巨大的個人度量差異。就像一個橄欖球球隊，前鋒比跑衛(wèi)更慢；好的角衛(wèi)常常只有較少的攔截?fù)寯嗷蛲黄品朗?，因為四分衛(wèi)很少朝他們傳球。度量的目的就如同前面討論的一樣，為我們提供了一幅更清晰的畫面來揭示發(fā)生了什么，幫助我們更好地溝通，并且?guī)椭覀兇_定和發(fā)展有用的技能。本書后續(xù)章節(jié)將探究度量如何應(yīng)用于招聘、績效考核和其他團隊管理的方方面面。然而，在所有的案例中，只有在度量作為每個程序員當(dāng)前的工作技能、強項和弱項的反映，而不是作為一種評級方法的前提下，度量才真正有效。團隊動態(tài)雖然不應(yīng)該嚴(yán)格地認(rèn)為度量是評級，但不可避免的事實是，任何好的度量系統(tǒng)都無法避免地識別出人與人之間的必然差異。在組織中，如果人們通過勞動獲得報酬，并且他們的工資標(biāo)準(zhǔn)與他們的貢獻和技能密切相關(guān)，那么好的度量數(shù)據(jù)與工資標(biāo)準(zhǔn)和其他額外津貼就存在著一些關(guān)聯(lián)。但無論如何，你不應(yīng)該因此而太過于在意捕捉和利用度量，或者認(rèn)為人們會試圖偽造數(shù)據(jù)。如JamesSurowiecki在他的《TheWisdomofCrowds》一書中所指出的，人們大致期望在造詣和獎勵之間存在著一個真實和公平的關(guān)系。大多數(shù)人并不指望不相稱的造詣能獲得相同的獎勵，并且事實上，當(dāng)獎勵系統(tǒng)很公平并且與人們的貢獻一致的時候，大多數(shù)人是滿意的。在這個意義上，度量提供了更詳盡的細(xì)節(jié)和更高的精確度來理解人們的相關(guān)技能和貢獻（這也可以幫助你確定人們是否獲得了公平的薪水）。度量的使用可以增強個體與團隊之間的滿意度。人們只是期望一視同仁和得到認(rèn)可——你可以問一下自己，如果缺乏合理的、基于度量的方法，是否可以做到很公平。在職業(yè)運動中，球員的統(tǒng)計數(shù)據(jù)被無休止地詳細(xì)檢查，并且他們的年薪也同樣眾所周知。對于領(lǐng)袖球員，他們的合同談判通常會被媒體緊密地追蹤報道和討論。但是，當(dāng)一些談判陷入僵局時，最終球員和球隊雙方一般會尋求一個相對“公平”的合同，這個合同往往會參照行業(yè)標(biāo)準(zhǔn)及其他擁有類似技能的球員的合同，現(xiàn)在許多體育合同的爭論都引入仲裁這一獨立的機構(gòu)，通過比較程序來裁決出一份公平的薪水。在仲裁時，球員統(tǒng)計數(shù)據(jù)扮演著重要角色。JedLowrie，波士頓紅襪隊的一個全能內(nèi)場手，并沒有期望與二壘手DustinPedroia這樣的球隊公認(rèn)的明星一樣的薪水，然而，我們可以想象如果Lowrie能夠得到更多薪水肯定會很開心，我們也同樣相信他和其他像他一樣的球員，只要他們認(rèn)為其報酬是公平的，就會感到滿意。當(dāng)然，他們對于球隊的成功同樣至關(guān)重要。如果有什么區(qū)別的話，那就是球員統(tǒng)計數(shù)據(jù)在薪水談判中的運用使得程序更加公平，從而，通過這樣的方式，球員不再感覺遭受非人的待遇。在過去那個年代像道奇隊的總經(jīng)理BuzzieBavasi只告訴SandyKoufax值多少錢而不管其表現(xiàn)的日子，已成為過去。在軟件開發(fā)行業(yè)中，一般不會公開薪水，當(dāng)然你也不希望別人追蹤報道你的薪水談判。即使你這樣做，你也可以想象并非所有的團隊成員都期望相同的薪水。你同樣可以想象的是，所有的人都想要一個盡可能客觀公正的系統(tǒng)。所有這些并不是說你應(yīng)該只是根據(jù)度量來進行你的薪水討論和績效考核，這無異于把度量等同于評級。這僅僅是說，一個開放的、與技能和業(yè)績相關(guān)的度量對于構(gòu)建一個健康協(xié)作的團隊環(huán)境并不讓人討厭。更進一步，如果度量可以用于幫助團隊的改善和成功，則度量可以直接用于營造一個更健康的環(huán)境。并且，他們也更有利于理解那些之前可能就沒有完全認(rèn)可的個人貢獻。連接活動與目標(biāo)程序員是軟件開發(fā)團隊中的球員，這個軟件開發(fā)團隊是某個商業(yè)活動或者組織的一部分。至少這個組織的一些目標(biāo)同樣也是這個軟件開發(fā)團隊的目標(biāo)（因此，那些目標(biāo)也同樣是程序員的目標(biāo)）。最有意義和有用的度量允許將程序員和團隊關(guān)聯(lián)到組織目標(biāo)上。為了做到這一點，需要定義那些軟件團隊所共享的組織目標(biāo)，并且這些目標(biāo)可以精確地或近似地測量出。然后，需要確定程序員和團隊的哪些技能是可以測量的，最終，必須建立一個模型或者度量將技能與目標(biāo)關(guān)聯(lián)在一起。你可能說，運動團隊有一個清晰的目標(biāo)，那就是贏得比賽（并且最終贏得總冠軍）。他們或許還有其他目標(biāo)，比如賺錢，但是很明確，贏得比賽是一個關(guān)鍵目標(biāo)，并且這很容易進行測量和跟蹤。這只要收集個人統(tǒng)計數(shù)據(jù)和根據(jù)分析過去比賽輸贏的歷史記錄就可以完成。從那里，球隊經(jīng)理能夠發(fā)現(xiàn)趨勢，揭示關(guān)鍵洞察力——例如，對贏得比賽來說，四球上壘比盜壘更關(guān)鍵。歷史記錄的評估和如何將自下而上的度量連接至自上而下的目標(biāo)是一個不間斷的過程。隨著時間的流逝，將產(chǎn)生新的洞察力，并且新的發(fā)現(xiàn)隨著你的深入理解和環(huán)境的變化而不斷演變。好的度量像探照燈雖然度量不能告訴你哪些技能是好的，哪些技能是壞的，但是具體的度量本身顯然有好有壞。壞的度量通過沒用的或者實際不相關(guān)的細(xì)節(jié)浪費你的時間，分散你的注意力，使你不能有更深刻的理解；好的度量撥開迷霧，將燈光照耀在真正緊要的事情上。特別是那些隨著時間流逝，你或許已經(jīng)錯過、忘記或未能充分欣賞的事情。問題是，如果你不使用它們的話，你無法區(qū)分哪些是壞的度量，哪些是好的度量。如果度量太難于收集，或者太抽象并且混亂，我們可以認(rèn)為這些度量是壞的。你可以通過如下這些問題來評估一個度量本身的好壞：·這個度量是否相對易于描述和理解？·這個度量是否展示了我還不知道的一些事情？·這個度量是否清楚地涉及了我關(guān)心的目標(biāo)？如果上面所有問題的答案很明確是NO的話，那么這個度量要么需要更多的工作去完善，要么它就應(yīng)該廢棄掉。個人和團隊很自然地去選擇那些對他們來說很有意義的和提供最大價值的度量，隨著時間的流逝，如果存在更好的度量，將不再需要那些缺乏意義或者更沒用的度量。你想要描述性的度量，并且度量能夠覆蓋更多樣的技能，遺憾的是，大多數(shù)度量都只不過是混亂的和不切實際的。毫不夸張地說，已經(jīng)有上百個統(tǒng)計旨在跟蹤棒球運動員各種各樣的細(xì)節(jié)，包括諸多富有創(chuàng)造性的命名，如：貪婪得分（VulturedRuns）、魔鬼得分（GhostRuns）、構(gòu)成防御率（ComponentERA,CERA）和純粹防御率（Defense-IndependentComponentERA,DICE）。沒有人會定期地使用所有的這些度量，也沒有人懂得它們所有的意思?；蛟S在某個時候，會有人認(rèn)為所有的這些度量都可能是好的，但是，隨著時間的流逝，證據(jù)表明當(dāng)中的某些度量是沒有用的。每個分析師和每個團隊通過反復(fù)試驗來檢驗?zāi)切┙y(tǒng)計數(shù)據(jù)對特定球員位置和情形是很有意義的，并且將會沿用那些好的度量。好的度量不僅僅只是跟蹤活動。就像本章開篇引用的JohnWooden的名言揭示的一樣，活動并不等于成就。好的度量可以直接關(guān)聯(lián)到或者產(chǎn)出成就。例如，跟蹤某人工作了多久，對度量本身來說沒有任何用處。在籃球比賽中，沒有誰會統(tǒng)計某個球員運了多久的球，因為這樣跟蹤活動不能關(guān)聯(lián)到比賽的結(jié)果。但是人們會跟蹤某個球員丟掉控球（失誤），因為球權(quán)的改變可以極大地影響比賽的勝負(fù)。在棒球比賽中，救援和救援失敗是兩個好的統(tǒng)計例子。當(dāng)一個替補投手加入一個比分接近的比賽中，如果當(dāng)時他們隊是保持領(lǐng)先的，而他們成功地保持了領(lǐng)先優(yōu)勢，那么承認(rèn)他們充當(dāng)了救援。如果他們失去了領(lǐng)先優(yōu)勢，那么認(rèn)為他們救援失敗。這些統(tǒng)計數(shù)據(jù)滿足上面我們所說的好的度量的標(biāo)準(zhǔn)，也就是說，它們相對容易理解，這些統(tǒng)計數(shù)據(jù)給出我們在其他方面無法跟蹤到的一些信息，并且這些度量直接關(guān)聯(lián)球員和球隊的關(guān)鍵目標(biāo)（輸贏）。對于程序員，你可以想象一個類似于棒球的救援這樣的度量。一個程序員可能在項目的后期或者軟件發(fā)布之后，通過修改重要的問題而獲得好評。擁有這樣的度量將允許你跟蹤這些特別的“救援”，這允許你依次跟每一位成員溝通此度量，討論它的價值。并且可能確定團隊何時失去了達成“救援”的機會，你可以確定那些擁有很多“救援”的程序員可以得到認(rèn)可和欣賞。最終，就像你開始理解好團隊里的度量一樣，你或許開始識別出，如果你的軟件團隊缺少“救援”，則需要在這個領(lǐng)域提高關(guān)注或技能。假設(shè)檢驗真理并不總是赤裸裸的。基于這個原因，當(dāng)自己的某些假設(shè)成為成功的關(guān)鍵因素時，常常詢問一下自己，在這些假設(shè)中真正重要的是什么，不重要的又是什么，這樣做很有裨益。在尋找有用度量的過程中，你應(yīng)該目光長遠(yuǎn)一點，不只是蜻蜓點水，并且考慮所有的可能性。有時，某個地方不能看得很清楚，新的數(shù)據(jù)可能會幫助你找到隱藏在后面的真相。你可以收集并使用度量來挑戰(zhàn)你的假設(shè)，并且即使推翻了你的假設(shè)，也同樣有幫助，因為你真正掌握了知識。美式橄欖球有將近100年的歷史，公認(rèn)的一個教練理念是如果你的團隊在3次進攻之后未能達成首攻（將球推進10碼），并且由于距離目標(biāo)太遠(yuǎn)而不能踢任意球得分，因此你們應(yīng)該選擇棄踢。這樣，成功棄踢后，雙方交換球權(quán)，攻防轉(zhuǎn)換。如果首攻失，對方將在易于得分的位置得到球權(quán)，因此，棄踢看起來是更安全的方法。敗但在大約10年前，一些統(tǒng)計人員開始分析一些數(shù)據(jù)，如第4次進攻獲得達到10碼目標(biāo)所需的碼數(shù)或達陣得分、棄踢，以及在球場不同地點首攻控球最終得分的可能性。他們所發(fā)現(xiàn)的是，從統(tǒng)計方面來講，如果一個球隊擁有小的碼數(shù)剩余，并且他們在中場附近擁有球權(quán)，根據(jù)在第4次進攻成功得分的可能性，他們會優(yōu)先選擇第4次進攻而不是棄踢。一些思想開明的教練，如新英格蘭愛國者隊的BellBelichick開始將這些想法付諸實踐，并且現(xiàn)在這已經(jīng)成為球員在某些情形下嘗試第4次進攻并獲得達到10碼目標(biāo)所需的碼數(shù)或達陣得分的一個完美標(biāo)準(zhǔn)，因為它直接地提高了勝算。如果沒有人花時間基于從之前的成果中收集數(shù)據(jù)然后檢驗這個假設(shè)的話，那么棄踢就永遠(yuǎn)都是最佳選擇，這種老的教學(xué)理念或許永遠(yuǎn)都無法獲得改變。你又有多少關(guān)于如何交付成功軟件的假設(shè)最后同樣被證明是錯誤的呢？舉例來說，你或許考慮過以下關(guān)于程序員和軟件開發(fā)的陳述：·增加開發(fā)時間可以提高軟件質(zhì)量和客戶滿意度?！ぴ烬嫶蟮膱F隊越效率低下?！じ薪?jīng)驗的程序員可以把困難的任務(wù)完成得更好。不論上面的假設(shè)是對還是錯，如果沒有好的數(shù)據(jù)來證明，你永遠(yuǎn)都不知道。度量給出了數(shù)據(jù)來檢驗?zāi)愕募僭O(shè)。確定你想更嚴(yán)密地調(diào)查關(guān)鍵假設(shè)，特別是那些驅(qū)動你每天工作中關(guān)鍵決策的關(guān)鍵假設(shè)，同樣是一個用來確定你應(yīng)該收集和使用什么樣的度量的好方法。例如，如果你想檢驗“更有經(jīng)驗的程序員可以把困難的任務(wù)完成得更好”，你需要收集關(guān)于任務(wù)復(fù)雜度的度量，程序員經(jīng)驗級別的度量，以及完成的工作的相對質(zhì)量的度量。案例分享：局部地揭露魔力三角一組項目中的一個教訓(xùn)提供了深刻的例子，來說明度量對假設(shè)的挑戰(zhàn)。為了按時交付項目，本例中的團隊每天忙得團團轉(zhuǎn)，通常對于一個早期的啟動階段，意味著我們需要按季度交付包括新特性、功能增強和bug修訂的版本。有10位程序員負(fù)責(zé)這個項目。我有一個關(guān)于每個發(fā)布版內(nèi)容的假設(shè)。回頭看的話，我不確定這些假設(shè)都是何時何地冒出來的。我猜這僅僅是因為它們看起來像是常識，它只不過是經(jīng)常出現(xiàn)的假設(shè)之一。通常你認(rèn)為是基于客觀事實和經(jīng)驗的假設(shè)，往往只不過是基于別人告訴你的信息。由于指定了一個嚴(yán)格的截止期限，這個發(fā)布版中復(fù)雜的特性越多，最終產(chǎn)品的質(zhì)量就會越糟糕。按這個邏輯，我相信包含過多復(fù)雜特性的季度發(fā)布版同樣會包含很多的bug。我的假設(shè)是基于你也可能聽說過的那個概念：軟件開發(fā)的“魔力三角”。它表明，在更多的特性、更緊迫的進度和更高的質(zhì)量三者之間做選擇的話，你只能滿足其中兩個，而剩下那個將無法得到滿足。因為我們已經(jīng)承諾在一段很緊迫的時間里完成很多特性，所以如果我們添加更多的特性，那么結(jié)果將會是更差的質(zhì)量。有道理，對吧？為了測量每個發(fā)布版的內(nèi)容，我將每個程序員的任務(wù)（特性、功能增強或者bug修改）按最簡單到最復(fù)雜的順序，分別按1~4進行評分。軟件發(fā)布版的平均復(fù)雜度由任務(wù)的平均復(fù)雜度來確定，而工作總量由所有任務(wù)的復(fù)雜度之和獲得。為了測量每個版本的質(zhì)量，我將發(fā)布后出現(xiàn)的bug按相同標(biāo)準(zhǔn)和相似計算方法進行計算。結(jié)果令人驚奇。如表2-1所示，在兩年的6個軟件發(fā)布版中，在對每個版本實際時間數(shù)據(jù)進行標(biāo)準(zhǔn)化之后，擁有最高復(fù)雜度和工作量的兩個版本質(zhì)量并沒有更差，這里的質(zhì)量以發(fā)布后的bug數(shù)量來衡量。事實上，質(zhì)量最好的產(chǎn)品反而來自添加了很多東西的版本。并且，如果將所發(fā)現(xiàn)問題的數(shù)量按照每個版本的工作量取比值的話，兩個復(fù)雜的版本卻有相對較好的質(zhì)量。怎么會是這樣呢？首先，應(yīng)當(dāng)注意，盡管我們在某版本中加入了很多內(nèi)容，但我們很認(rèn)真地計劃和開始每個發(fā)布版從而保證我們至少是有成功機會的。雖然這些版本有很高的復(fù)雜度，但時間進度更緊迫，風(fēng)險很高而且沒有多少犯錯的余地。其次，我們擁有協(xié)作良好的杰出團隊。最后，我們注意到，由于工作進度已經(jīng)很緊湊，我們不允許任何重要的特性悄悄混進這些版本中，因此，在每個發(fā)布版本的研發(fā)開始之前，團隊就知道復(fù)雜度目標(biāo)。一種解釋可能是我們的計劃太保守，事實上我們有余力在發(fā)布版的開發(fā)中完成更高的復(fù)雜度?；蛟S我們認(rèn)為的張力并非真的如此。但這無法解釋為什么更復(fù)雜的版本有更高的軟件質(zhì)量。如果較小復(fù)雜度的版本也是同樣保守的計劃，那么這些發(fā)布版的質(zhì)量應(yīng)該更高而不是更低。你還可以找到其他可能的解釋。例如，可能某些領(lǐng)域的質(zhì)量隨著時間的流逝進行了改善。我只想說，有許多潛在的解釋，并且可以收集和研究更多的數(shù)據(jù)，來證明或駁斥這些解釋。然而，基于我對這個團隊工作知識的熟悉，我個人的推測是，其中存在其他更有意思的事情。這里是我認(rèn)為數(shù)據(jù)所說明的。好的團隊愿意接受挑戰(zhàn)，并且當(dāng)接受挑戰(zhàn)的時候，他們能夠應(yīng)付自如。如果你給他們設(shè)置更高的障礙，讓他們?nèi)プ龈嗟氖虑椋麄儠兊酶鼘Ｐ?、更有積極性，并且實際上他們確實干得更漂亮。因此，在緊湊的時間表中向發(fā)布版追加更多的工作量以及更高的復(fù)雜度且不損失質(zhì)量是可能的。事實上，如果團隊在壓力下反應(yīng)不錯并且得到激勵，產(chǎn)品質(zhì)量甚至能夠得以提高。“魔力三角”的概念沒有考慮到人類行為的特征。從某種意義上，我認(rèn)為這剛好反映出計劃方法中許多錯誤的假設(shè)，計劃方法總是認(rèn)為基于一個合理的計劃和進度表，程序員就能產(chǎn)出始終如一的產(chǎn)品質(zhì)量，其實這并不必然。為了更具權(quán)威性，我們需要更多的現(xiàn)實數(shù)據(jù)。但是，最起碼，像這個例子說明的，“魔力三角”可能是一個過于簡單化的概念，并且其可能導(dǎo)致錯誤的假設(shè)（就像之前的假設(shè)一樣）。由于我已經(jīng)了解了這個事實，因此我不會再很快打消追加多的復(fù)雜度到一個岌岌可危的發(fā)布版的想法，甚至挑戰(zhàn)團隊之前的極限可能會是一件好事。模式、異常點和離群點一般來說，我們收集和保持度量數(shù)據(jù)持續(xù)的時間越久，它們就會變得越有用。度量分析是一個模式識別的過程，意味著尋找一個重復(fù)的、可提供洞察力的模式。從單個時間段里收集到的一組度量或許會揭示出一些有趣的信息，并且我們可能會因此而得出一些有趣的假設(shè)，然而，從多個時間段里收集多個度量將可以改進我們的推測，或者把推測轉(zhuǎn)化為知識。我們在尋找模式的時候，很重要的一點是，必須認(rèn)識到并不是所有的模式都是簡單化的。我們必須仔細(xì)地尋找，而不僅僅只是關(guān)注于表面，因為從一些度量的組合中發(fā)現(xiàn)一些模式和解釋，比從單個度量中發(fā)現(xiàn)，從有效性上來說會更勝一籌?；谶@個原因，在很長的時間段中，以不連續(xù)的時間間隔收集度量數(shù)據(jù)是非常有用的，這樣可以用各種各樣好的度量數(shù)據(jù)一起來檢驗我們對事物的看法。StephenWolfran的《ANewKindofScience》盡管篇幅很長，但是作為復(fù)雜模式識別和模式多樣性方面的重要資料，也值得回顧一下。他的研究關(guān)注計算機模型和自然界，但是他的觀點是：混沌或極端復(fù)雜的事物中或許存在一些待發(fā)現(xiàn)的模式，這些模式可以直接應(yīng)用到任何領(lǐng)域的統(tǒng)計分析中。在棒球比賽中，一個廣泛使用的強大的技術(shù)統(tǒng)計是OPS，它代表整體攻擊指數(shù)（OnBasePercentageplusSluggingPercentage）。經(jīng)過上百位統(tǒng)計學(xué)家數(shù)十年嚴(yán)密的檢驗，目前他們一致認(rèn)為這個公式是用來識別擊球運動員有效性和球隊整體進攻能力的最好方法之一。相對于諸如全壘打（HR）或者得分打（RBI）那些只著眼于單個技術(shù)能力的統(tǒng)計來說，OPS更具描述性。我不想在這里深入更多的細(xì)節(jié)，簡單地說，經(jīng)過復(fù)雜的模式分析過程和年復(fù)一年的數(shù)據(jù)使用，發(fā)現(xiàn)了這個復(fù)雜的公式：[OPS=AB（H+BB+HBP）+TB（AB+BB+SF+HBP）/AB（AB+BB+SF+HBP）]。隨著我們對度量的了解與時俱進，我們也應(yīng)該嘗試區(qū)別異常點和離群點。人們常常傾向于丟棄或忽視那些“不尋?！钡幕蛘卟辉谡７秶鷥?nèi)的數(shù)字。例如，如果程序員A一般情況下花幾周的時間可以完成一定的工作量，只不過，在其中的一個時間段內(nèi)，完成的工作量可能會急劇下降，或者急劇上升，通常我們只會關(guān)注前者而忽視后者。如果我們一直都在檢查平均值的話，那么我們會很快遺忘或者丟失那些已經(jīng)發(fā)生過的事情。但是，“異常點”與“離群點”會有很大的不同，“異常點”一般指的是那些不可解釋或不可再現(xiàn)的異常發(fā)生事件，“離群點”則表示的是違背常理的事件，并且可能再現(xiàn)，甚至伴隨一些“可預(yù)知”的模式。通常對它們的定義如下所示?！ぎ惓｜c：不協(xié)調(diào)性或者不一致性，對標(biāo)準(zhǔn)的偏差?！るx群點：那種距離整體較遠(yuǎn)的某個數(shù)值。NassimNicholasTaleb和MalcolmGladwell分別在其各自的著作《黑天鵝》（BlackSwan）和《異類》（Outliers）中探究過離群點的力量。兩位作者都分別在其書中介紹了許多關(guān)于離群點扮演重要角色而獲得巨大成功的例子。在《異類》中，我們了解到，研究得越緊密，經(jīng)常就可以發(fā)現(xiàn)一些看似意外的成功后面都隱藏著一些可解釋的模式。在《黑天鵝》中，我們可發(fā)現(xiàn)，離群點常被看做一個復(fù)雜系統(tǒng)中可能發(fā)生的事件。一個清晰的事實是：忽視離群點將會限制我們對成功模式的理解。當(dāng)我們看到一些特別意想不到或不同尋常的結(jié)果時，我們首先應(yīng)該做的是嘗試確定這是否是個異常點或離群點。比如，如果是在這個測量周期內(nèi)，由于程序員A本身遇到了一些個人問題，而導(dǎo)致工作成績急劇下降，那么我們可以把這看做是異常點。經(jīng)驗法則是：·如果可以清楚地解釋為一次性發(fā)生的偶然事件，該結(jié)果就為異常點?！と绻麩o法清楚地解釋為偶然事件，該結(jié)果就為離群點，并且需要更嚴(yán)密的檢驗，持續(xù)觀察，方能確定其是否有意義或者是模式的一部分。在1993~2007年間，IvanRodriguez是美國職業(yè)棒球大聯(lián)盟中一個相當(dāng)穩(wěn)定的捕手。自1988年作為16歲的天才球員簽約以來，他14次入選全明星陣容。那段時期，他技術(shù)統(tǒng)計數(shù)據(jù)中的某些下滑大部分可以解釋為是由于他的傷病和糟糕的球隊影響到Rodriguez的表現(xiàn)機會，并進一步影響到他的技術(shù)統(tǒng)計。因此，這些可以看成是異常點。同時期另一位優(yōu)秀的捕手MikePiazza，12次出現(xiàn)在全明星陣容中，同樣擁有始終穩(wěn)定的技術(shù)統(tǒng)計數(shù)據(jù)。Rodriguez和Piazza都毋庸置疑地進入棒球名人堂。可是，Piazza在棒球史上同樣值得注意的是因為在1988年的球員選秀中，他落在了第1390順位，在第62輪才被洛杉磯道奇隊選中。雖然在高中時期他打破了學(xué)校的擊中紀(jì)錄，但他經(jīng)歷了平凡的大學(xué)生涯。他因為不符合球探尋找球員的模式而被忽視。他不像IvanRodriguez，沒有明星球員的體型，并且在那個時期的棒球運動中，他的名字和種族背景也顯得與眾不同。至少我們應(yīng)該認(rèn)識到，這種膚淺的分析是大錯特錯的，現(xiàn)在，這名幾乎落選的球員成了貨真價實的名人堂成員和捕手中的頂級全壘打擊球手。MikePiazza和其他像他一樣的人就是離群點。在軟件開發(fā)中，你可以把這個教訓(xùn)應(yīng)用到你現(xiàn)有的招賢納士的方法中。你的招聘方式是否可以發(fā)現(xiàn)那些"MikePiazza"，未來的名人堂成員的背景是否符合你的期望，或者說是否符合你之前尋找優(yōu)秀程序員的模式？你是否有一個客觀的方法來幫助你理解哪些才是團隊所真正需要的技能，并且去發(fā)現(xiàn)那些擁有或超出這些技能需求的程序員，即使他們或許沒有你一般所期望的背景或外表？在這里，度量并不是全部的答案，但是它們肯定是答案的一部分。由于依賴自身經(jīng)驗和對事物的認(rèn)識，我們總是會更傾向于看到那些我們正在尋找的事物。就像許多成功的故事所呈現(xiàn)的一樣，這種打破常規(guī)的驚人之舉幾乎沒人能夠預(yù)測到，定期發(fā)生的這些事情足以告訴我們，像這樣的故事以后還會一次又一次地繼續(xù)上演。這種驚人之舉的出現(xiàn)給我們提供了學(xué)習(xí)的機會，或許可以發(fā)現(xiàn)它們其實一點也不驚奇。如果恰巧你知道得更多，對成功的模式有更深入的理解，那么就你就可能預(yù)測到結(jié)果，并且結(jié)果也將變得不再驚奇。離群點是驚奇和意外結(jié)果的數(shù)據(jù)表現(xiàn)。在我們收集度量和分析模式時，我們有必要認(rèn)真分析離群點。峰值和谷值就像隨著時間的推移，我們可以通過度量發(fā)現(xiàn)一些模式一樣，同樣，通過度量也可以揭示一些峰值和谷值。峰值和谷值也像離群點一樣值得檢驗，這是因為它們可能極其重要。有時候，在任何時間范圍內(nèi)的最高點和最低點僅僅是活動和成就的正常變化的一部分，但有時候，它們可以揭示一些有用的規(guī)律?！熬植繕O大值”和“局部極小值”值得我們?nèi)パ芯渴欠裼惺裁次窗l(fā)現(xiàn)的解釋。每隔幾周或每個月，一般水平的棒球擊球手可能會有一場優(yōu)秀的比賽表現(xiàn)，相反，優(yōu)秀的棒球擊球手也可能會打出糟糕的比賽。在許多情況下，這僅僅是表現(xiàn)和產(chǎn)出的正常起伏。但是，在有些情況下，可能也有某種解釋?；蛟S，那個擊球手表現(xiàn)得特別好或差是針對某個特定的捕手，也或者是某個特點的球場。如果那個擊球手這種表現(xiàn)上的起落未得到考慮或研究的話，那么我們將會錯過這個可能存在解釋性原因的例子。當(dāng)我們看到一些特別高的度量值或特別低的度量值的時候，我們應(yīng)該追蹤和檢驗它們，并且尋找那些會隨著時間的推移出現(xiàn)的模式。我們希望發(fā)現(xiàn)高低值出現(xiàn)的緣由。幫助個體或團隊發(fā)現(xiàn)這些解釋，或許這樣可以幫助我們調(diào)整環(huán)境以達到想要的結(jié)果。比不頻繁的峰值或谷值更重要的是那些持續(xù)的峰值和谷值。在體育運動中，這稱為“連續(xù)取勝”和“持續(xù)低迷”。在更長的時間周期里（比如整個賽季），我們稱為“巔峰年”、“職業(yè)巔峰”和“下降年”。在體育運動中，當(dāng)球員正處巔峰時，為了球隊的勝利，球隊將會給這些球員更多的機會（特別在一些重要情形下，給他們傳更多的球或讓他們獲得更多的擊球），如果球員持續(xù)低迷，球隊為了擺脫困境，可能給球員分配新的任務(wù)，或者甚至幾天都不能上場，以嘗試改變球員的境況。在軟件開發(fā)中，是不是程序員也會持續(xù)處于巔峰和低迷狀態(tài)？如果我們可以處理好更多的持續(xù)高值和持續(xù)低值，就像球隊一樣，你或許可以加強持續(xù)處于巔峰狀態(tài)的優(yōu)勢，或?qū)ふ乙粋€方法來擺脫困境。漣漪效應(yīng)另一個重要的模式是，度量可以幫助我們確認(rèn)一個人對團隊中其他成員的影響。例如，優(yōu)秀的程序員，可能使其他程序員黯然失色，也可能幫助其他程序員更迅速地提高他們的技能。最難識別和確定的是那些漣漪效應(yīng)的模式，但是一旦發(fā)現(xiàn)這種模式，這可能帶來最大的價值。個體對團隊的正面影響或負(fù)面影響是決定團隊是否大于或小于個體之和的重要因素。我們可以檢驗的并且同等重要的另一個相關(guān)模式是，特定的人在一起工作所產(chǎn)生的結(jié)果。在這種情況下，你不會看到太多個體對其他人的影響，但是會看到某些特定的人員組合是否會更有效。這種模式的目的是識別那些明確良性或惡性的關(guān)系，因此，我們可以利用這些信息成功地定位我們的團隊。在過去的十年里，籃球和冰球統(tǒng)計學(xué)家花了很多的時間和精力去分析當(dāng)某些特定的球員組合在場和不在場的結(jié)果。這些分析關(guān)注球隊在比賽中的進攻及防守成績，以及比賽中一些特定的得分，比如在籃球比賽中的“關(guān)鍵時刻”——非常重要的最后4分鐘。這些技術(shù)統(tǒng)計數(shù)據(jù)在球員效用的分析上是非常重要的，同樣，教練可以根據(jù)這些信息決定在某個特定時刻哪些球員應(yīng)該在一起打球。在任何涉及人類活動的團隊中，漣漪效應(yīng)與個體或人員的組合相關(guān)。并且這個效應(yīng)可能不是這些個體本身所認(rèn)同的，因為人格特質(zhì)的不同，他們的判斷在大多數(shù)時候是有偏差的，這決定了誰是他們最能共處的，誰又不是。但是有時，最有效的人員組合并不必然是那些彼此最喜歡的人。我們可以在軟件開發(fā)的團隊中找到相同的模式。有些程序員會讓身邊的人變得更優(yōu)秀，并且有些程序員組合在一起會變得特別有效，而其他的組合卻不是。理解怎樣客觀地確定和測量漣漪效應(yīng)是非常難的，特別是團隊成員個體的看法可能不會反映事實的真實性。可重復(fù)的成功雖然度量可以提升我們的理解力，并且我們可以在許多方面因此而受益。但我們追尋的第一要務(wù)是可重復(fù)的成功模式。如果找到，這些模式可以指出哪些是我們團隊所需要的，以幫助我們最大化成功的概率和最小化失敗的概率。常言說“人算不如天算”，就眼前來說，這或許是對的。但是，幸運并不是保持穩(wěn)定績效的內(nèi)因（雖然很多賭徒渴望它是）。高度熟練的個體或團隊看起來是幸運的，但是他們始終如一的成功緣于他們的努力工作和計劃。某些人或許得到了“機遇”或有個“好運氣”。但是隨著時間的流逝，這種運氣總會用完。也就是說，再經(jīng)過很長的一段時間，個體或團隊（在任何涉及技能和團隊工作的領(lǐng)域）一般只會取得他們應(yīng)得的成功。在體育運動中，我們可以看到很多球員或球隊取得一次或短期成功的例子，但是這些成功并不能長期持續(xù)下去。很多球隊可能只有短期的熾熱表現(xiàn)，取得一兩周的連勝。但是，經(jīng)過整個賽季，如果這些球隊不具備真正始終如一地取得勝利的要素，那么熾熱的表現(xiàn)就不能持續(xù)，并且經(jīng)常被低迷表現(xiàn)所抵消。我們同樣可以看到一些從某些情形中受益的球員。在棒球比賽中，如果球隊獲得很多跑壘得分，那么雖然投手在比賽中有太多糟糕的投球，但還是可能贏得比賽。投手應(yīng)該因為贏得了比賽而得到積分嗎？在棒球比賽中，在這種情況下投手確實會得到積分，這就是為什么勝負(fù)不應(yīng)該是投手技能或球隊價值的好的度量，并且也不是可重復(fù)成功的一個好的指標(biāo)。我們需要認(rèn)真地思考軟件行業(yè)定義和測量成功的方式。比如，有時雖然生意失敗了，但軟件開發(fā)團隊獲得了成功，或者恰好相反。生意上的成敗并不一定反映軟件開發(fā)團隊的成敗。關(guān)于這一點，我會在后面討論更多的細(xì)節(jié)。一旦我們定義了成功，就可以分析軟件開發(fā)團隊取得始終如一的成功的模型。我們同樣可以分析在那個時期里取得成功但不能維持那一水準(zhǔn)的那些團隊。最后，我們也需要考慮那些一直都沒有取得成功的團隊。檢驗我們可以接觸的所有案例，可以幫助我們開始確定那些成功的因素和模式，幫助我們更好地了解那些有助于團隊取得成功的技能和貢獻。從越多的項目收集越多的數(shù)據(jù)，就越能有助于我們確定可重復(fù)成功的模式。發(fā)現(xiàn)那些分別與成功失敗相互關(guān)聯(lián)的度量，并且增加我們的學(xué)問。我們的數(shù)據(jù)或許沒有說服力，但是可以給我們的進步提供足夠的洞察力。一個簡單的例子是，在很多成功的項目中，我們可以發(fā)現(xiàn)團隊擁有很多相互幫助的程序員，但是在那些失敗的項目里，程序員之間的互動很少。如果這是真的，為了提高未來項目的成功，讓團隊里的每個成員都了解這一點是非常有幫助作用的。度量幫助我們確定這樣的模式，并且有助于與他人交流我們的發(fā)現(xiàn)。理解度量的限制度量和統(tǒng)計分析的使用是一項實踐和方法論，有助于發(fā)現(xiàn)模式及檢驗假設(shè)，提高我們對過往的認(rèn)知，并且美化我們的未來。度量的解釋能力是抽象的，也不是十全十美的。從實際上來說，我們收集的度量并不能給出一幅完整的畫面，用于呈現(xiàn)程序員的工作或者復(fù)雜的團隊動態(tài)及通向成功的所有元素。在棒球運動中，雖然WHIP（保送加上被按打除以投球局?jǐn)?shù)）這個技術(shù)統(tǒng)計數(shù)據(jù)可以幫助我們確定一個投手的效率，但它并不能完整地描述為什么SandyKoufax那么獨特。沒有哪個統(tǒng)計數(shù)據(jù)可以完整地測量他對勝利的渴望和專注能力。雖然贏球和球隊數(shù)據(jù)統(tǒng)計是一支勝利之師的指標(biāo)，但是這一切加上個人數(shù)據(jù)統(tǒng)計也無法完全解釋為什么在1975年，辛辛納提紅人隊會作為那個時代的一支偉大球隊出現(xiàn)在球迷的心目中——因為球隊的偉大還在于他們超凡的人格和魅力。我們不能由于沒有獲取太多的度量數(shù)據(jù)而簡單地認(rèn)為度量是沒有用的。反之，我們應(yīng)當(dāng)承認(rèn)度量的局限性，盡可能使用那些度量所能提供的好處。對于更好度量的探索不會停止，沒有盡善盡美，有更多的東西等待我們測量和學(xué)習(xí)。案例分享：意料之外的成功因素這是個關(guān)于意外的度量的故事，之前我并沒有發(fā)現(xiàn)它與軟件團隊和程序員的成功有多大的關(guān)聯(lián)。這個例子來自一個工作在大型組織里的軟件開發(fā)團隊，大概有500名員工被安排在一個樓層里，樓層是開放的，但由許多的小隔間組成。我一直非常信仰“關(guān)門”政策，也就是我倡導(dǎo)延長程序員的“安靜”時間。程序員不應(yīng)該被打斷，這樣他們一旦進入狀態(tài)，就可以保持足夠的專注。因此，我一直避免在一天中開過多的會議。并且從個人角度來說，當(dāng)程序員正在工作的時候，我會努力避免打斷他們。我個人也不愿意被打斷。我的理論曾經(jīng)是：增加不中斷的工作時間能夠提高生產(chǎn)力和質(zhì)量。為什么我說是“曾經(jīng)的”理論呢？這僅僅是因為我偶然注意到的而非刻意發(fā)現(xiàn)的事情。如前所述，我之前心存偏見。如果我能選擇的話，我會讓每個程序員都坐在辦公室里，并且關(guān)上辦公室的門。事實上，這個公司里的每個人都待在一個個小隔間里，每天都時刻遭受隨意走動的人的干擾。在我們發(fā)布周期的中間階段，當(dāng)程序員正在為產(chǎn)品功能增強和新特性而努力工作的時候，有一些程序員開始向我抱怨他們正在遭受太多的干擾。技術(shù)支持人員向他們詢問一些產(chǎn)品問題，銷售工程師向他們詢問一些新特性是怎樣工作的，并且產(chǎn)品經(jīng)理和市場部人員也在向他們獲得一些來自客戶、分析師和媒體界的問題的答案，我也同樣遭受很多這樣的干擾，因此，我理解他們在說什么。有這么多的抱怨，我開始思考可以做些什么。或許我們可以利用一個周末，用水泥磚塊修一堵高墻。不過，隨著時間推移，我注意到另一件事。那些遭受最多干擾的程序員也一直在抱怨，但同時也產(chǎn)出了好的軟件：新的特性、關(guān)鍵的改進以及bug的修復(fù)。他們前瞻性地處理那些在很長時間之前就隱匿的東西，并且在革新方面有顯著的增長。這些人當(dāng)中有一些是我們團隊中的頂級成員，這就是他們會比其他人遭受更多干擾的原因。雖然他們在抱怨，但是他們的工作并沒有因此而耽擱。事實上，他們的工作比之前做得還要好。我意識到雖然不斷增加的干擾正在騷擾程序員，但事實上也在幫助他們。這將讓他們?nèi)ニ伎几嗾嬲挠脩魡栴}，了解更多人們感興趣的是什么，并且讓他們對質(zhì)量和技術(shù)更敏感。頻繁地與外界打交道，開發(fā)團隊會變得身心健康。受到干擾之后，需要花一點時間重新回到編程狀態(tài)中，但是程序員會多知道他們之前并不知道的一些事情。這種結(jié)果有利于編寫好的軟件，以及獲得更新穎的解決方案。從那時起，一旦我看到了這種模式，我就能一次又一次地再看到它們。我習(xí)慣性地認(rèn)為打斷是一件壞事情，我曾試圖在工作時間把我自己和程序員遮蔽保護起來。今天，我依舊避免那些安排在一天的中間時間的會議。但是如今我事實上將“打斷”作為我跟蹤的一個關(guān)鍵度量。我這樣做并不是想確定程序員不能得到太多的打斷，而是想確定他們是否頻繁地被打斷?，F(xiàn)在，我需要程序員被打斷。我需要他們自發(fā)地與開發(fā)團隊之外的人進行交流互動。對于那些沒有遭受打斷的程序員來說，一旦他們擁有足夠的經(jīng)驗，我也會嘗試把他們帶到無休止的打斷中?，F(xiàn)在我更喜歡部門之間交叉安排位置，具有開放的樓層規(guī)劃和開門的辦公環(huán)境。打斷是否具有價值，或者打斷是否對那些在家里或遠(yuǎn)程辦公的程序員也擁有同樣的效果，說實話我也不知道。我不打算討論那些在遠(yuǎn)程辦公場所中來自外人的打斷，比如，在家里辦公時來自他們小孩的打斷。但如果他們受到的打斷來自于軟件開發(fā)團隊相關(guān)人員的郵件和電話，并且他們處理這些干擾，這些干擾所產(chǎn)生的效果或許就是類似的。我也跟蹤?quán)]件和電話的打斷，但因為與我工作的程序員都是在同一地點的，所以我缺乏和遠(yuǎn)程工作人員相關(guān)的高質(zhì)量數(shù)據(jù)。我可以說的是，我認(rèn)為郵件和電話打斷的影響與辦公室里人際間的影響類似，因此我相信對于遠(yuǎn)程辦公的程序員來說，那些打斷對他們會擁有相同的效果。擁有關(guān)于打斷的度量可以幫助我們跟蹤這樣的效果，但是同樣它建立了一個與程序員溝通這些交流價值的手段。它可能并不能減少在打斷時刻的煩惱，但是當(dāng)你懂得打斷是怎樣積極地促進團隊成員學(xué)習(xí)以及正面地影響軟件質(zhì)量后，他們會更容易接受打斷的煩惱。有價值的數(shù)據(jù)本書后續(xù)章節(jié)將討論一些特定的程序員度量。某些度量相當(dāng)簡單，基于產(chǎn)品bug這類原子數(shù)據(jù)；而有些度量相對更復(fù)雜一些，它們需要利用公式以及多個數(shù)據(jù)元素的組合。無論如何，在深入探究特定的度量之前，我們都應(yīng)考慮各種可用于程序員度量的數(shù)據(jù)類型，并思考這些數(shù)據(jù)是否有用處。我們需要廣泛而深入地思考那些令人關(guān)注的、新的數(shù)據(jù)元素，因為它們能夠帶來更有意義的度量。同樣，程序員和軟件團隊的工作需要關(guān)聯(lián)到團隊和組織的目標(biāo)。我們也同樣需要認(rèn)真地思考如何確定這些數(shù)據(jù)。下面的列表是我發(fā)現(xiàn)的一些有用的數(shù)據(jù)示例，將在后續(xù)章節(jié)深入討論。此處只是說明性質(zhì)的，因此僅僅描述了信息的類別或分類，而具體的數(shù)值（例如計數(shù)或者平均值）會在后面的內(nèi)容中討論?！こ绦騿T加入團隊的時間?！F隊規(guī)模、團隊優(yōu)化和團隊建設(shè)?！ぐ磸?fù)雜度分類并由程序員完成的任務(wù)?！こ绦騿T協(xié)同完成的任務(wù)或程序員幫助他人完成的任務(wù)?！ぬ貏e緊急的任務(wù)，如修復(fù)嚴(yán)重的產(chǎn)品問題?！わ@示程序員超常的創(chuàng)造力、創(chuàng)新和主動性的任務(wù)?！ぱ悠诘?、失敗的或者取消的任務(wù)?！こ绦騿T參與的項目、產(chǎn)品和產(chǎn)品領(lǐng)域?！せㄔ谌蝿?wù)上的時間?！せㄔ跁h上的時間，或者處理自己中斷的事宜花費的時間?！た蛻舭l(fā)現(xiàn)的問題，以嚴(yán)重性和復(fù)雜度進行分類?！榱丝蛻糁С止ぷ鞫M行聯(lián)系的次數(shù)（電話、郵件或者聊天）?！べ徺I或使用產(chǎn)品或特性的客戶數(shù)?！ぴ囉昧水a(chǎn)品或特性，但決定不再使用的客戶數(shù)?！と∠蛲Ｖ故褂卯a(chǎn)品或特性的客戶數(shù)。·維持、獲得或直接競爭對手失去的客戶數(shù)?！漠a(chǎn)品或特性的改變中獲益的現(xiàn)有客戶數(shù)。·從產(chǎn)品、特性或者其他完成任務(wù)中獲益的內(nèi)部員工數(shù)。以上僅是可使用在度量中的一些數(shù)據(jù)類型的例子。除了本書中提及的一些數(shù)據(jù)之外，毋庸置疑，也確實存在其他有助于程序員度量的數(shù)據(jù)類別。按一般原則，極有可能我并未完全嘗試或考慮過許多潛在的數(shù)據(jù)。但對于有些數(shù)據(jù)類型，我本人曾經(jīng)嘗試或者深入思考過，而由于各種原因，這些數(shù)據(jù)并不是很有用或者存在更好的選擇，因此本書中沒有使用這些數(shù)據(jù)類型。下面是關(guān)于這些排除的數(shù)據(jù)類型的幾個例子以及我排除它們的原因。千行代碼量（KLOC）我們常常認(rèn)為用代碼行數(shù)（KLOC代表1000行代碼）來測量程序員的效率是非常有用的一種方法，并且也有不少實例認(rèn)為KLOC在估計技術(shù)和降低項目估計失誤的工具方面是有用的，特別是對一些大型項目而言。但一般而言，我認(rèn)為KLOC更像是活動而不是代碼的度量指標(biāo)。我很難將這個度量指標(biāo)關(guān)聯(lián)到明確的團隊目標(biāo)上，例如客戶接受度、滿意度或者產(chǎn)品質(zhì)量。KLOC的另一個問題是，對不同的編程語言來說，它們沒有一個統(tǒng)一的標(biāo)準(zhǔn)。比如，寫1000行Java代碼所花的時間和能力與寫1000行JavaScript、XML、PHP或者Ruby代碼是完全不同的（雖然理論上可以有這樣的一個方法來進行跨語言的KLOC標(biāo)準(zhǔn)化）。最后，我認(rèn)為程序員很難認(rèn)為這個度量指標(biāo)與其工作業(yè)績或者成敗有什么關(guān)系。從而，也就很難有效地使用KLOC作為一種手段就技能與貢獻進行討論。因此，出于本書中討論的目的，我發(fā)現(xiàn)關(guān)注任務(wù)和基于復(fù)雜度的任務(wù)分類會比使用KLOC更有意義。開發(fā)階段的bug數(shù)量bug數(shù)量肯定是評定代碼質(zhì)量的一種度量。但是根據(jù)我的經(jīng)驗，在開發(fā)階段的bug不同于發(fā)布后產(chǎn)品的bug，由于存在太多的可變性，因此很難使得開發(fā)中的bug數(shù)量成為一個很有用的度量。開發(fā)過程中發(fā)現(xiàn)的bug的多寡會隨著測試人員的數(shù)量、測試的深度和代碼在開發(fā)中的成熟度而波動。如果我們在開發(fā)周期早期就開始對一塊復(fù)雜的代碼進行徹底地測試，會發(fā)現(xiàn)許多bug，但是這并不能告訴我們什么。也許會有人認(rèn)為確實存在這樣一些bug，如果bug是在程序員認(rèn)為功能已經(jīng)實現(xiàn)且完成單元測試的情況下發(fā)現(xiàn)的，它們可以成為有用的度量。但是我發(fā)現(xiàn)，在實踐中，這項指標(biāo)不太一致，也很難下結(jié)論。最后，我認(rèn)為我們僅需保持關(guān)于任務(wù)的復(fù)雜度和完成這些任務(wù)所花的時間的度量，它已經(jīng)包含了充分修改開發(fā)bug的時間，否則代碼就無法發(fā)布。如果程序員制造了許多bug，其結(jié)果就是完成任務(wù)的時間更長。對于同樣復(fù)雜的工作，花費時間更少的程序員一般更井然有序且產(chǎn)生的bug數(shù)目也較少。產(chǎn)品收入產(chǎn)品收入（毛收入或凈收入）是商業(yè)規(guī)劃和產(chǎn)品規(guī)劃中的一個關(guān)鍵部分。我們建造什么產(chǎn)品，新增哪些特性，哪些問題值得花時間去修改，都依賴于財務(wù)分析的結(jié)果。在大多數(shù)情形下，軟件開發(fā)的預(yù)算與產(chǎn)品收入有直接的關(guān)系。事情本該如此。然而，如果把產(chǎn)品收入作為軟件開發(fā)流程中的度量，去衡量程序員和團隊的成功與相關(guān)貢獻，我認(rèn)為這是有問題的。首先，很多軟件根本就沒有收入（開源項目和內(nèi)部項目就是兩個很好的例子）。即使存在收入，這也不總是與軟件和軟件開發(fā)團隊的工作直接相關(guān)。它們廣泛地依賴于折扣、不同銷售人員的能力和更多的因素（包括國家或全球經(jīng)濟）等。另一個重要的問題是，將金錢作為度量，很容易轉(zhuǎn)移注意力和帶來誤導(dǎo)。人們會變得更關(guān)注金錢，而不是度量的目標(biāo)和意義。比如，每個客戶需要為新的iPhone應(yīng)用程序付費2美元，如果今天有1000個人購買，從許多方面來說，客戶數(shù)比2000美元的毛利能提供更清晰、正面的闡釋（2000美元無法讓人留下深刻印象）。相反，如果你的公司本周僅僅成交了一個10萬美元的訂單，這個數(shù)字或許聽起來令人印象深刻，但如果關(guān)注到存在那么多的業(yè)務(wù)卻只簽訂了一份訂單，這樣的事實就需要我們更為關(guān)注。我個人的感覺是，產(chǎn)品收入的意識和理解收入預(yù)測如何驅(qū)動產(chǎn)品計劃的決策對軟件開發(fā)團隊來說是有用的。但是，作為軟件開發(fā)團隊工作進度的度量，我更愿意測量特性的交付、試用用戶到客戶的轉(zhuǎn)換率、產(chǎn)品bug數(shù)量，并且對用戶數(shù)和使用量保持關(guān)注。總之，探索新的數(shù)據(jù)類型并嘗試使用它們不會帶來損失。我們應(yīng)該樂于試驗新想法。也可以相信，其中非常有用的、合理的那些數(shù)據(jù)會顯現(xiàn)出來，而剩余的部分可以舍棄。數(shù)據(jù)選擇為度量尋找合適的數(shù)據(jù)，有點像科學(xué)，有點像藝術(shù)，但更多的是試錯。當(dāng)決定使用哪些數(shù)據(jù)時，我們會面對很多選擇。顯然，你可以提出多種多樣的測度，能獲得相同的結(jié)果，或者發(fā)生幾乎等同的一件事。例如，要決定一個程序員的質(zhì)量測試有多好，我們可以選擇去測量編寫的測試用例數(shù)、代碼的測試覆蓋率，或者發(fā)現(xiàn)的bug數(shù)量和嚴(yán)重性。我們也可以測量所有這些。一般來說，當(dāng)我不得不在多個可能使用的測度中去選擇時，我基于以下經(jīng)驗法則來決定最優(yōu)方案：·選擇最容易獲得的數(shù)據(jù)。·選擇最容易讓非程序員解釋和理解的數(shù)據(jù)。第一條經(jīng)驗法則或許平淡無奇，但第二條法則看起來就有點古怪了。為什么要關(guān)心非程序員能夠解釋和理解那些測度和數(shù)據(jù)呢？這條法則對清晰性、簡單性進行了專門測試，也就是說非程序員（例如測試人員或者技術(shù)作者）應(yīng)該也可以理解那些數(shù)據(jù)，并且知道這個數(shù)據(jù)是怎樣關(guān)聯(lián)到軟件開發(fā)的。因為好的度量的一個關(guān)鍵好處是它們具有很好的描述性，以及隨之而來的溝通改善和合適行為的驅(qū)動。度量和之后的數(shù)據(jù)能夠易于理解是非常根本的。這條法則可以重寫為“選擇更簡單的測度”，或者只是“保持簡單”。但是我喜歡用非程序員能夠解釋和理解的測度和數(shù)據(jù)進行測試。例如，考慮如何測量代碼的復(fù)雜度。一個辦法是通過源代碼的統(tǒng)計分析，產(chǎn)生可供分析的各種數(shù)據(jù)，比如關(guān)鍵字頻度、方法的長度、嵌套層級和圈復(fù)雜度。你也可以通過程序員用于改變特性、修復(fù)bug的時間，或者一定時間里bug出現(xiàn)的比率來測量代碼復(fù)雜度。就我而言，相對于自動代碼分析，我更贊成通過花費的時間和發(fā)布后的問題數(shù)量來測量復(fù)雜度。這是因為這個數(shù)據(jù)一般更容易獲得，并且更易于讓哪些非程序員或類程序員解釋和理解。在我看來，這些數(shù)據(jù)能夠讓度量也變得更易于解釋和理解，從而也更強大而有用。數(shù)據(jù)獲取很多系統(tǒng)都能幫助收集數(shù)據(jù)元素。有些可以提供易于訪問的有用數(shù)據(jù)，特別是那些直接打交道的或控制的并且與開發(fā)相關(guān)的系統(tǒng)。對度量而言最有用的系統(tǒng)之一可能就是實際產(chǎn)品本身，一些適當(dāng)?shù)氖侄魏捅O(jiān)控可以提供關(guān)于客戶采用、使用或特定特性和產(chǎn)品改變的成功的大量數(shù)據(jù)。有些系統(tǒng)可能不容易訪問，通常是你無法授權(quán)使用其他業(yè)務(wù)部門的數(shù)據(jù)。我的經(jīng)驗是，如果你向系統(tǒng)所有者或管理員解釋數(shù)據(jù)的有用性和使用目的，而且說明你并不需要保密和敏感的數(shù)據(jù)，你應(yīng)該能得到授權(quán)。有時我們可以直接從系統(tǒng)中得到數(shù)據(jù)，而有時數(shù)據(jù)是從常規(guī)報告或者其他諸如部門或財務(wù)小結(jié)的文檔中間接獲得的。在大多數(shù)情況下，每周或每個月定期地收集這些目標(biāo)數(shù)據(jù)已經(jīng)足夠。大多數(shù)的現(xiàn)代系統(tǒng)都能夠定期地報告和導(dǎo)出。對于從那些用于跟蹤程序員工作的系統(tǒng)中獲得的數(shù)據(jù)，比如項目和bug跟蹤系統(tǒng)，可以選擇每周獲取數(shù)據(jù)，并且我們可以得到程序員個體、開發(fā)團隊和項目領(lǐng)域的數(shù)據(jù)。對于那些從開發(fā)之外的商業(yè)系統(tǒng)中獲得的數(shù)據(jù)，比如客戶支持系統(tǒng)，從每月小結(jié)中獲取這些數(shù)據(jù)就可以了，但是你可能希望依照不同的產(chǎn)品領(lǐng)域?qū)?shù)據(jù)進行細(xì)分。以下是一些可以提供關(guān)鍵數(shù)據(jù)元素的系統(tǒng)。項目跟蹤系統(tǒng)例如：VersionOne、Greenhopper、Rally、MicrosoftProjectManager有效數(shù)據(jù)：任務(wù)數(shù)、任務(wù)持續(xù)時間、任務(wù)復(fù)雜度粒度：按不同的程序員和項目領(lǐng)域每周統(tǒng)計bug跟蹤系統(tǒng)例如：Bugzilla、JIRA、FogBugz有效數(shù)據(jù)：發(fā)布后bug數(shù)量、bug的嚴(yán)重性、bug的復(fù)雜度粒度：按不同的程序員和項目領(lǐng)域每周統(tǒng)計銷售機會跟蹤系統(tǒng)例如：S、MicrosoftDynamics、Siebel有效數(shù)據(jù)：機會數(shù)量、機會損失數(shù)、成交數(shù)粒度：按產(chǎn)品（在適當(dāng)?shù)那闆r下根據(jù)特性）每月統(tǒng)計用戶支持問題跟蹤系統(tǒng)例如：S、MicrosoftDynamics、RightNow、Zendesk有效數(shù)據(jù)：支持聯(lián)系數(shù)、支持案例數(shù)、案例嚴(yán)重性粒度：按產(chǎn)品每周統(tǒng)計軟件產(chǎn)品（內(nèi)置適當(dāng)監(jiān)控的設(shè)施）有效數(shù)據(jù)：用戶激活數(shù)、登錄次數(shù)、特性使用量、用戶錯誤、性能粒度：按產(chǎn)品每周統(tǒng)計像獲取數(shù)據(jù)一樣，你也需要決定怎樣保存這些數(shù)據(jù)。如果你有時間將這些數(shù)據(jù)放入數(shù)據(jù)庫，這當(dāng)然非常棒，這也有助于后續(xù)的分析。然而，我的建議是，在一開始并不需要太過于擔(dān)心存儲機制。簡單地把數(shù)據(jù)用電子表格保存，可能的話生成幻燈片或文檔形式的月小結(jié)，將是一個不錯的開始。不要讓存儲問題擋了你繼續(xù)前行的路。只要積累數(shù)據(jù)并且使用它，就將