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