軟件管理的開(kāi)發(fā)治理

申請(qǐng)免費(fèi)試用、咨詢(xún)電話：400-8352-114

    行業(yè)發(fā)展，例如 Agile，和目前向動(dòng)態(tài)語(yǔ)言發(fā)展的趨勢(shì) 1 ，生成了維護(hù)對(duì)關(guān)鍵的開(kāi)發(fā)過(guò)程的管理控制的新挑戰(zhàn)。這混合了維護(hù)開(kāi)發(fā)治理所需的已經(jīng)成熟的功能集合 2 。Scott W. Ambler 和 Per Kroll 在最近的關(guān)于“Best practices for lean development governance” 3 的三部分系列文章中應(yīng)對(duì)了這些挑戰(zhàn)，覆蓋了組織要實(shí)現(xiàn)關(guān)于敏捷的開(kāi)發(fā)計(jì)劃的治理所需的概念：原則和組織、過(guò)程和度量，及角色和策略。

    本文將延伸他們的討論，分析管理層能夠用于在這些變化的時(shí)代使團(tuán)隊(duì)工作的具體量度的最佳實(shí)踐，以及通過(guò)應(yīng)用這些實(shí)踐，如何利用 IBM? Rational? 基礎(chǔ)架構(gòu)來(lái)促進(jìn)被贈(zèng)與的利益。我專(zhuān)注于這些最佳實(shí)踐的子集，詳細(xì)說(shuō)明管理層可以用于計(jì)劃和支持開(kāi)發(fā)治理的方法和指南。焦點(diǎn)在于源自 Rational 基礎(chǔ)架構(gòu)的，洞察并發(fā)揮關(guān)于開(kāi)發(fā)過(guò)程的管理控制的關(guān)鍵性能指示器（key performance indicators，KPIs）。

    雖然本討論延伸并詳細(xì)說(shuō)明了 Ambler 和 Kroll 最近的系列，但是不打算討論 Agile 或者更“正規(guī)”的方法的優(yōu)缺點(diǎn)。如果有，那么這些方法可以是從軟件管理角度的補(bǔ)充，更確切地說(shuō)，在這里，為治理而描述的 KPI 一般可以應(yīng)用于軟件開(kāi)發(fā)過(guò)程。

    治理不僅僅是管理

    Albert Einstein 曾經(jīng)說(shuō)過(guò)“只有我們指向概念所談到的對(duì)象 4 ，以及將概念分配給這些對(duì)象所依據(jù)的規(guī)則時(shí)，概念才有意義?！痹谶@個(gè)精神下，我想要定義一組涉及與治理相關(guān)的管理角色和職責(zé)的公共的術(shù)語(yǔ)。通過(guò)這樣做，我希望避免疏忽地將“治理”和“管理”，以及“管理層”和“經(jīng)理”之間的混淆。

    開(kāi)發(fā)治理是管理的職責(zé)，但是管理的職責(zé)遠(yuǎn)遠(yuǎn)超過(guò)治理。管理的角色是使團(tuán)隊(duì)了解關(guān)于團(tuán)隊(duì)計(jì)劃、項(xiàng)目狀態(tài)和軌道，以及問(wèn)題識(shí)別和解決的及時(shí)切準(zhǔn)確的信息。從治理的角度看，這轉(zhuǎn)化為確保遵循組織的治理計(jì)劃，理想的情況下，按照以理想且強(qiáng)制的方式促進(jìn)對(duì)團(tuán)隊(duì)的計(jì)劃的形式。

    管理通常服務(wù)于兩種人：團(tuán)隊(duì)和客戶(hù)。管理對(duì)團(tuán)隊(duì)運(yùn)作的關(guān)注可以被認(rèn)為是對(duì)內(nèi)的，監(jiān)督管理負(fù)責(zé)的人員和運(yùn)作。對(duì)此添加了一組對(duì)外的職責(zé)：與上級(jí)和商業(yè)對(duì)手的溝通、資源分配和計(jì)劃、預(yù)算，及預(yù)測(cè)。

    實(shí)現(xiàn)與一個(gè)或其它這幾類(lèi)人之間的成功是困難的工作，在為團(tuán)隊(duì)和客戶(hù)提供充足支持的時(shí)候，平衡二者的需求確實(shí)令人畏縮。對(duì)于這些人，管理還必須增加將治理計(jì)劃加入交付和執(zhí)行的挑戰(zhàn)。

    區(qū)分“管理層”和“經(jīng)理”會(huì)更復(fù)雜。軟件行業(yè)已經(jīng)長(zhǎng)期應(yīng)用在組織圖中將“經(jīng)理”放在“程序設(shè)計(jì)人員”和“軟件質(zhì)量保證分析人員”之上的層次。

    最近的趨勢(shì)混淆了這些區(qū)別。什么是經(jīng)理？一個(gè)定義是，不僅負(fù)責(zé)軟件項(xiàng)目執(zhí)行的某個(gè)方面，而且還負(fù)責(zé)項(xiàng)目的成功的結(jié)果，并擁有與實(shí)現(xiàn)此結(jié)果相適合的權(quán)威的人。以前這意味著項(xiàng)目經(jīng)理、開(kāi)發(fā)經(jīng)理、QA 經(jīng)理、發(fā)布工程經(jīng)理，等等。但在現(xiàn)今的環(huán)境中，并隨著運(yùn)動(dòng)，例如 Agile 的促進(jìn)，執(zhí)行和結(jié)果之間的連接不斷地直接向開(kāi)發(fā)人員、質(zhì)量保證分析人員，和其它知識(shí)分子擴(kuò)展。

    這是一個(gè)健康的征兆，軟件開(kāi)發(fā)團(tuán)體正擁抱著從使團(tuán)隊(duì)具有及時(shí)的信息以及在他們的任務(wù)中取勝所需的過(guò)程洞察的其他規(guī)程中得來(lái)的經(jīng)驗(yàn)。對(duì)于個(gè)別開(kāi)發(fā)人員和質(zhì)量保證分析人員來(lái)說(shuō)，經(jīng)驗(yàn)是相當(dāng)清楚的：在您的名片上可能不是“經(jīng)理”，但是您可能是開(kāi)發(fā)管理中關(guān)鍵的部分。

    治理三元組

    隨著軟件行業(yè)的成熟，術(shù)語(yǔ)“治理”、“法規(guī)遵循”和“標(biāo)準(zhǔn)”正日益承擔(dān)顯著的角色。這些術(shù)語(yǔ)有具體的力量和含義，但只有在軟件開(kāi)發(fā)過(guò)程中所有受到影響的部分都很好地理解了這種力量和含義時(shí)，它們才是有用的。為了將這些術(shù)語(yǔ)概念化，要建立基本的框架，就考慮圖 1 中顯示的棧。

圖 1：治理三元組

自底向上考慮圖 1 中的術(shù)語(yǔ)：

    * 標(biāo)準(zhǔn)（Standards）是度量工作產(chǎn)品和過(guò)程所依據(jù)的基準(zhǔn)。開(kāi)發(fā)組織一般都擁有標(biāo)準(zhǔn)，盡管它們的表達(dá)是正式或非正式的。規(guī)章的需求還可能需要標(biāo)準(zhǔn)和標(biāo)準(zhǔn)運(yùn)作過(guò)程。

    * 法規(guī)遵循（Compliance）是根據(jù)標(biāo)準(zhǔn)對(duì)工作產(chǎn)品和過(guò)程的評(píng)估。

    * 治理（Governance）是施加管理控制來(lái)加強(qiáng)支持法規(guī)遵循的實(shí)踐，并校正未遵循法規(guī)的實(shí)踐的行為。

    通過(guò)分開(kāi)梳理這三個(gè)術(shù)語(yǔ)，并且給每個(gè)術(shù)語(yǔ)一個(gè)具體的范圍和含義，我們能夠從圖 1 中獲得靜態(tài)的表示，并且使之運(yùn)轉(zhuǎn)，如圖 2 中所示。當(dāng)看起來(lái)像動(dòng)態(tài)過(guò)程時(shí)，很清晰的是，治理三元組的每個(gè)組件都供給另一個(gè)組件，告知遵循標(biāo)準(zhǔn)的管理和執(zhí)行的接收者，以便采取適當(dāng)?shù)男袆?dòng)。

圖 2：治理三元組的每個(gè)組件都供給另一個(gè)組件

    期望的結(jié)果是為了促進(jìn)組織的成熟，達(dá)到操作效率的增加的層次，以及創(chuàng)建可以使內(nèi)部和外部審計(jì)人員審查的標(biāo)準(zhǔn)化的，可預(yù)測(cè)的過(guò)程。

    牢記我在前面部分中提到的對(duì)結(jié)果的強(qiáng)調(diào)，通過(guò)支持對(duì)標(biāo)準(zhǔn)的遵循，以及糾正非法規(guī)遵循，在治理中加入“支配”，并實(shí)施適當(dāng)?shù)目刂剖枪芾淼墓ぷ鳌?/P>

    缺少了法規(guī)遵循報(bào)告，該循環(huán)就打破了。大量無(wú)效地實(shí)施管理，并且項(xiàng)目目標(biāo)和團(tuán)隊(duì)的成功受到危害。標(biāo)準(zhǔn)失去了他們的生命力和上下文，因缺乏熟悉或故意地避免，團(tuán)隊(duì)忽視了標(biāo)準(zhǔn)。當(dāng)管理試圖實(shí)施控制時(shí)，有時(shí)候團(tuán)隊(duì)會(huì)將工作視為幼稚，或甚至反復(fù)無(wú)常的，并且沒(méi)有機(jī)制來(lái)評(píng)估影響是好的，壞的，或無(wú)關(guān)緊要的。就像古老的諺語(yǔ)說(shuō)的那樣，如果您不知道打算去哪里，那么什么方向都行。

    要使得這個(gè)動(dòng)態(tài)的過(guò)程工作，法規(guī)遵循報(bào)告是必要的，令管理層可以對(duì)開(kāi)發(fā)過(guò)程進(jìn)行觀察。當(dāng)團(tuán)隊(duì)用標(biāo)準(zhǔn)來(lái)評(píng)估法規(guī)遵循時(shí)，他們復(fù)得了管理羅盤(pán)，并能夠帶著實(shí)現(xiàn)所期望的結(jié)果的更大信心來(lái)繪制前進(jìn)的航向。他們獲得了評(píng)估管理工作的影響的能力，以便可以考察二者的風(fēng)險(xiǎn)和好處。他們從那種混亂，英雄驅(qū)動(dòng)的團(tuán)隊(duì)，動(dòng)態(tài)經(jīng)歷 Capability Maturity Model? Integration (CMMI) 6 成熟度級(jí)別為 1 的組織，轉(zhuǎn)到成熟度級(jí)別為 3 及更高 7 的更穩(wěn)定，可預(yù)測(cè)，基于標(biāo)準(zhǔn)的結(jié)果。

    關(guān)鍵的性能指示器

    一些非常聰明的人 —— 從 Lord Kelvin 到 W. Edwards Deming 到 Philip B. Crosby —— 以這樣的想法為生，一個(gè)人不可能管理不能度量的東西，過(guò)程 KPI 是當(dāng)今他們的學(xué)說(shuō)的應(yīng)用。

    某些開(kāi)發(fā)標(biāo)準(zhǔn)，例如可證實(shí)的結(jié)束和檢查點(diǎn)，可以是法規(guī)和審計(jì)遵循的需求。對(duì)這些標(biāo)準(zhǔn)的遵循證明了團(tuán)隊(duì)的完整性，以及管理變更和負(fù)責(zé)地執(zhí)行的能力。但它可能沒(méi)有確實(shí)地對(duì)團(tuán)隊(duì)生產(chǎn)力或者軟件工作產(chǎn)品的可度量的質(zhì)量的增加做出貢獻(xiàn)。

因此，在不減少更面向程序的審計(jì)標(biāo)準(zhǔn)的重要性或必要性的情況下，讓我們考慮團(tuán)隊(duì)可以用來(lái)本質(zhì)上增強(qiáng)開(kāi)發(fā)過(guò)程的項(xiàng)目標(biāo)準(zhǔn)?？偟膩?lái)說(shuō)，這些標(biāo)準(zhǔn)作為 KPI，在實(shí)現(xiàn)團(tuán)隊(duì)的結(jié)果。

    KPIs 一般分為兩類(lèi)：過(guò)程和工作產(chǎn)品。過(guò)程 KPIs 允許管理層處理開(kāi)發(fā)過(guò)程中的可變性，以便可以理解、管理，并最終容納此變化的根本原因和伴隨的風(fēng)險(xiǎn)。這個(gè)評(píng)估過(guò)程是正在進(jìn)行的管理活動(dòng)，并且有利于完成并維護(hù)可預(yù)測(cè)的，可重復(fù)的過(guò)程。

考慮相對(duì)于 CMMI，展開(kāi)與開(kāi)發(fā)過(guò)程相關(guān)的標(biāo)準(zhǔn)范圍，并且令管理層注意到提升對(duì)這些標(biāo)準(zhǔn)的遵循的關(guān)聯(lián)性和可見(jiàn)性，是從成熟度級(jí)別為 2 的“受管理的過(guò)程”轉(zhuǎn)化到 成熟度級(jí)別為 3 的“定義的過(guò)程”的關(guān)鍵成分。隨著轉(zhuǎn)化為分別與 成熟度級(jí)別為 4 和 5 相關(guān)聯(lián)的“數(shù)量上的管理”和“最佳化”狀態(tài)，過(guò)程 KPIs 增加了關(guān)聯(lián)性和效用。

    過(guò)程 KPI 的細(xì)節(jié)與過(guò)程本身相關(guān)，并且為此，必須稍微了解開(kāi)發(fā)方法、實(shí)踐和規(guī)程。然而，過(guò)程擁有跨方法邊界應(yīng)用的某些一般的特征。也許您擁有帶有強(qiáng)組件傾向的軟件工廠，或者也許您對(duì)服務(wù)于業(yè)務(wù)單元部門(mén)的開(kāi)發(fā)豎井垂直地分層。也許您正使用瀑布開(kāi)發(fā)方法，或者您已經(jīng)采用 Agile。不論您為開(kāi)發(fā)設(shè)置的什么過(guò)程，該過(guò)程擁有離散的過(guò)程。這些過(guò)程有希望由團(tuán)隊(duì)很好地定義，并且廣泛地了解，但是甚至是成熟度級(jí)別為 1 的組織都在勉強(qiáng)追求過(guò)程。此外，過(guò)程擁有確定定義的特征。它們擁有輸入、輸出，和檢查點(diǎn)，否則將其置于一個(gè) CTO 的更多彩的語(yǔ)言中，它們會(huì)有“gazintas、gazoutas，和 ga-whaaaaat”?

    過(guò)程 KPI

    過(guò)程 KPI 基于上面介紹的一般特征，并且分為兩個(gè)部分：易變率和容積。

    過(guò)程 KPI 的接受者一般是那些負(fù)責(zé)了解并優(yōu)化過(guò)程的人，以及負(fù)責(zé)隨著時(shí)間監(jiān)控趨勢(shì)，產(chǎn)生了關(guān)于過(guò)程遵循（非遵循）的洞察 8 。從開(kāi)發(fā)治理立場(chǎng)上講，過(guò)程 KPI 對(duì)管理程序設(shè)計(jì)活動(dòng)的人來(lái)說(shuō)更有效且可訴，對(duì)負(fù)責(zé)質(zhì)量保證的人來(lái)說(shuō)沒(méi)那么有效且可訴。若是真的，那么一般的理由是質(zhì)量保證沒(méi)察覺(jué)自己會(huì)影響開(kāi)發(fā)方法，或者命令對(duì)它的變更，這是功能規(guī)程的傳統(tǒng)分離，“12 尺的磚墻是用程序設(shè)計(jì)人員和 QA 之間的剃刀線蓋成的”在行業(yè)中仍舊普遍。在較進(jìn)步的開(kāi)發(fā)文化中，開(kāi)發(fā)人員和質(zhì)量保證合伙人更積極地參與測(cè)試方法和法規(guī)遵循，建立對(duì)要應(yīng)用的標(biāo)準(zhǔn)的一致同意，并且用過(guò)程 KPI 實(shí)現(xiàn)更多結(jié)果。然而，不論是傳統(tǒng)的或是進(jìn)步的，對(duì)易變率和容積的理解是評(píng)估軟件項(xiàng)目的基礎(chǔ)。

    易變率 KPI

    隨著過(guò)程從開(kāi)始到結(jié)束，它經(jīng)受著特定量的易變率。易變率度量著完成目標(biāo)過(guò)程中波動(dòng)的數(shù)量和比率。易變率一般有兩種度量方式：預(yù)計(jì)的和實(shí)際的。預(yù)計(jì)的易變率表明了完成任務(wù)、里程碑，或項(xiàng)目中所出現(xiàn)的總波動(dòng)的估計(jì)量，然而實(shí)際的易變率度量了實(shí)際出現(xiàn)的波動(dòng)。從管理的立場(chǎng)出發(fā)，易變率是熟悉的概念，與同樣包含了“預(yù)算對(duì)實(shí)際”的概念的項(xiàng)目計(jì)劃實(shí)踐相關(guān)聯(lián)。

    當(dāng)管理層了解了預(yù)計(jì)的對(duì)實(shí)際的易變率時(shí)，就能夠評(píng)估與計(jì)劃的差異，并且設(shè)法控制正要脫離控制的項(xiàng)目。從根本上，這是個(gè)治理問(wèn)題：評(píng)估對(duì)標(biāo)準(zhǔn)的遵循 —— 預(yù)計(jì)的項(xiàng)目易變率曲線 —— 從而使管理層適當(dāng)?shù)厥箞F(tuán)隊(duì)完成成功的項(xiàng)目成果。如果您想要完成標(biāo)準(zhǔn)的，可預(yù)測(cè)的過(guò)程，那么就致力于那些過(guò)程的易變率的評(píng)估和管理。這對(duì)軟件維護(hù)活動(dòng)尤其正確，它們經(jīng)常比新的開(kāi)發(fā)更容易地遵循已建立的模式。

    易變率的一個(gè)杰出的量度是單位時(shí)間的總變更，以及該量度隨著時(shí)間的趨勢(shì)的整體評(píng)估。有各種各樣的方法來(lái)度量總變更：代碼行（lines of code，LOC），修正、確定的故障、感到滿(mǎn)意的增強(qiáng)請(qǐng)求，等等。團(tuán)隊(duì)?wèi)?yīng)該在安排一個(gè)或其它的方法之前，討論相對(duì)于他們的手段和方法的這些選擇，并且應(yīng)該隨著他們能力的提高，以及新技術(shù)和方法的可用，虛心地演進(jìn)該量度。作為起始點(diǎn)，對(duì)跨項(xiàng)目階段的單位時(shí)間內(nèi)變更的總 LOC 的簡(jiǎn)單度量將繪制出項(xiàng)目的軌道，并展示出項(xiàng)目是否達(dá)到了與成功地在完成日期著陸相適合的“下滑軌道”。甚至成熟的開(kāi)發(fā)組織都經(jīng)常會(huì)發(fā)現(xiàn)，在對(duì)易變率 KPI 的首次觀察中，他們的過(guò)程遭受著偷偷通過(guò)同行審查，以及質(zhì)量保證審查的未預(yù)期且未報(bào)告的“遲的破壞（late-breaking）”變更，或者發(fā)現(xiàn)他們的過(guò)程包含與期望的 Agile 方法相反的潛伏期和延遲時(shí)間。

    容積 KPI

    容積 KPI 說(shuō)明了在開(kāi)發(fā)中生成的邏輯或其它相關(guān)工件的總量。在一些組織中，邏輯的容積可能有關(guān)聯(lián)性的想法已經(jīng)引起爭(zhēng)論，有時(shí)候會(huì)受到某種程度的懷疑，甚至輕視。然而，“容積”的基本思想對(duì)三種軟件開(kāi)發(fā)規(guī)程來(lái)說(shuō)是重要的：項(xiàng)目預(yù)測(cè)、質(zhì)量保證，和程序設(shè)計(jì)。

    影響維護(hù)成本的重要因素是正被討論的代碼基數(shù)的大小。一般確實(shí)是比起較小的代碼基數(shù)，大型的代碼基數(shù)要用更多的人來(lái)維護(hù)制度上的存儲(chǔ)并且保持最新。人們可能爭(zhēng)論維護(hù)工作是否與代碼基數(shù)的大小線性相關(guān)，而事實(shí)上對(duì)此問(wèn)題的回答可能是因素的功能，包括軟件設(shè)計(jì)方法、組件化的程度、資源技能水平、集中對(duì)分布的團(tuán)隊(duì)，以及外包或境外人員的使用。然而，對(duì)于您的管理層要明確維護(hù)團(tuán)隊(duì)的大小和組成與團(tuán)隊(duì)所維護(hù)的項(xiàng)目的大小和組成之間的關(guān)聯(lián)的最好方法是開(kāi)始度量并應(yīng)用容積 KPI。

這種 KPI 可以為項(xiàng)目預(yù)測(cè)增加好處，因?yàn)樗试S軟件團(tuán)隊(duì)來(lái)溝通，概括地說(shuō)，響應(yīng)客戶(hù)需求的團(tuán)隊(duì)的效率和生產(chǎn)力、增加請(qǐng)求，和軟件缺陷。在依據(jù)軟件開(kāi)發(fā)的客戶(hù)投資的模型的環(huán)境中，例如許多公司的 IT 部門(mén)，容積 KPI 可以作為有價(jià)值的可視化工具在同樣的頁(yè)面上從字面上加入軟件團(tuán)隊(duì)及其業(yè)務(wù)單元副本。

    容積還對(duì)質(zhì)量保證很重要，由于軟件產(chǎn)品的大小是缺陷密度比率的分母。隨著時(shí)間觀察容積的趨勢(shì)，顯示出了關(guān)于缺陷密度的一些細(xì)小區(qū)別，并且?guī)椭訌?qiáng)對(duì)這種 KPI 的洞察。舉例來(lái)說(shuō)，在質(zhì)量保證有機(jī)會(huì)發(fā)現(xiàn)并進(jìn)入與新代碼有關(guān)的缺陷之前，產(chǎn)品的容積可能在一小段時(shí)間內(nèi)快速擴(kuò)展，這將產(chǎn)生表面上減少缺陷密度的影響，因此掩飾了一個(gè)事實(shí)，實(shí)際的情況可能需要增加測(cè)試腳本或測(cè)試自動(dòng)化來(lái)審計(jì)新的代碼。類(lèi)似的情況出現(xiàn)在當(dāng)重構(gòu)代碼，將代碼基數(shù)分為更謹(jǐn)慎地合理的程序或組件集合的時(shí)候。當(dāng)整體代碼大小下降時(shí)，缺陷密度上升，看起來(lái)好像整體的質(zhì)量水平更糟糕了，既使代碼基數(shù)已經(jīng)轉(zhuǎn)移到改進(jìn)的可維護(hù)性和較多的代碼覆蓋的地方。通過(guò)監(jiān)控容積 KPI，以及缺陷密度，質(zhì)量保證可以觀察這些重要的趨勢(shì)，從而計(jì)劃。

    程序設(shè)計(jì)人員易于對(duì)容積有相當(dāng)本能的反應(yīng)，但是一般看不到代碼基數(shù)大小的整體變更趨勢(shì)，例如，趨勢(shì)可能是耗時(shí)的，并且很難得到并看出。但程序設(shè)計(jì)人員的內(nèi)臟檢查非常有意義，并且直入問(wèn)題的心臟。程序設(shè)計(jì)人員知道什么時(shí)候他們將處理腫脹的代碼，并且意識(shí)到 —— 經(jīng)常強(qiáng)烈地 —— 對(duì)項(xiàng)目的負(fù)面影響。在這種情況下，就像缺陷密度是程序設(shè)計(jì)效率的追溯的量度一樣，程序設(shè)計(jì)人員可能直觀地將容積應(yīng)用于軟件設(shè)計(jì)的效率的追溯的量度。當(dāng)程序設(shè)計(jì)人員看到時(shí)，容積的快速，未預(yù)期的增長(zhǎng)是糟糕設(shè)計(jì)的暗示。它們揭示了一米寬一寸深的，不鼓勵(lì)可測(cè)性或可維護(hù)性，以及一般會(huì)破壞設(shè)計(jì)雅致的技術(shù)棧。

    容積的典型量度包括 LOC、SLOC、ELOC、語(yǔ)句、分號(hào)、方法數(shù)、類(lèi)數(shù)和文件數(shù)。行業(yè)一般支持一種或另一種 LOC 作為大小的指示，如根據(jù)每 LOC 的缺陷計(jì)算的幾乎不變的缺陷密度所示。

    因?yàn)橐恍┤藢⑷莘e認(rèn)為是引起爭(zhēng)議的量度，有時(shí)候組織陷入爭(zhēng)論，什么容積量度是“最好的”。在一定程度上，如果您根本沒(méi)有度量容積，那么詳述此爭(zhēng)論就沒(méi)有意義。幾乎沒(méi)有什么軟件量度是偉大的，但是許多（像 LOC）是好的，重要的是增強(qiáng)管理的治理能力，以及團(tuán)隊(duì)對(duì)他們工作的重要維度的可見(jiàn)性，KPI 可以并將隨著時(shí)間改進(jìn)。

    通常，推薦在同樣的基礎(chǔ)上評(píng)估易變率和容積。如果您根據(jù) LOC 中的隨時(shí)間變更的總量度量易變率，那么您會(huì)希望也根據(jù) LOC 中隨時(shí)間的凈變更度量容積。

    工作產(chǎn)品 KPI

    有許多可以用于評(píng)估軟件工作產(chǎn)品（不論是組件、子系統(tǒng)、服務(wù)，或應(yīng)用程序）的質(zhì)量和完整性的工具。這些工具的選擇和使用形成了組織治理計(jì)劃的主要部分。

    通常，這些工具向靜態(tài)（源代碼）或動(dòng)態(tài)（運(yùn)行時(shí)）環(huán)境應(yīng)用一組規(guī)則。當(dāng)引入治理計(jì)劃時(shí)，違反規(guī)則的行為一般都確定為對(duì)項(xiàng)目標(biāo)準(zhǔn)的違規(guī)行為。乍一看，這可能聽(tīng)起來(lái)有點(diǎn)苛刻，在缺少對(duì)一線希望的偏移的情況下過(guò)分強(qiáng)調(diào)負(fù)面。但是存在一個(gè)實(shí)際的理由：測(cè)試違規(guī)行為相對(duì)容易，但是不同于缺少違規(guī)行為，測(cè)試遵循要難得多。這個(gè)治理主題有時(shí)候會(huì)引起爭(zhēng)論，含糊地聽(tīng)起來(lái)有哲學(xué)的，像“好的僅僅是缺少邪惡?jiǎn)?？”雖然對(duì)其的回答有一點(diǎn)困難，但是肯定的是工具可以找出確實(shí)邪惡的安全性漏洞、復(fù)雜的代碼，和性能瓶頸。

    當(dāng)引起管理層的注意時(shí)，來(lái)自這些工具的輸出就成為了工作產(chǎn)品 KPI。關(guān)于這些工具的問(wèn)題是，他們是被設(shè)計(jì)用來(lái)由個(gè)別開(kāi)發(fā)人員使用的，還是在運(yùn)行時(shí)環(huán)境中（在該環(huán)境中按照不規(guī)律的頻率執(zhí)行評(píng)估，并且結(jié)果不保留）使用的。為了參與治理計(jì)劃，這通常意味著將工具和一致的框架相集成，進(jìn)行分析和報(bào)告。

    承認(rèn)了廠商，例如 SourceIQ 已經(jīng)跨接了工具和管理報(bào)告之間的間隔，讓我們來(lái)分析可以快速并積極影響開(kāi)發(fā)治理的工作產(chǎn)品 KPI： 編碼規(guī)則、語(yǔ)言規(guī)則，和復(fù)雜性。

    編碼規(guī)則

    組織出于最佳的理由采用編碼規(guī)則。按照公共的規(guī)則開(kāi)發(fā)的代碼在團(tuán)隊(duì)成員之間更易接受和維護(hù)，更容易在大型組織中分享，并且在維護(hù)中更節(jié)約成本，特別是當(dāng)轉(zhuǎn)給不是原始工作一部分的團(tuán)隊(duì)時(shí)。

    不幸的是，經(jīng)常出現(xiàn)的情況是，團(tuán)隊(duì)中的個(gè)人隨著時(shí)間有選擇的應(yīng)用并侵蝕這些規(guī)則。在沒(méi)有工作產(chǎn)品 KPI 的情況下，在管理層無(wú)意識(shí)的情況下，出現(xiàn)了代碼基數(shù)的退化。因此，當(dāng)新的團(tuán)隊(duì)成員艱難地符合速度時(shí)，同行審查難以達(dá)到不可行的程度，或者維護(hù)成本上升，根本原因是對(duì)試圖修正問(wèn)題的管理層不可見(jiàn)。

思想上的重要轉(zhuǎn)變出現(xiàn)于團(tuán)隊(duì)成員看出了他們對(duì)同事的職責(zé)，并且加入了另每個(gè)人的工作更簡(jiǎn)單的編碼規(guī)則。有許多可以用于自定義組織的特殊編碼規(guī)則的工具和腳本。當(dāng)這些工具加入到治理環(huán)境中時(shí)，管理層就能夠在增加的法規(guī)遵循方向上輕推開(kāi)發(fā)組織。在途中，可能有一些挫折，但它是健康的事情，因?yàn)樗梢赃M(jìn)一步改善規(guī)則。累積影響傾向于非常積極，團(tuán)隊(duì)成員能夠共享代碼，在團(tuán)隊(duì)中調(diào)試，并且概括地了解彼此的工作。

    語(yǔ)言規(guī)則

    語(yǔ)言規(guī)則類(lèi)似于編碼規(guī)則，但是一般來(lái)自于開(kāi)發(fā)組織之外，而不是從內(nèi)部。舉例來(lái)說(shuō)，Sun Microsystems 發(fā)布了一組 Java 語(yǔ)言 9 的編碼約定。商業(yè)和開(kāi)源工具可以自動(dòng)地根據(jù)語(yǔ)言廠商的規(guī)則評(píng)估代碼，一般使用令調(diào)整規(guī)則使其滿(mǎn)足開(kāi)發(fā)治理計(jì)劃的需求很容易，的規(guī)則引擎和語(yǔ)法檢查。在某些情況下，語(yǔ)言廠商的規(guī)則相當(dāng)良好，并且可能只影響到代碼的表示或維護(hù)的某個(gè)小方面。然而，在其他情況下，代碼中違反規(guī)則的表現(xiàn)可以是一個(gè)紅色的標(biāo)記，即使編譯器讓其通過(guò)，在運(yùn)行時(shí)也會(huì)嚴(yán)重地出錯(cuò)。

    隨著工具，例如這些工具并入治理計(jì)劃，在今天的行業(yè)中，軟件工具正經(jīng)歷快速的變更和演進(jìn)是毫無(wú)意義的。IBM? 最近收購(gòu)了 Watchfire，強(qiáng)調(diào)了可以查明安全弱點(diǎn)的工具之間的成熟度，并且考慮與開(kāi)發(fā)目標(biāo)和審查需求相關(guān)的這類(lèi)工作產(chǎn)品 KPI 的關(guān)系對(duì)您來(lái)說(shuō)是有意義的。重要的事情是保持行業(yè)趨勢(shì)的優(yōu)勢(shì)，并且消息靈通。

    復(fù)雜性

    上面提到的工作產(chǎn)品評(píng)估一般是性質(zhì)上的，復(fù)雜性分析形成了強(qiáng)大工作產(chǎn)品 KPI 的基礎(chǔ)。甚至超過(guò)編碼規(guī)則，復(fù)雜性分析是在您的系統(tǒng)中確定最有風(fēng)險(xiǎn)的，更容易出錯(cuò)的，最困難且維護(hù)成本最高的代碼的基礎(chǔ)。許多組織沒(méi)有成功地利用這一關(guān)鍵量度，因?yàn)樗徽J(rèn)為是，對(duì)已經(jīng)有負(fù)擔(dān)的開(kāi)發(fā)團(tuán)隊(duì)來(lái)說(shuō)是太花費(fèi)時(shí)間或太困難了。但是隨著源自管理量度的自動(dòng)化系統(tǒng)的到來(lái)，例如 SourceIQ，管理層現(xiàn)在可以將復(fù)雜性作為至關(guān)重要的維度加入到開(kāi)發(fā)治理計(jì)劃中。

    從 IBM Rational ? 工具中獲得 KPI

    組織根據(jù)表示為 KPI 的標(biāo)準(zhǔn)評(píng)估，利用他們的 Rational 基礎(chǔ)架構(gòu)實(shí)現(xiàn)與那些標(biāo)準(zhǔn)相關(guān)的真正的法規(guī)遵循報(bào)告。

這可能類(lèi)似于一點(diǎn)小跳躍，但讓我們拋開(kāi)某個(gè)歷史的包袱。一些人將 Rational 套件視為工具的集合：開(kāi)發(fā)人員使用 IBM Rational ClearCase?，質(zhì)量保證團(tuán)隊(duì)使用 IBM Rational ClearQuest?，等等。但是 Rational 基礎(chǔ)架構(gòu)遠(yuǎn)不止一組工具。它是一組集成工具，包含了關(guān)于關(guān)鍵開(kāi)發(fā)過(guò)程的事實(shí)和事務(wù)的寶藏，并且可以對(duì)于根據(jù)標(biāo)準(zhǔn)的法規(guī)遵循報(bào)告進(jìn)行挖掘和分析。

    Rational 基礎(chǔ)架構(gòu)是獲得有效治理所需的管理 KPI，以及確保前面提到的動(dòng)態(tài)治理三元組仍舊完整，有快速的響應(yīng)，并且跨團(tuán)隊(duì)（不論是本國(guó)的、境外的，或全球分布的）有效，的基礎(chǔ)。有了統(tǒng)一變更管理（Unified Change Management，UCM），該基礎(chǔ)架構(gòu)甚至更強(qiáng)大，而其洞察力甚至更集中。

    Rational 套件的三個(gè)成員提供了您需要的所有基礎(chǔ)：ClearQuest、ClearCase 和 IBM Rational Build Forge?。

ClearQuest 提供關(guān)于評(píng)估過(guò)程 KPI（允許對(duì)開(kāi)發(fā)過(guò)程的端點(diǎn)的治理）所需的增強(qiáng)的請(qǐng)求和缺陷的事實(shí)和事務(wù)的編年存儲(chǔ)庫(kù)：輸入的請(qǐng)求和輸出的審查。很明顯存在 ClearQuest 的替代方案，但是它擁有關(guān)于 UCM 的特別優(yōu)勢(shì)，如下所述。

    ClearCase 是編年的存儲(chǔ)庫(kù)，可以從其中獲得不同時(shí)間的過(guò)程和工作產(chǎn)品的狀態(tài)。有了 UCM，ClearCase 增加了治理價(jià)值，發(fā)現(xiàn)了用于許多外部審計(jì)所需的變更的永不改變的存儲(chǔ)庫(kù)的想法。下一個(gè)部分中將探究該存儲(chǔ)庫(kù)的非凡價(jià)值，讀者當(dāng)然要熟悉關(guān)于 ClearCase 的配置選項(xiàng)，例如 UCM 和多站點(diǎn) 10 。

    ClearQuest 啟用的 UCM 是向開(kāi)發(fā)治理計(jì)劃授權(quán)牽引力的理想配置。不論您的開(kāi)發(fā)方法是 Agile 或是瀑布的，這個(gè)技術(shù)減少了將開(kāi)發(fā)過(guò)程標(biāo)準(zhǔn)化的困難，并且提供通過(guò)變更順序、編碼，和測(cè)試表示變更的事務(wù)的至關(guān)重要的環(huán)境。

雖然 ClearQuest 和 ClearCase 提供了數(shù)據(jù)和環(huán)境，但是 Build Forge 是自動(dòng)地生成法規(guī)遵循報(bào)告的工具。由于許多組織每晚構(gòu)建或連續(xù)的集成，這解決了法規(guī)遵循報(bào)告頻率和周期性的問(wèn)題，并且令管理者更敏感地處理違規(guī)行為的情況。

  多么持久？

    軟件開(kāi)發(fā)行業(yè)在不斷地徹底改造自己，拆用老的思想和方法，并將它們轉(zhuǎn)換為一些新的，不同的，且有希望更好一點(diǎn)的東西。這種流直接影響了可以設(shè)置的標(biāo)準(zhǔn)、可以施加的管理控制，以及可以實(shí)現(xiàn)的治理。

    舉例來(lái)說(shuō)，許多組織熱切地希望從動(dòng)態(tài)語(yǔ)言，例如 Ruby 和 PHP 中獲得好處。但是許多這些同樣的組織不能接受伴隨他們認(rèn)為是“作家，發(fā)布”的開(kāi)發(fā)過(guò)程的風(fēng)險(xiǎn)，該過(guò)程缺少伴隨傳統(tǒng)語(yǔ)言在編譯和連接階段的更結(jié)構(gòu)化的檢查點(diǎn)，以及關(guān)于那些步驟的工具。

    有時(shí)候退回一步，評(píng)估優(yōu)先權(quán)，并詢(xún)問(wèn)問(wèn)題是有幫助的：什么是真正要緊的？在和許多開(kāi)發(fā)組織一起分析了該問(wèn)題之后，SourceIQ 得到了相當(dāng)出乎意料的回答，它與我們?cè)谲浖_(kāi)發(fā)行業(yè)中看到的波動(dòng)相關(guān)。

    在我給出答案之前，讓我們來(lái)看看事物是如何波動(dòng)的。軟件工具相當(dāng)快速地波動(dòng)，廠商每年發(fā)布主要的新更新，有時(shí)候甚至更快。程序設(shè)計(jì)語(yǔ)言波動(dòng)的少一些，每七到十年主要變化一次。形成 KPI 的知識(shí)基礎(chǔ)的軟件量度波動(dòng)的更緩慢，許多回溯到二十到三十年前。

    但是從經(jīng)驗(yàn)出發(fā)，我們已經(jīng)發(fā)現(xiàn)了軟件開(kāi)發(fā)最持久的資產(chǎn)是組織生成的實(shí)際的源代碼本身。一旦創(chuàng)建了，它可能就要經(jīng)受看上去不停的維護(hù)。但是代碼的夕陽(yáng)看來(lái)很少到來(lái)。60 年代做主機(jī) IT 開(kāi)發(fā)的公司仍舊在原始的邏輯上運(yùn)行核心系統(tǒng)。

    需求、軟件設(shè)計(jì)，甚至測(cè)試腳本與代碼比較有相對(duì)短的預(yù)期壽命。雖然重要，但是它們似乎很快就過(guò)時(shí)了，失修或停用，并且報(bào)廢了。但是代碼不僅是耐用的，它甚至可以獲得一再構(gòu)建于系統(tǒng)中的隱匿的質(zhì)量，即使很久以后，它不再被任何東西參考！

    本討論絕不是說(shuō)拿開(kāi)應(yīng)該應(yīng)用于需求定義、設(shè)計(jì)，和測(cè)試的精確和審查等級(jí)。如果有什么的話，來(lái)自這些規(guī)程的工件可能得益于像代碼那樣在長(zhǎng)期過(guò)程中是完整的。

    但是從純實(shí)際的立場(chǎng)出發(fā)，代碼的持久特性強(qiáng)調(diào)了開(kāi)發(fā)治理計(jì)劃的優(yōu)先權(quán)。程序設(shè)計(jì)人員將來(lái)往于項(xiàng)目中。代碼可能轉(zhuǎn)移到不同的大陸上。它運(yùn)行的平臺(tái)將變更。辦公大樓上的公司名稱(chēng)甚至可能變更，但是代碼將以違背信念的方式持久下去。因此，管理層對(duì)項(xiàng)目的代碼基數(shù)、起源和當(dāng)前狀態(tài)，及根據(jù)有意義的 KPI 的核心集合的評(píng)估了解的越多，團(tuán)隊(duì)將在調(diào)整代碼基數(shù)以滿(mǎn)足未來(lái)的需求方面得到更多的授權(quán)。

    我如何開(kāi)始？

    如果您擁有 IBM Rational 基礎(chǔ)架構(gòu)，一個(gè)開(kāi)發(fā)治理的需求，并且您正渴望開(kāi)始一些管理 KPI，那么要做的第一件事情是開(kāi)始詢(xún)問(wèn)一些問(wèn)題。已經(jīng)有什么標(biāo)準(zhǔn)了？缺少什么標(biāo)準(zhǔn)？標(biāo)準(zhǔn)的遵循對(duì)開(kāi)發(fā)組織來(lái)說(shuō)是優(yōu)先的嗎？如果您有外包或境外合伙人，那么您的標(biāo)準(zhǔn)是他們的服務(wù)等級(jí)協(xié)議的一部分嗎？

    如果治理將受到變更管理基礎(chǔ)架構(gòu)的促進(jìn)，并且以變更管理基礎(chǔ)架構(gòu)為基礎(chǔ)，那么您將想要標(biāo)準(zhǔn)使用模型。這些模式適當(dāng)?shù)靥幱诨蚩缭巾?xiàng)目和團(tuán)隊(duì)了嗎？

    另一組問(wèn)題與管理 KPI 的受者相關(guān)。雖然量度沒(méi)什么新的，但是一些人可能需要更新他們對(duì) KPI 的理解，以及那些 KPI 與完成開(kāi)發(fā)治理之間的相關(guān)性。構(gòu)建一致并共享的理解的最佳方法是涉及所有受到開(kāi)發(fā)治理影響的接受者：架構(gòu)師、開(kāi)發(fā)人員、質(zhì)量保證分析人員、發(fā)布工程師，也許甚至有業(yè)務(wù)單位聯(lián)絡(luò)人。當(dāng)人們開(kāi)始討論并彼此問(wèn)問(wèn)題時(shí)，他們開(kāi)始與結(jié)果有利害關(guān)系了，并且取得了成功執(zhí)行治理計(jì)劃的所有權(quán)。

    最后，治理是管理功能，反對(duì)不得不停在某處。誰(shuí)負(fù)責(zé)治理？誰(shuí)是有責(zé)任的？負(fù)責(zé)實(shí)施治理、按標(biāo)準(zhǔn)實(shí)現(xiàn)，并且評(píng)估法規(guī)遵循的人有權(quán)與工作功能的執(zhí)行相適合嗎？

    隨著標(biāo)準(zhǔn)開(kāi)始成型，著重于將要在開(kāi)發(fā)團(tuán)隊(duì)間共振的量度和 KPI 的小的核心集合，提供上級(jí)管理洞察，可以在短期內(nèi)采用并理解。本文介紹了用大部分團(tuán)隊(duì)完成了該工作的一個(gè)集合。您的團(tuán)隊(duì)可能有其自己的復(fù)雜性，或者細(xì)微差異，并且可能需要不同的東西，但“l(fā)ess is more”的指導(dǎo)原則仍舊可用。

    一旦您到達(dá)了最初的標(biāo)準(zhǔn)集，就是時(shí)候計(jì)劃實(shí)現(xiàn)了。除非管理 KPI 對(duì)強(qiáng)制的法規(guī)遵循來(lái)說(shuō)是完整的，否則它們需要一點(diǎn)提升來(lái)幫助它們獲得牽引力。最好的方法是確保 KPI 向管理接受者提供價(jià)值，并且確保很快發(fā)現(xiàn)好處。一旦管理層開(kāi)始使用過(guò)程 KPI 來(lái)通過(guò)過(guò)程和審計(jì)跟蹤回顧來(lái)向前獲得可溯性，并且當(dāng)軟件項(xiàng)目轉(zhuǎn)移到運(yùn)行時(shí)更低的維護(hù)成本，改進(jìn)的健壯性的狀態(tài)時(shí)，結(jié)果就實(shí)現(xiàn)了。

在項(xiàng)目接著項(xiàng)目，或者團(tuán)隊(duì)并團(tuán)隊(duì)的基礎(chǔ)上進(jìn)行實(shí)現(xiàn)。嘗試項(xiàng)目和代碼一致的企業(yè)跨度的計(jì)劃的組織傾向于不超越他們自己的官僚權(quán)力，并且因此在工作中受挫。通過(guò)向先遣團(tuán)隊(duì)授權(quán)來(lái)強(qiáng)調(diào)項(xiàng)目的成功的更精益的方法更可能產(chǎn)生熱情和成功，并且增加了培育開(kāi)發(fā)人員的好處，他們會(huì)將所學(xué)到的有價(jià)值的經(jīng)驗(yàn)傳到下一個(gè)項(xiàng)目中。

    最后，記住利用您的 Rational 基礎(chǔ)架構(gòu)。管理 KPI 通常不出自于開(kāi)發(fā)者 IDE 或者在書(shū)架上接塵土的工具。它們出自于堅(jiān)固的基礎(chǔ)架構(gòu)組件，像 Rational，這些組件安全，可以進(jìn)行外部的詳細(xì)審計(jì)，并且給出一致的答案。

    注釋

1. 要了解更多關(guān)于動(dòng)態(tài)語(yǔ)言的信息，請(qǐng)參見(jiàn) The Rational Edge 的 2007 年 6、7，和 8 月刊中 Gary Pollice 的文章。

2. 參見(jiàn) Scott Ambler 在 Dr. Dobb's Journal 的 11 月刊中的治理專(zhuān)欄，看看關(guān)于 Agile 方法如何為治理提供更大的機(jī)會(huì)的討論。

3. Scott W. Ambler 和 Per Kroll 的“Best practices for lean development governance”出自 2007 年 6、7，和 8 月出版的 The Rational Edge 系列。

4. “Obituary for Ernst Mach”，1916 年 3 月 14 日，Collected Papers of Albert Einstein（CPAE），6:26。

5. 舉例來(lái)說(shuō)：Total Quality Management（TQM），就像由 International Organization for Standardization（ISO）定義的一樣，在制造業(yè)、政府，和服務(wù)行業(yè)中廣泛使用，ISO 16949（Quality Management Systems: Automotive）。

6. Carnegie Mellon、Capability Maturity Model、CMM，和 CMMI 是由卡內(nèi)基梅隆大學(xué)在 U.S. Patent and Trademark Office 注冊(cè)的。在本文中，對(duì)于 CMM 的參考一般理解為為開(kāi)發(fā)應(yīng)用 CMMI，版本 1.2，由卡內(nèi)基梅隆的 Software Engineering Institute 于 2006 年 8 月公布。

7. CMMI 用于能力等級(jí)特征的環(huán)境中。也許值得注意的是，作者同意其他人（Hillel Glazer、Mike Konrad、James Over），Agile 和 CMMI 不是對(duì)立的方法。

8. 要采用 Gary Pollice （“Does Process Matter?” The Rational Edge，2006 年 8 月）的工作，本討論的重點(diǎn)更傾向于企業(yè)過(guò)程而不是團(tuán)隊(duì)過(guò)程，但適用于他介紹的微過(guò)程下的該光譜。

9. http://java.sun.com/docs/codeconv/

10. Software Configuration Management Strategies and IBM Rational ClearCase: A Practical Introduction（2nd Edition），作者 David E. Bellagio 和 Tom J. Milligan，是用于標(biāo)準(zhǔn)化 ClearCase 的使用并獲得開(kāi)發(fā)治理中最大利益的，用于了解和構(gòu)建的有價(jià)值的指導(dǎo)。(csai)