高級軟件工程

SoftwareEngineering軟件研發(fā)效能度量為什么關(guān)注研發(fā)效能在數(shù)字化的時代，研發(fā)效能已經(jīng)成為一家科技公司的核心競爭力在軟件研發(fā)領(lǐng)域，能夠有助于效能提升的方法論和實(shí)踐一直在快速發(fā)展比如，敏捷開發(fā)方法已經(jīng)誕生了二十年，DevOps也已經(jīng)發(fā)展了十多年。但是，我們經(jīng)常遇到的一種現(xiàn)象是，當(dāng)一個組織或者團(tuán)隊(duì)在消耗了大量的“變革”時間、花費(fèi)了大量的人力資源和成本后，卻無法有效回答一些看似非?；镜膯栴}：我們的研發(fā)效能到底怎么樣？可否量化？比所在行業(yè)平均水平、比別的公司、比別的團(tuán)隊(duì)更好還是更差？研發(fā)效能的瓶頸點(diǎn)和問題是什么？在采納了敏捷或DevOps實(shí)踐之后，有沒有效果？有沒有實(shí)質(zhì)上的提升？下一步應(yīng)該采取什么樣的行動以繼續(xù)優(yōu)化效能？996Vs955,哪個更能產(chǎn)生效能？……2研發(fā)效能度量軟件工程數(shù)字化，將大數(shù)據(jù)技術(shù)用于軟件研發(fā)中。軟件企業(yè)的數(shù)字化轉(zhuǎn)型讓效能可量化、可分析、可提升，通過數(shù)據(jù)驅(qū)動的方式更加理性地評估和改善效能。3研發(fā)效能度量的挑戰(zhàn)軟件研發(fā)過程中的可視性差軟件研發(fā)過程中工作切分的隨意性敏捷研發(fā)過程中工作是并行開展的402-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標(biāo)504-研發(fā)效能度量的反模式和原則“沒有度量就沒有改進(jìn)”--PeterDrucker“沒有度量就沒有控制”--TomDemarco6軟件度量的價值認(rèn)知：認(rèn)知和理解過程、產(chǎn)品、資源和環(huán)境，建立比較基線；評估：比較同步跟蹤軟件項(xiàng)目的狀態(tài)，管理進(jìn)展；及時發(fā)現(xiàn)實(shí)施和計(jì)劃的偏差，評估質(zhì)量目標(biāo)的達(dá)成情況，以及技術(shù)和過程的改進(jìn)對產(chǎn)品和過程的影響；預(yù)測：是建立在適當(dāng)資源下，達(dá)到成本、進(jìn)度和質(zhì)量目標(biāo)的計(jì)劃的基礎(chǔ)。也可根據(jù)度量的實(shí)證，預(yù)測項(xiàng)目發(fā)展的傾向，估計(jì)分析風(fēng)險，做出設(shè)計(jì)／成本權(quán)衡；改進(jìn)：幫助識別問題根源，判斷可以改進(jìn)的機(jī)會，交流改進(jìn)的目標(biāo)和理由等;調(diào)整資源分配等。7更好地管理軟件開發(fā)與運(yùn)維度量的定義度量關(guān)注的是在一定規(guī)則下獲取關(guān)于實(shí)體屬性的信息一個實(shí)體可以是一個實(shí)物，如軟件產(chǎn)品；或者是一個事件，如軟件測試；屬性是我們所關(guān)注的實(shí)體的特征或特性．8度量的分類主觀/客觀objective/subjective絕對/相對absolute/relative動態(tài)/靜態(tài)dynamic/static預(yù)測/解釋predictive/explanatory過程/產(chǎn)品/項(xiàng)目/資源process/product/project/resource9按度量對象分產(chǎn)品度量，是以某種方式實(shí)現(xiàn)軟件過程中所指定的產(chǎn)品指標(biāo)的合理量化，從而衡量軟件工作產(chǎn)品的規(guī)模、質(zhì)量和復(fù)雜度等屬性，如代碼行數(shù)、McCabe圈復(fù)雜度、模塊的耦合度、測試覆蓋率、用戶平均響應(yīng)時間等。過程度量，是以某種方式實(shí)現(xiàn)所指定的過程能力指標(biāo)的合理量化，從而衡量組織級別上軟件過程的質(zhì)量、成本、盈利、投資回報(bào)率和生產(chǎn)率等屬性，如需求變更率、缺陷的修復(fù)成本占總開發(fā)成本的比率、生產(chǎn)率等。項(xiàng)目度量，是以某種方式實(shí)現(xiàn)軟件項(xiàng)目指標(biāo)的合理量化，從而衡量項(xiàng)目的質(zhì)量、成本、盈利、生產(chǎn)率和進(jìn)度等屬性，如項(xiàng)目質(zhì)量目標(biāo)的達(dá)成率、人均開發(fā)效率等。資源度量，是以某種方式實(shí)現(xiàn)資源指標(biāo)的合理量化，從而衡量資源的利用、勝任力、分布合理性等屬性，如程序員的能力、工具的使用效率、庫存周轉(zhuǎn)率等。10研發(fā)效能是綜合性度量度量模型：GQM11GQM（Goal-Question-Metric）模型是基于這樣的假設(shè)：對一個機(jī)構(gòu)而言，度量是應(yīng)當(dāng)有目的性的，即它應(yīng)首先定義其自身或該機(jī)構(gòu)內(nèi)某個項(xiàng)目的目標(biāo)，根據(jù)這些目標(biāo)去跟蹤那些定義這些目標(biāo)的數(shù)據(jù)，最后提供一個框架用于解釋這些數(shù)據(jù)與所確定的目標(biāo)之間的關(guān)系。GQM度量模型第一層：概念層（目標(biāo)G）。包含一個目標(biāo)、目標(biāo)涉及的度量對象及其屬性等信息。目標(biāo)所涉及的對象類型有：產(chǎn)品（Product）：軟件生存期中產(chǎn)生、發(fā)布的各種軟件產(chǎn)品、文檔等；過程（Process）：與軟件生產(chǎn)相關(guān)的各種活動；資源（Resourse）：被過程所利用，以便產(chǎn)生其輸出產(chǎn)品的所有對象，如人、硬件、軟件、辦公空間等。第二層：運(yùn)作層（問題Q）。問題是有上一層的目標(biāo)細(xì)化而來，用于描述實(shí)現(xiàn)該目標(biāo)的方式。一個目標(biāo)能細(xì)化出多個問題。第三層：量化層（度量M）。一組以量化的方式回答上層問題的數(shù)據(jù)。這組數(shù)據(jù)可以是：客觀的：若該組數(shù)據(jù)全部是通過對對象的測量獲得的，而不是以什么人的主觀認(rèn)識取得的；主觀的：若該組數(shù)據(jù)是通過實(shí)測和人們的主觀判斷獲得的。舉例目標(biāo)：分析開發(fā)過程中的軟件錯誤，以便找出降低成本的可能點(diǎn)問題：Q1：在哪些地方出現(xiàn)了錯誤？Q2：這些錯誤的來源在哪里？Q3：發(fā)現(xiàn)的錯誤是否得到更改？Q4：從發(fā)現(xiàn)錯誤、確認(rèn)錯誤、到更改錯誤所需要的時間？Q5：從過程改進(jìn)小組的角度看，目前的糾錯、改錯過程是否合理？度量：(Q5得到的度量)M51（錯誤延遲）=M52（糾錯人工）=1302-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標(biāo)1404-研發(fā)效能度量的反模式和原則軟件度量過程15步驟1確立和維持度量承諾接受度量需求度量的范圍定義為組織單元，可以是單一項(xiàng)目、功能領(lǐng)域、整個企業(yè)、單一場所或多場所的組織。由組織單元確定對度量過程的資源承諾以及維護(hù)這種承諾的意愿。分配資源度量發(fā)起者把度量職責(zé)分配給有能力勝任的人，勝任力為度量原理，以及數(shù)據(jù)收集、數(shù)據(jù)分析和信息通報(bào)等知識。所涉及的角色至少包括度量用戶和度量分析員。度量發(fā)起者應(yīng)確保資金和人員等資源供給。16步驟2準(zhǔn)備度量定義度量策略描述度量組織的特性確定度量的信息需求，例如“如何評價設(shè)計(jì)過程中的軟件產(chǎn)品質(zhì)量？”從業(yè)務(wù)目標(biāo)出發(fā)，根據(jù)已確定的信息需求，按GQM確定度量指標(biāo)定義數(shù)據(jù)收集、分析和報(bào)告規(guī)程明確度量評價的準(zhǔn)則識別和策劃度量工具評審和批準(zhǔn)度量計(jì)劃獲取并部署支持技術(shù)，包括度量工具和培訓(xùn)課程等17Metric示例18建議：從研發(fā)工具中自動收集數(shù)據(jù)從項(xiàng)目管理工具、需求管理工具、版本管理工具、IDE和代碼、評審工具、測試工具、持續(xù)集成工具、運(yùn)維工具等自動收集數(shù)據(jù)采用埋點(diǎn)方式收集數(shù)據(jù)從database/file,trace,log等收集數(shù)據(jù)19數(shù)據(jù)集成，構(gòu)建軟件工程關(guān)聯(lián)數(shù)據(jù)（linkeddata）20步驟3實(shí)施度量把數(shù)據(jù)的產(chǎn)生、收集、分析與報(bào)告過程與相關(guān)的軟件過程進(jìn)行集成收集、存儲和驗(yàn)證數(shù)據(jù)分析數(shù)據(jù)，得到度量結(jié)果記錄并通報(bào)度量結(jié)果21分析技術(shù)22可視化展示23步驟4評價度量評價度量信息和度量過程通過審核，對度量信息（例如度量指標(biāo)、數(shù)據(jù)、規(guī)程、方法和工具等）和度量過程進(jìn)行評價，識別它們的弱項(xiàng)和強(qiáng)項(xiàng)。把通過評價得到的經(jīng)驗(yàn)教訓(xùn)存入度量經(jīng)驗(yàn)庫。識別潛在的改進(jìn)契機(jī)例如軟件規(guī)模度量指標(biāo)從代碼行變?yōu)楣δ茳c(diǎn)，重新分類軟件缺陷等。24建立組織級研發(fā)效能度量體系2502-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標(biāo)2604-研發(fā)效能度量的反模式和原則3+1度量指標(biāo)體系27研發(fā)效能度量指標(biāo)集28阿里巴巴的效能度量指標(biāo)29阿里巴巴的“2-1-1”愿景目標(biāo)30螞蟻集團(tuán)的效能度量31Facebook的效能度量32DevOps全球調(diào)查報(bào)告中的度量指標(biāo)StateofDevOpsReport討論：設(shè)計(jì)軟件度量指標(biāo)項(xiàng)目組A在最終的系統(tǒng)測試時發(fā)現(xiàn)了384個bug,項(xiàng)目組B則發(fā)現(xiàn)了184個。要決定哪個項(xiàng)目組發(fā)現(xiàn)bug更有效，應(yīng)采用哪些度量？

代碼評審是軟件質(zhì)量管理的最佳實(shí)踐，現(xiàn)需要設(shè)計(jì)代碼評審的度量指標(biāo)，度量目標(biāo)為：推進(jìn)代碼評審的實(shí)踐，從而提升軟件的質(zhì)量代碼評審時，評審者每分鐘罵臟話的次數(shù)？34代碼評審的度量指標(biāo)3502-軟件度量過程01-軟件度量和GQM模型03-研發(fā)效能度量指標(biāo)3604-研發(fā)效能度量的反模式和原則古德哈特定律

當(dāng)某個度量變成了目標(biāo)，它便不再是一個好的度量。37“千行代碼缺陷率”引發(fā)的“血”案從千行代碼缺陷率來看工程師A屬于正常水平，無功也無過。工程師B會因此受到表揚(yáng)？不一定！他很有可能會被判定為沒有進(jìn)行充分的測試，被責(zé)令加強(qiáng)測試。工程師C必然會遭受批評，被責(zé)令改進(jìn)代碼質(zhì)量?；谇写a缺陷率對這三個工程師的評價顯然是有失公允的。38需求變更后…軟件需求發(fā)生了變化……工程師B和工程師C的代碼具有較好的可維護(hù)性，可以方便地變更，所以很快完成變更任務(wù)，只引入了少量的新缺陷。工程師A的代碼由于缺乏設(shè)計(jì)模式的支持，大量代碼需要重寫，同時還會引入了很多新缺陷。度量結(jié)果：由于代碼量夠大，工程師A的千行代碼缺陷率依舊在平均范圍內(nèi)，所以依然無功也無過工程師B和工程師C則繼續(xù)得到差評，因?yàn)樗麄兊墓ぷ骺雌饋硖唵瘟耍黠@工作量“不飽滿”。39結(jié)論千行代碼缺陷率的度量體系是失敗的，其所傳達(dá)的價值觀與我們所期望的背道而馳從工程師B的遭遇可以看出“我們不相信你能夠?qū)懗龈哔|(zhì)量的代碼”從工程師C的遭遇可以看出“我們不鼓勵技術(shù)提升階段的陣痛”從工程師A那邊看到的是“我們歡迎那些平庸的程序員”40陷入“算法對抗”的窘境程序員：稀釋代碼采取稀釋代碼的方式來降低千行代碼缺陷率，而不是實(shí)際去減少缺陷數(shù)量。因?yàn)榕c減少缺陷數(shù)量相比，直接稀釋代碼（比如：一行寫成多行、括弧必須換行、多寫注釋、多加空行等）的難度更低，而且更可控。度量員：改進(jìn)度量算法，用基于AST的開發(fā)當(dāng)量代替代碼行數(shù)程序員：通過人為增加開發(fā)當(dāng)量（比如減少封裝等）來降低代碼缺陷率度量員：再次改進(jìn)度量算法……41正確的做法是什么呢？研發(fā)效能度量的反模式把度量和KPI進(jìn)行綁定片面性的度量數(shù)據(jù)采集依賴于人工錄入在沒有任何明確改進(jìn)目