全棧必備 敏捷估點
老板常問：“產(chǎn)品什么時候可以上線呢?”
產(chǎn)品經(jīng)理常問：“完成這些功能需要多長時間呢?”
技術(shù)經(jīng)理常問：”這個模塊要開發(fā)多久呢?“
自己常問：“為啥又要delay呢?”
……
所有這些問題，都會指向一件事————研發(fā)中的估點。估點是計劃的基礎(chǔ)，不論你關(guān)注還是不關(guān)注它，它都在那里。估點不是拍腦袋，是一種對事件的客觀描述方式。通過統(tǒng)計學(xué)可以讓我們知道，用兩個數(shù)字就能夠描述世界——期望和方差。然而，如果沒有歷史數(shù)據(jù)的話，統(tǒng)計學(xué)的技術(shù)方法就無法應(yīng)用。因此，估點既是獲取研發(fā)中經(jīng)驗數(shù)據(jù)的開始，也貫穿于研發(fā)過程的始終。
從零開始——無歷史參考的初始估點
對產(chǎn)品開發(fā)時間的估算有多重方式，其中目標(biāo)分解后對每個子任務(wù)的時間估算一般被認(rèn)為是估點，產(chǎn)品開發(fā)時間的估算是由估點后形成的關(guān)鍵路徑?jīng)Q定的。對于估算本身而言，如果是基于一種次序性的尺度，而且有把握對等距尺度作出解釋，那么就可以在這種類型的數(shù)據(jù)上安全地執(zhí)行推斷性統(tǒng)計分析，從而得到預(yù)測的結(jié)果。
如果使我們的研發(fā)時間估算相對準(zhǔn)確，那么估點中的等距尺度是什么呢?
估點的單位
不論是TRIZ還是一般的架構(gòu)思想，都會考慮以終為始。 對于估點中的等距尺度即估點的時間單位而言，也是如此。
既然要得到一個時間的數(shù)值，進一步提高準(zhǔn)確度的話，還需要一個置信區(qū)間，所以估點應(yīng)該依據(jù)一個相等的時長。就像我們在物理課上做測量那樣，需要一個測量單位。如果單位是米，誤差就可能是米或者更大，如果是厘米，那么誤差就可能是厘米，以此類推。同理，如果估點的單位時長較大，那么整個估算的誤差也會較大，如果估點的單位時長過小，那么操作起來就會比較復(fù)雜，就像我們學(xué)生時代使用游標(biāo)卡尺去測量長度那樣。
那么多大的時長是相對合適的呢?
互聯(lián)網(wǎng)上有一種說法，“三個月就是一年”，不僅是形容了互聯(lián)網(wǎng)的發(fā)展速度，而且是符合敏捷開發(fā)的思想和實踐的——快速迭代。三個月就是一年，這是一個1:4的關(guān)系，一周頂四周用，一天相當(dāng)于四天，那么兩個小時(Double Hours，DHR)就相當(dāng)于一天了。因此，對人/天的任務(wù)估算可以轉(zhuǎn)化為對人/DHR的估算，也就是說，估點的單位時長為兩個小時(DHR)是相對合理，而且是可以接受的。
初始估點的方法
作為一個新組建的團隊，如果沒有可測量的歷史數(shù)據(jù)作為支撐，那么初始估點的方式一般是：
將產(chǎn)品的目標(biāo)轉(zhuǎn)化為一個個以兩小時為單位的可開發(fā)實現(xiàn)任務(wù)。
將產(chǎn)品的目標(biāo)轉(zhuǎn)化為以DHR為單位的小任務(wù)是一個設(shè)計、建模和架構(gòu)的過程，同樣可以通過敏捷開發(fā)的方法來實現(xiàn)。具體地，就是明確我們的Sprint周期，根據(jù)需求來定義用戶故事，將用戶故事拆分為一個個以每兩小時為單位的backlog。
估點中兩個主要的難點是：需求的不確定性 和 思維的系統(tǒng)性。
需求的不斷變化是導(dǎo)致估點無效的主要因素，這就要求對需求的邊界有相對明確的定義和細化。軟件估算的準(zhǔn)確度取決于對軟件定義的細化程度，必須通過排除可變性來源的方法來實現(xiàn)對需求邊界的界定。 同時，由一個人來估算“有多少”，由另一個人來估算“有多不確定”，這是考慮不確定性影響的一種不錯的方式。
對于思維的系統(tǒng)性是指我們思考問題過程中的盲點，也就是說，有一些我們可能遺漏的東西，可以通過建立一個檢查列表的方式實現(xiàn)，這一列表可以根據(jù)自己的團隊來補充完善。筆者曾經(jīng)遇到過的功能性遺漏包括：
- 安裝程序和構(gòu)建環(huán)境
- 數(shù)據(jù)轉(zhuǎn)換和數(shù)據(jù)遷移的相關(guān)工具
- 使用第三方API或者開源軟件所需的集成代碼和選型評估
- 幫助和引導(dǎo)系統(tǒng)
- 部署方式和監(jiān)控管理
- 與外部系統(tǒng)接口的集成、測試及評估
非功能性需求往往是隱式的，但對于架構(gòu)而言是必須關(guān)注的，筆者曾經(jīng)遇到遺漏過的非功能性需求約束包括：
- 互操作性，產(chǎn)品所運行的環(huán)境與產(chǎn)品之間的相互影響
- 可修改性，這是一個參數(shù)化的過程，要求對內(nèi)容或展現(xiàn)形式的動態(tài)修改
- 性能，具體的性能指標(biāo)是否實現(xiàn)
- 可靠性，結(jié)果是否確定，異常是否處理全面等
- 可復(fù)用性，這一功能是否可以復(fù)用，粒度如何(函數(shù)，模塊乃至服務(wù)的復(fù)用性)等
- 可伸縮性，隨著數(shù)據(jù)規(guī)模或者時間的變化是否可以實現(xiàn)彈性
- 安全性，涉及安全的林林總總，例如SQL注入，跨域攻擊等等
- 抗毀性，是高可用性的一個分支，主要考慮服務(wù)可恢復(fù)的場景
- 易用性，使用是否容易，不論是涉及用戶交互，還是進程間或進程內(nèi)的相互調(diào)用
其中性能在估點時尤其是項目的初期是一個非常有爭議的話題，那句“過早優(yōu)化是萬惡之源”實際上是我們對高德納先生的斷章取義，原文大概是這樣的：
我們應(yīng)該在例如97%的時間里，忘掉小處的效率;
過早優(yōu)化是萬惡之源。
但我們不應(yīng)該錯過關(guān)鍵的3%中的機會。
實際上，非關(guān)鍵路徑上的優(yōu)化是萬惡之源，問題的核心所在————如何確定我們的代碼是否在關(guān)鍵路徑上。不論節(jié)省的時間是多少，花費在關(guān)鍵路徑上的性能優(yōu)化都是值得的，也是我們必須要重視的。
估點的簡單示例
舉一個最常見的例子——用戶登陸，如何進行估點呢?
首先，確定這一功能的邊界。這里不用贅述領(lǐng)域驅(qū)動開發(fā)或者5W1H等其他的設(shè)計方法，一個簡單的用戶故事描述可能是這樣的：
作為一個XXX系統(tǒng)的用戶，可以通過在客戶端輸入帳戶信息登陸到XXX系統(tǒng)，看到XXX系統(tǒng)的主頁面。
接著，把這一用戶故事轉(zhuǎn)換成可以實現(xiàn)的backlog。采用面向接口的方式，把它分割成前后端的設(shè)計，那么接口協(xié)議的設(shè)計可以作為一個backlog。對用戶故事中的對象實體進行分析同樣是一個backlog，用戶是否分類?用戶是否存在不同的類型，這涉及到后臺的數(shù)據(jù)表設(shè)計?？蛻舳擞心男╊愋?，Android，iOS，還是網(wǎng)頁?不同的客戶端是否具有相同的呈現(xiàn)形式，還是有各自的特點? 帳戶信息指的的是什么?用戶名/密碼? 用戶名是否有規(guī)則呢?密碼是否密文傳輸?……
簡化起見，對各種客戶端的登陸實現(xiàn)分別作為一個backlog，后臺的登陸接口實現(xiàn)以及數(shù)據(jù)表設(shè)計作為一個backlog。得到的估點結(jié)果是，6個人/DHR。
這就足夠了嗎?
對于功能性需求而言，如果前置條件不足，就需要考慮注冊與登錄的一致性，登錄失敗等異常處理和引導(dǎo)有可能又是一個backlog。如果允許使用第三方帳戶登錄，那又是一個backlog。登錄頁面的引導(dǎo)和幫助，又是一個backlog ……
對于非功能性而言，如果開發(fā)者使用的是新的電腦?那么環(huán)境的搭建也將是一個backlog。如果需要持續(xù)集成，那么Jinkens的搭建及各端構(gòu)建腳本的編寫同樣至少是一個backlog?？紤]性能因素，引入緩存不會少于兩個backlog。對于安全性問題，客戶端在輸入的時候需要規(guī)則檢驗，同時要做簡單的防SQL注入，至少是一個backlog。 至于易用性，是否要在客戶端記住用戶名/密碼，在跟換用戶登錄時，如何處理本地的存儲，往往涉及多用戶使用同一終端登錄的問題，至少又一個backlog。 如果一個用戶在多個終端同時登錄，會是一種怎樣的表現(xiàn)呢?這往往用一個新的用戶故事來描述更好。當(dāng)用戶總量和并發(fā)發(fā)生變化的時候，在一個怎樣的范圍內(nèi)，應(yīng)用的后臺可以足夠適應(yīng)……
具體的情況還有很多，一個登錄的功能模塊，backlog可以從6個到20多個不等，當(dāng)產(chǎn)品的定義不能覆蓋我們在技術(shù)上的定義要求的時候，我們有責(zé)任和義務(wù)就估點提出建議和解決方案。
在我們把目標(biāo)分解為backlog 之后，具體的就是在兩個小時內(nèi)完成交付了。同樣采用一比四的方式，兩個小時被分為四段————半小時設(shè)計，半小時測試代碼，半小時編碼實現(xiàn)，最后半小時是測試和文檔輸出，這不是絕對的，可以交叉，但最好是相對清晰。幸運的是，半小時剛好滿足番茄工作法對時間的要求。
在確定了估點之后，思考不確定性是必要的。例如對這一登錄的示例而言，如果6個DHR是一個最大可能的時間，最樂觀的估計可能是2個DHR，最悲觀的估計是8個DHR，可以通過簡單的經(jīng)驗公式得到一個估算值：
估算時間=( 樂觀估計 + 可能時間*4 + 悲觀估計)/6
即 (2+6*4 +8)/6= 5.7 DHR，這個數(shù)是可以作為一個期望值的。
尤其需要注意的是，對系統(tǒng)架構(gòu)而言，往往要復(fù)雜的多，但是思路和方法是一致的。對整個產(chǎn)品而言，資源的約束和關(guān)鍵路徑的組成，對產(chǎn)品開發(fā)周期的整體估算是至關(guān)重要的。一般地，我們需要使用協(xié)同工具來關(guān)注資源的約束和關(guān)鍵路徑。在自己使用過的協(xié)同工具中，筆者認(rèn)為trello 是非常出色的服務(wù)之一，可以對估點進行詳細的記錄和追蹤，同時通過對支持trello 各種插件的使用，可以生成燃盡圖等的數(shù)據(jù)圖表，從而更有效地了解產(chǎn)品開發(fā)過程的真實進度。
多元估點——數(shù)據(jù)方法的佐證
當(dāng)進行了三個以上的sprint之后，相等于初步完成了對研發(fā)過程中相關(guān)數(shù)據(jù)的采集。這時候，對于新產(chǎn)品的研發(fā)估點而言，同樣可以初始估點中的方法，因為將目標(biāo)轉(zhuǎn)化成以DHR為時間單位的思路和方法是相同的。同時，通過對歷史數(shù)據(jù)的計數(shù)分析，可以采用統(tǒng)計學(xué)中的一些方法進行評估，得到對產(chǎn)品開發(fā)時間的另一種估算結(jié)果。將使用統(tǒng)計估算的結(jié)果與初始估點的估算結(jié)果進行比較，可以進一步判斷估點的置信區(qū)間，從而提高估點的準(zhǔn)確性和可信度。
對歷史數(shù)據(jù)的提取和采集
對哪些歷史數(shù)據(jù)進行選取并作為估點的依據(jù)呢?同樣存在很多的方法，比較簡單有效的歷史數(shù)據(jù)就是代碼行數(shù)了。盡管代碼行數(shù)又著各種各樣的局限，但是以其他數(shù)據(jù)作為估算的依據(jù)可能會更糟糕。
對于存儲代碼的版本管理工具而言，Git 幾乎是大多數(shù)開發(fā)團隊的首選。在Git的開源社區(qū)中有一些可視化的工具如gitk，giggle等，可以用來查看產(chǎn)品的開發(fā)歷史。但對于大型的項目，這些簡單的可視化工具就可能不足以了解完整的開發(fā)歷史了，因為一些定量的統(tǒng)計數(shù)據(jù)(如每日提交量，行數(shù)等)更能反映開發(fā)進程和活躍性。GitStats是筆者推薦的一個好工具，它是一個Git倉庫分析軟件，可以幫助我們查看Git倉庫的狀態(tài)，自動生成相關(guān)的數(shù)據(jù)圖表，它所生成的統(tǒng)計數(shù)據(jù)如下：
- 常規(guī)的統(tǒng)計：文件總數(shù)，行數(shù)，提交量，作者數(shù)。
- 活躍度：每天中每小時的、每周中每天的、每周中每小時的、每年中每月的、每年的提交量。
- 所有參與開發(fā)的作者數(shù)據(jù)：列舉所有的開發(fā)者(提交數(shù)，第一次提交日期，最近一次的提交日期)，并按月和年來進行劃分。
- 文件數(shù)：支持按日期劃分以及按文件的擴展名來劃分。
以及代碼行數(shù)：按日期劃分。
GitStats的下載網(wǎng)址為http://gitstats.sourceforge.net/，也可以從github上獲得：https://github.com/trybeee/GitStats， 這是一個基于Python 的程序，調(diào)用git 自身的相關(guān)命令獲取數(shù)據(jù)，使用Gnuplot 作為繪圖工具，最終生成HTML的文件作為輸出結(jié)果。
GitStats的使用方法非常簡單，示例如下：
./gitstats /home/abel/git/project ~/gitstats_html/project
Git項目在/home/abel/git/project下，生成的統(tǒng)計數(shù)據(jù)放在~/gitstats_html/project目錄下。以老曹經(jīng)歷的一個產(chǎn)品為例，gitstats輸出的常規(guī)信息如下：
從中可以發(fā)現(xiàn)一些有趣的數(shù)字，比如增加了1882629行代碼，同時刪除了1392776行代碼。是代碼的重構(gòu)還是需求變化導(dǎo)致的呢?
看一看每天中哪個時段或者一周中的哪一天代碼的提交比較頻繁：
還可以看到每個開發(fā)者在該產(chǎn)品中的貢獻情況：
基于統(tǒng)計數(shù)據(jù)的估算
基于統(tǒng)計數(shù)據(jù)的估算有著一些基本的假設(shè)，例如開發(fā)人員的開發(fā)時間全部應(yīng)用于某一產(chǎn)品的開發(fā)，而不是時分復(fù)用，不同產(chǎn)品之間是相對獨立的等等。通過對大目標(biāo)的估算分解成對小任務(wù)的估算，利用大數(shù)法則，讓偏大的誤差和偏小的誤差在一定程度上相互抵消。
其中的一個難點和不確定性是backlog與代碼行數(shù)之間的對應(yīng)關(guān)系，一個功能的實現(xiàn)采用不同的編程語言代碼量不同，比如通過http 請求獲取一個頁面，Java可能需要30行代碼，而Python可能不超過5行。如果采用相同語言，使用不同的庫導(dǎo)致代碼量同樣會有較大差別。即使采用相同的編程語言和相同的庫，開發(fā)人員本身的技能水平同樣會導(dǎo)致代碼量差異。
因此，基于統(tǒng)計數(shù)據(jù)的估算一般來說是面向開發(fā)者個人的，也就是說，首先要保持團隊的相對穩(wěn)定，然后讓開發(fā)者根據(jù)自己的數(shù)據(jù)進行估算比較好，因此，針對同一個業(yè)務(wù)的開發(fā)，不同的開發(fā)者建立的backlog 可能是不同的。
如何找到每個backlog對應(yīng)的代碼量呢?如果使用trello 來跟蹤backlog狀態(tài)的話，可以通過trello的開發(fā)者API 通過程序來獲得每個backlog的時間段，同時在流程中約定，在每個backlog 的DHR過程中中必須提交代碼，這樣就可以從git倉庫中針對每個開發(fā)者的每個backlog進行代碼量的統(tǒng)計了。
至于backlog 之間的相似性，也是以開發(fā)者自身的縱向?qū)Ρ葹橹?。因為一個資深的工程師和一個一般水平程序員之間的橫向?qū)Ρ韧痪邆淇杀刃?，這或許就是所謂“10倍生產(chǎn)率”的一個表現(xiàn)。
舉個簡單的例子，如果工程師A歷史數(shù)據(jù)中每個backlog的代碼行數(shù)平均值為100行，標(biāo)準(zhǔn)差是30行的話，就可以嘗試根據(jù)正態(tài)分布計算置信區(qū)間了。
其他參考模型的估算
當(dāng)然，這時也可以參考其他常見的軟件估算模型進行多元估點，例如Putnam模型。Putnam是一種動態(tài)多變量模型，其中L代表源代碼行數(shù)，K代表開發(fā)的工作量，Tdev表示開發(fā)時間，Ck是技術(shù)狀態(tài)常數(shù)取值因開發(fā)環(huán)境而定，得到的開發(fā)時間估算公式如下：
還有比較有名的COCOMO II 模型，在COCOMO II 模型中關(guān)于進度的估算公式如下：
具體解釋參見參考閱讀。
需要注意的是，傳統(tǒng)估算模型都是以人/天，人/月甚至人/年為單位的，我們要轉(zhuǎn)換成以DHR為單位，那些參數(shù)也需要根據(jù)自己的歷史數(shù)據(jù)進行不斷的校準(zhǔn)。
這樣，我們就可以嘗試用多元估點的方法對估算的最終結(jié)果進行比較和進一步評估了。
處理產(chǎn)品與研發(fā)間的估點矛盾
產(chǎn)品經(jīng)理和研發(fā)人員的矛盾主要是開發(fā)周期的目標(biāo)與估點結(jié)果之間的矛盾。作為一名研發(fā)人員或者技術(shù)管理者，在與產(chǎn)品經(jīng)理或者項目經(jīng)理進行溝通的時候最好保持以下原則：
- 把人和問題分開，也就是我們提倡的“對事不對人”
- 更關(guān)注利益，產(chǎn)品的哪些功能交付可以為團隊乃至公司帶來怎樣的利益，而不是出于不同分工的立場
- 我們是一條繩上的螞蚱，創(chuàng)造可以共同獲利的可行方案
- 堅持使用客觀標(biāo)準(zhǔn)，任何的主觀臆斷都可能會導(dǎo)致相互間誤會的加劇
溝通中的要素
我們要記下估算中包含的假設(shè)，并就此進行溝通。同時，明確表達的是估算結(jié)果中的不確定性，而不是自己達到承諾的能力的不確定性。不要向其他干系人提供只有很小可能的估算結(jié)果，最好以圖形代表文本作為估算值的表達形式。
不要用范圍表示承諾，承諾應(yīng)該是明確的，也就是說，我們承諾何時可以完成就要在那個時間點必須完成，這是一種職業(yè)的態(tài)度和操守?？梢詫Τ兄Z進行溝通，但不要對估算值進行談判，讓產(chǎn)品/項目經(jīng)理了解有效的估算實踐是有意義的，最好讓他們幫助檢查估算中10個問題：
- 是否明確定義了估點目標(biāo)?
- 是否包括完成任務(wù)所需的所有工作類型?
- 是否包含了完成任務(wù)所需的所有功能領(lǐng)域?
- 是否被分解到足夠詳細的程度，可以揭示所有隱藏的工作?
- 是否使用來自過去的歷史數(shù)據(jù)，設(shè)定的生產(chǎn)率是否接近于類似工作所達到的生成率?
- 是否被實際要完成開發(fā)工作的工程師所認(rèn)可?
- 是否分別包含了最好情況，最差情況和最可能情況,最差情況是否真的最差?是否還有更差?
- 是否從這些情況中正確的計算出了預(yù)期情況?
- 是記錄了估算中的假設(shè)?
- 估算做出后是否發(fā)生了改變?
除非有定量推算的方法，否則不要提供“百分之多少的置信度”形式的估算值(尤其是“90%置信度”)，從個人經(jīng)驗上看，大部分直覺上的90%置信度實際上相當(dāng)于30%置信度。
妥協(xié)與共贏
謹(jǐn)慎對待進度壓縮和最短的可能進度，因為縮短名義上的進度會增加總工作量。由于可能存在難以突破的或者難以實現(xiàn)的關(guān)鍵點，如果我們必須要面對壓縮進度，最好不要讓進度縮短的幅度超過25%。如果縮減團隊規(guī)模，使進度變得寬松一些，通常會減少總工作量。也就是說，延長進度并采用較小的團隊，可降低開發(fā)的成本。但需要注意的是，讓進度延長超過30%很可能會產(chǎn)生各種低效的情況，反而會增加成本。
最后期限的壓力往往是軟件工程中最危險的敵人。過度緊張的或不合理的進度是對所有產(chǎn)品開發(fā)最具破壞力的影響因素。所以，盡量不要故意低估，低估帶來的損失比高估帶來的損失更嚴(yán)重。最好通過計劃和控制來解決對高估的顧慮，而不要故意降低估算值。高估帶來的損失往往是線性而且是有限的，但是，低估帶來的損失是非線性增長的而且是沒有限制的，很多時候，更多bug所產(chǎn)生的損害比高估要嚴(yán)重的多。
在討論進度的時候，提出盡可能多的可選計劃，為達到開發(fā)的目標(biāo)提供支持。在形成合作式解決問題的氣氛時，千萬不要根據(jù)即興估算(拍腦袋)做出任何承諾。也就是說，不要對估算結(jié)果本身進行溝通，堅持由有資格的人來進行估算，參考所在開發(fā)組的歷史數(shù)據(jù)和估算方式，經(jīng)受住理念沖突的考驗。 當(dāng)遇到僵局的時候，只思考一個問題————“怎樣才對我們的組織/公司最有利” 。
回顧與小結(jié)
對軟件開發(fā)的估算是對開發(fā)持續(xù)時間的一種預(yù)測，以期望達到產(chǎn)品和業(yè)務(wù)的目的，進而許諾在特定的日期之前以特定的質(zhì)量水平交付規(guī)定的功能。
估算應(yīng)該是相對客觀的分析過程，目的是得到相對準(zhǔn)確的結(jié)果;而規(guī)劃與計劃一般是主觀的目標(biāo)求解過程，目的是尋求一種特定的結(jié)果。在傳統(tǒng)的軟件工程中，估算的準(zhǔn)確度最高可達±10%,也只有在控制很好的項目中才能達到。估算的首要目標(biāo)不是預(yù)測最終的結(jié)果，而是確定目標(biāo)是否能夠?qū)崿F(xiàn)，從而在可控的狀態(tài)下完成這些目標(biāo)，無需非常準(zhǔn)確而是要有效。良好的估算是對項目實際情況有足夠清晰的看法，讓管理層可以作出可控而且能夠達到目標(biāo)的決策。
具體地說，以DHR作為初始估算的時間單位，確定目標(biāo)需求的邊界，進而檢查功能的完備性以及非功能性約束是否遺漏，得到估點的期望值。進一步，以歷史數(shù)據(jù)為依據(jù)，通過統(tǒng)計方法或其他估算模型進行多元估點，對多種估算結(jié)果進行比較，可以得到置信區(qū)間以及對估算的結(jié)果進行糾偏。 最后，與產(chǎn)品/管理團隊溝通協(xié)商做出承諾，團結(jié)一致，全力做好產(chǎn)品。
【本文來自51CTO專欄作者“老曹”的原創(chuàng)文章，作者微信公眾號：喔家ArchiSelf,id:wrieless-com】
