AI落地研發(fā)的“最后一公里”暨《DevData24研發(fā)效能基準報告》數(shù)據(jù)解讀

《DevData

'24

研發(fā)效能基準報告》核心數(shù)據(jù)解讀思碼逸研發(fā)效能發(fā)效能能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼思碼逸清華大學計算機系博士；前微軟亞洲研究院研究員，斯坦福大學、卡內(nèi)基梅隆大學訪問學者《軟件研發(fā)效能度量規(guī)范》標準核心起草專家多篇論文發(fā)表在

FSE、OSDI

等頂級國際會議上曾參與微軟下一代服務器系統(tǒng)架構設計，獲

4

項美國發(fā)明專利Apache

DevLake

開源項目發(fā)起人任晶磊公思碼司逸職創(chuàng)位始人兼CEO思碼逸研發(fā)效能G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站發(fā)效能能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼逸研發(fā)效能思碼思碼逸企業(yè)研發(fā)應用

AI，效能提升了嗎？（采納率）應用

AI

工具對企業(yè)研發(fā)效能的影響數(shù)據(jù)來源：《DevData

2024

研發(fā)效能基準調研報告》效率方面：

18%應用

AI

工具比未應用的企業(yè)需求交付周期更快質量方面：

23%應用

AI

工具比未應用的企業(yè)單元測試覆蓋度更高G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站AI

落地企業(yè)研發(fā)的路徑與終點AI

落地企業(yè)研發(fā)需要“以終為始”，做填空題：使用

DevChat后，規(guī)范提交比例從

%提高到了

%，從而看清楚了需求、缺陷和重構工作的占比，優(yōu)化了資源分配

據(jù)此保證了

%研發(fā)帶寬用于支持業(yè)務需求，將需求吞吐率從每月交付

個提升到

使用

DevChat后，單元測試覆蓋度從

%提高到了

%，改進了質量薄弱環(huán)節(jié)，降低了質量保障成本

據(jù)此將缺陷密度從

‰降低到

‰，發(fā)版事故數(shù)從

個減少到

G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告指標涵蓋了《軟件研發(fā)效能度量規(guī)范》的三個主要認知域：

交付速率、交付質量和交付能力。三大認知域統(tǒng)計分析代碼生產(chǎn)率、代碼貢獻均衡度、需求吞吐量、需求交付周期、重點問題密度、缺陷修復工作量等指標基準線（或表征）15個指標基準線首次采用客觀數(shù)據(jù)結合主觀問卷方式

?？陀^數(shù)據(jù)來自受訪企業(yè)私有部署的思碼逸DevInsight，采集Git、Jira等數(shù)據(jù)。170份有效樣本G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告代碼當量*：基于程序分析算法，衡量代碼規(guī)模和復雜度的基礎指標使用代碼當量作為可靠數(shù)據(jù)校準其他研效數(shù)據(jù)質量*

Jinglei

Ren,

Hezheng

Yin,

et

al.

Towards

quantifying

the

developmentvalue

of

code

contributions.

FSE

2018.G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站認知域指標（單位）平均值IQR交付速率需求吞吐量（個/月）20人以下386–

2421-50人4612–

5450人以上6621–

50需求交付周期（天）219–

30需求顆粒度（代碼當量）49361–

645代碼生產(chǎn)率（代碼當量/人月）35952199–

5003開發(fā)過程穩(wěn)定性（代碼生產(chǎn)率離散系數(shù)）0.340.25–

0.40代碼貢獻均衡度（%）29%23%–

35%交付質量單元測試覆蓋度（%）15.27%6.61%–

20.08%注釋覆蓋度（%）30.70%22.36%–

32.98%代碼不重復度（%）84.97%79.26%–

91.46%重點問題密度（個/千當量）1.710.54–

2.21缺陷修復工作量（代碼當量）367–

47DevData

'24

研發(fā)效能基準報告G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站「高效能團隊」評分量表，取等權重綜合得分前20%認知域指標（單位）評分3分 2分 1分交付速率需求交付周期（天）≤

Q1Q1

-Q3≥

Q3代碼生產(chǎn)率（代碼當量/人月）≥

Q3Q1

-Q3≤

Q1開發(fā)穩(wěn)定性（代碼生產(chǎn)率離散系數(shù)）≤

Q1Q1

-Q3≥

Q3代碼貢獻均衡度（%）≥

Q3Q1

-Q3≤

Q1交付質量單元測試覆蓋度（%）≥

Q3Q1

-Q3≤

Q1注釋覆蓋度（%）≥

Q3Q1

-Q3≤

Q1代碼不重復度（%）≥

Q3Q1

-Q3≤

Q1重點問題密度（個/千當量）≤

Q1Q1

-Q3≥

Q3缺陷修復工作量（代碼當量）≤

Q1Q1

-Q3≥

Q3交付能力部署頻率按需每天多次部署介于每周1次到每月1次介于每月1次到每6個月1次變更前置時間介于1天到1周之間介于1周到1個月介于1個月到6個月之間服務恢復時間不到1天介于1天到1周介于1周到1個月變更失敗率0%-15%16%-30%46%-60%DevData

'24

研發(fā)效能基準報告「高效能團隊」

中位值水平畫像每

14

天交付一個需求代碼生產(chǎn)率

3463

當量/人月代碼生產(chǎn)率離散系數(shù)

0.2535%的團隊成員貢獻

80%的代碼當量單元測試覆蓋度

20%注釋覆蓋度

33%代碼不重復度

91%重點問題密度

0.54

個/千當量修復一個缺陷耗費

15當量可提供每天多次按需部署變更前置時間在

1

天～1

周之間服務恢復時間不到

1

天變更失敗率小于

15%交付速率交付質量交付能力G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告敏捷開發(fā)模式下的代碼生產(chǎn)率更高，相比其他模式高

9%20

人以下團隊的代碼生產(chǎn)率相比

50

人以上團隊高

46%單元測試覆蓋度中位值僅為

15%，“測試左移”仍有較大空間引入外包的研發(fā)團隊代碼生產(chǎn)率高

12%，但重點問題密度高

25%應用度量指標管理研效的企業(yè)相比未應用企業(yè)的代碼生產(chǎn)率高

5%G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告運營培訓、結合私有信息、適配實際場景是

AI

落地企業(yè)研發(fā)的三大挑戰(zhàn)G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站DevData

'24

研發(fā)效能基準報告流程規(guī)范、團隊協(xié)作和度量體系是企業(yè)研發(fā)效能提升面臨的三大挑戰(zhàn)G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站度量案例：助力提升DevOps成熟度數(shù)據(jù)分散，收集困難原始數(shù)據(jù)比較散亂，沒有統(tǒng)一的度量模型和方法痛點歸納需求背景：金融企業(yè)，研發(fā)團隊規(guī)模超300人。數(shù)據(jù)分散，治理困難，指標體系不完善。集團對信息化建設提出要求，以推動整體效能提升，其中完成信通院DevOps成熟度評級成為關鍵考核標準。通過

DevOps持續(xù)交付標準3

級評估，相關能力達到國內(nèi)領先水平實踐效果指標和評價體系不完善解決方案借助思碼逸系統(tǒng)集成能力，01

01

陸續(xù)將DevOps工具集成到系統(tǒng)中，完成數(shù)據(jù)自動同步建設企業(yè)領域數(shù)據(jù)寬表，對數(shù)02 02 據(jù)進行清洗整理，借助DORA指標建立評估模型從思碼逸指標體系中選取質量03

03

類評價指標，補充完善已有指標庫G

O

P

S

全球運維大會暨

X

O

p

s

技術創(chuàng)新峰會

2

0

2

4

·

北京站度量案例：助力提升DevOps成熟度G