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

申請免費(fèi)試用、咨詢電話：400-8352-114

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

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

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

    治理不僅僅是管理

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

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

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

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

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

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

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

    治理三元組

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

圖 1：治理三元組

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    過程 KPI

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

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

    易變率 KPI

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

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

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

    容積 KPI

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

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

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

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

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

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

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

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

    工作產(chǎn)品 KPI

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

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

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

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

    編碼規(guī)則

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

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

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

    語言規(guī)則

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

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

    復(fù)雜性

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

    從 IBM Rational ? 工具中獲得 KPI

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

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

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

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

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

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

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

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

  多么持久？

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

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

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

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

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

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

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

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

    我如何開始？

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

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

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

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

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

    一旦您到達(dá)了最初的標(biāo)準(zhǔn)集，就是時候計(jì)劃實(shí)現(xiàn)了。除非管理 KPI 對強(qiáng)制的法規(guī)遵循來說是完整的，否則它們需要一點(diǎn)提升來幫助它們獲得牽引力。最好的方法是確保 KPI 向管理接受者提供價(jià)值，并且確保很快發(fā)現(xiàn)好處。一旦管理層開始使用過程 KPI 來通過過程和審計(jì)跟蹤回顧來向前獲得可溯性，并且當(dāng)軟件項(xiàng)目轉(zhuǎn)移到運(yùn)行時更低的維護(hù)成本，改進(jìn)的健壯性的狀態(tài)時，結(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)力，并且因此在工作中受挫。通過向先遣團(tuán)隊(duì)授權(quán)來強(qiáng)調(diào)項(xiàng)目的成功的更精益的方法更可能產(chǎn)生熱情和成功，并且增加了培育開發(fā)人員的好處，他們會將所學(xué)到的有價(jià)值的經(jīng)驗(yàn)傳到下一個項(xiàng)目中。

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

    注釋

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

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

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. 舉例來說：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 注冊的。在本文中，對于 CMM 的參考一般理解為為開發(fā)應(yīng)用 CMMI，版本 1.2，由卡內(nèi)基梅隆的 Software Engineering Institute 于 2006 年 8 月公布。

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

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

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 的使用并獲得開發(fā)治理中最大利益的，用于了解和構(gòu)建的有價(jià)值的指導(dǎo)。(csai)