最近與某互聯(lián)網(wǎng)公司架構(gòu)師討論了研發(fā)效能中的問題，整理分享如下。
有許多評估團(tuán)隊產(chǎn)出的辦法，比如代碼行、功能點、故事點和故事卡數(shù)量，這種度量方式不僅存在偏差，而且是一種非常局部的度量方式，現(xiàn)在都已不再適用。更有許多研發(fā)團(tuán)隊存在著這種情況，開發(fā)編碼的效率很高，測試和部署工作量大，成為瓶頸，或者需求澄清和排程的時間長，壓縮了開發(fā)時間，無法詳細(xì)地設(shè)計和驗證，質(zhì)量下滑拖累了效率。從而導(dǎo)致最后效能問題“每天工作投入度和響應(yīng)上，自己感知已經(jīng)夠快了，業(yè)務(wù)還說我們慢，原因在哪里我也說不清楚”。
這里的關(guān)鍵點在于，效能為誰度量，即以誰的視角來看待效能？由于研發(fā)最終的目標(biāo)是交付到業(yè)務(wù)，那效能最終面對的還是業(yè)務(wù)視角。
很多時候業(yè)務(wù)感知的“慢”，在于需求的端到端交付周期過長，也在于過程的信息不透明?！耙粋€小需求，也要那么久才能上線！”而開發(fā)感知到的是，需求的評估、排程和跨組/團(tuán)隊協(xié)同過程太耗時了，是因為在這個過程中等待太久，才導(dǎo)致周期拉得很長。
一個需求從提出到發(fā)布，通常會經(jīng)過分析、澄清、計劃、設(shè)計、開發(fā)、測試、部署到正式發(fā)布幾個階段。
那么在各個環(huán)節(jié)中，究竟多長時間是合適的呢？精益思想給出了一個度量方法，就是最小積壓，理想狀態(tài)下是做到零庫存，即沒有需求積壓。如果業(yè)務(wù)持續(xù)不斷地接收到產(chǎn)出物，同時看到新需求不斷進(jìn)入處理過程，就很難感知到“很慢”了。
舉個例子，同樣是等，在星巴克你能看到你的杯子正在什么位置，咖啡師正在準(zhǔn)備什么；外賣下單后，你能看到騎手的位置和狀態(tài)，就能緩解等待的焦慮。而在研發(fā)過程中，因為信息不透明帶來的需要同步的“會議”實在是太多了。
近些年我們推崇的是使用時間來度量效能，并且在數(shù)個咨詢項目上通過這種度量方式驅(qū)動，成功地幫助團(tuán)隊找到了改進(jìn)點，優(yōu)化了整體的交付周期。
三個關(guān)鍵的時間度量指標(biāo)是：
Lead Time（前置時間）：業(yè)務(wù)感知效能的重要指示燈，是指從業(yè)務(wù)提出需求到最終需求發(fā)布到業(yè)務(wù)的時間間隔（自然日）。如需求于9月1日提出，9月30日發(fā)布，那Lead Time就為29天。又被稱為需求端到端交付周期。
Cycle Time（周期時間）：研發(fā)內(nèi)部效能的重要指示燈，是指開發(fā)團(tuán)隊接受需求到交付業(yè)務(wù)驗收的時間間隔（自然日），覆蓋了分析、設(shè)計、編碼、測試及修復(fù)缺陷的時間。通常也稱之為交付周期。
Takt Time（節(jié)拍時間）：研發(fā)節(jié)奏制定的重要參考值，是指開發(fā)團(tuán)隊在周期時間內(nèi)完成需求的平均時間。比如周期時間為29天，共產(chǎn)出10個需求，節(jié)拍時間就為2.9天。精益的理想狀態(tài)是單件流，即最小的批量不間斷流轉(zhuǎn)，節(jié)拍時間就是縮小批量大小，邁向不間斷流轉(zhuǎn)的重要依據(jù)。
度量了這幾個時間，那又如何來說明效能呢？
前面提到精益給出的度量標(biāo)準(zhǔn)，即最小積壓。在交付的各個環(huán)節(jié)中等待的任務(wù)，都是積壓，即是浪費。對研發(fā)中的浪費，我們設(shè)定在計劃啟動之后進(jìn)行統(tǒng)計，并分類原因：
根據(jù)大量的咨詢經(jīng)驗，許多效能問題，只需要消除浪費就能夠顯著地提升，這個提升比率最低在40%，最高在89%；一些跨團(tuán)隊協(xié)作的痛點，僅僅通過統(tǒng)一拆分任務(wù)和計劃方式，就將協(xié)同任務(wù)的節(jié)拍時間下降了40%之多。
推行敏捷最重要的就是帶給大家一種全新的工作方式：從一種自上而下領(lǐng)導(dǎo)式的計劃和管理，變成自下而上的團(tuán)隊合作達(dá)成目標(biāo)。為達(dá)成這個轉(zhuǎn)變，團(tuán)隊需要掌握幾項技能：
設(shè)定目標(biāo)：從業(yè)務(wù)和用戶的視角理解需求，了解業(yè)務(wù)價值、使用者和痛點，而不僅僅是功能說明清單。
需求分解：”需求跨不跨迭代“、”需求分幾個迭代開發(fā)完成“，也是迭代式開發(fā)中的一個常見問題。正確答案是：在敏捷開發(fā)里，無論選擇哪類需求載體，特性、用戶故事還是任務(wù)，都不應(yīng)該在計劃階段設(shè)定為跨迭代交付，除非迭代目標(biāo)沒達(dá)成，在評審會議上轉(zhuǎn)入下一個迭代。沒有正確的需求分解方法，是排不出正確的迭代計劃的。
任務(wù)估算：ESTIMATE翻譯為估算一直以來都被視為一種對交付時間的承諾，所以讓開發(fā)團(tuán)隊感覺很難操作。如果用中文更準(zhǔn)確的表達(dá)應(yīng)為“評估”，估算技術(shù)，是一種從時間上量化交付周期和風(fēng)險的手段。比如采用斐波那契數(shù)列進(jìn)行估算，就能夠很好地為不確定的風(fēng)險添加緩沖時間。
迭代/看板計劃：許多團(tuán)隊僅僅是劃分了一個更小的周期，就把它當(dāng)作迭代。甚至還有團(tuán)隊劃分出來的是開發(fā)人員的一個容量包，比如兩周的工作量，排進(jìn)一個迭代，迭代N的交付物，是測試團(tuán)隊在迭代N+1的測試版本，然后在N+1迭代中又?jǐn)D進(jìn)一些不可預(yù)測的缺陷修復(fù)工作量，最后在N+2/3迭代中發(fā)布迭代N的需求。這也是許多開發(fā)團(tuán)隊自稱已做到“兩周一迭代”而業(yè)務(wù)覺得沒啥變化的原因：真實的”需求迭代“應(yīng)該在六到八周左右，差不多一個半月到兩個月?？窗逵质橇硪环N工作計劃方式，需要比迭代更細(xì)致的優(yōu)先級排序，形成任務(wù)隊列。在看板上，團(tuán)隊自頂向下拉動任務(wù)卡至交付泳道。
規(guī)矩千萬條，最后都落墻角。工作方式大家都口頭接受了，但一執(zhí)行又全跑歪，又該怎么辦呢？
討論中架構(gòu)師談到，不止研發(fā)效能，還包括架構(gòu)和代碼質(zhì)量，都已經(jīng)制定了嚴(yán)格的標(biāo)準(zhǔn)，團(tuán)隊也接受了，但就是很難執(zhí)行，現(xiàn)在針對一個200人級別的大型重構(gòu)項目，不得不組建近30人的治理團(tuán)隊，負(fù)責(zé)評審代碼和接口，以避免架構(gòu)質(zhì)量走偏。
我認(rèn)為，這是一種治標(biāo)不治本的方式。結(jié)果有偏差，問題的根源在哪里？代碼已經(jīng)不合格了，評審、退回、重做和返工都是浪費。效能的改進(jìn)是致力于消除這種浪費，而許多技術(shù)型管理者關(guān)注和控制的落腳點在最終結(jié)果，而不是原因。有沒有親自到現(xiàn)場走查一下，這些不合格的代碼、接口是怎么寫出來的呢？
許多規(guī)范只是原則，而開發(fā)人員執(zhí)行的是操作。比如說一個接口的設(shè)計規(guī)范明明要求：滿足向前兼容。但開發(fā)出來的新版本卻把舊的功能破壞了。開發(fā)人員很可能并不知道什么叫“向前兼容”，這些原則對并不了解它們的人來說，根本不具備指導(dǎo)意義。如果改成：
禁止修改不熟悉的代碼，如要修改，請和代碼編寫者或技術(shù)負(fù)責(zé)人溝通，并編寫對應(yīng)的單元測試，以避免破壞系統(tǒng)功能。
禁止修改已發(fā)布的接口實現(xiàn)代碼，應(yīng)該使用擴(kuò)展的方式添加新的代碼功能。
如果要停用某個接口，必須添加注解。示例：@Deprecated
這類問題就可以避免了。
許多開發(fā)人員并沒有養(yǎng)成高效的工作習(xí)慣。每天第一時間處理什么任務(wù)？接到任務(wù)后第一時間處理什么？下班之前哪些事項必須收尾？每個人在動手開動這一切時，指導(dǎo)他的，是他過去的經(jīng)驗、習(xí)慣和思維方式，而不是在某個會議上突然聽到的聲音。把具體的工作步驟成文，并輔導(dǎo)團(tuán)隊逐步形成習(xí)慣，結(jié)合績效對過程標(biāo)準(zhǔn)的考核，才能杜絕頻繁返工、銜接不暢的浪費。每個10人左右的小團(tuán)隊內(nèi)，一定要有人單對單的輔導(dǎo)，這就是公司作為一個有效的組織，而非一群人的關(guān)鍵原因。許多技術(shù)人員的關(guān)注點在于系統(tǒng)，而未關(guān)注到系統(tǒng)開發(fā)的過程，而這個過程中，最本質(zhì)的就是人的行為，造成了研發(fā)效能的根本影響。
場量科技是一家專注于產(chǎn)品創(chuàng)新與效能優(yōu)化的平臺服務(wù)商，我們基于十余年的知名企業(yè)咨詢經(jīng)驗，圍繞產(chǎn)品創(chuàng)新提供工具與數(shù)據(jù)交易平臺，并幫助企業(yè)優(yōu)化產(chǎn)品研發(fā)效能。
