寫在前面
最近看了一本書《團(tuán)隊(duì)軟件過程》。
本來是想研究下這個(gè)過程的原理之類的內(nèi)容，后來被其中的一些度量指標(biāo)吸引了。
合上這本書，我覺得對(duì)于我來說，收獲最大的就是了解到原來除了我們耳熟能詳?shù)娜毕萋?，Reopen率等等外，還有那么多的可以使用的度量指標(biāo)。
在講這些指標(biāo)之前，我想先說一下《團(tuán)隊(duì)軟件過程》到底介紹了一種什么過程。
TSPi
為研究生或高年級(jí)本科生的團(tuán)隊(duì)軟件工程課程而設(shè)計(jì)的框架。
指導(dǎo)學(xué)生一步步的完成團(tuán)隊(duì)軟件項(xiàng)目課程，并教會(huì)你如何在團(tuán)隊(duì)協(xié)作環(huán)境中應(yīng)用成熟的軟件工程和軟件過程。
我不禁有些感慨，現(xiàn)在的學(xué)校都已經(jīng)開始做這種實(shí)操的練習(xí)了。
其實(shí)這樣挺好的，讓學(xué)生親身經(jīng)歷整個(gè)項(xiàng)目過程以及各種角色，會(huì)有更多的體會(huì)。
研究了下TSPi是TSP的簡化版本，專門為了培訓(xùn)和軟件工程而定制的。
麻雀雖小，五臟俱全。
TSPi在過程中通過周期性的迭代的方式開展工作，每個(gè)周期包含完整的計(jì)劃、設(shè)計(jì)、開發(fā)、測試、總結(jié)。
但是因?yàn)檫x擇的策略不同，可以是在瀑布的大過程中嵌套小周期迭代，也可以純迭代。
我覺得這也是TSPi與敏捷過程的一個(gè)不同之處。
另外一個(gè)不同之處在于，TSPi很強(qiáng)調(diào)度量和評(píng)估。
不僅要在每個(gè)周期進(jìn)行度量和評(píng)估，還要對(duì)包括角色、質(zhì)量、規(guī)模等等方面進(jìn)行評(píng)估。
所以在TSPi中給了很多的量表，很有CMMI的意思。
書中提到了很多度量的指標(biāo)，我這里摘取其中幾個(gè)我覺得比較有意思，也比較實(shí)用的分享給大家。
概要比率
這個(gè)指標(biāo)包含了三個(gè)子指標(biāo)，主要用于度量團(tuán)隊(duì)的貢獻(xiàn)情況。
LOC/小時(shí)：度量了團(tuán)隊(duì)的總體生效率
每小時(shí)寫多少行代碼，這個(gè)指標(biāo)非常常見。
復(fù)用百分比：當(dāng)前產(chǎn)品中復(fù)用以前產(chǎn)品的LOC比例
在TSPi中很強(qiáng)調(diào)代碼復(fù)用，甚至提到“在設(shè)計(jì)初期就對(duì)復(fù)用部分進(jìn)行設(shè)計(jì)”。
復(fù)用率高，表示被復(fù)用的代碼的質(zhì)量等各方面的績效不錯(cuò)，也間接的說明了在這個(gè)周期內(nèi)的產(chǎn)出質(zhì)量有一定的保證。
新增可復(fù)用百分比：新增的代碼中可以作為未來周期及項(xiàng)目的復(fù)用代碼的比例。
我們不僅要在開發(fā)的時(shí)候盡量復(fù)用之前穩(wěn)定的代碼，還需要?jiǎng)?chuàng)造一些可以被復(fù)用的代碼。
這些代碼不僅在本項(xiàng)目中可以復(fù)用，還可以被復(fù)用到其他項(xiàng)目中去。
缺陷數(shù)/KLOC
千行代碼缺陷數(shù)，這是一個(gè)重要的質(zhì)量指標(biāo)。
這個(gè)指標(biāo)沒什么好說的，主要是作者在這個(gè)指標(biāo)后面的一句話，引起了我的思考。
如果單元測試有很多缺陷，單元測試后遺留的缺陷也會(huì)很多。
也就是說，如果單元測試發(fā)現(xiàn)很多的缺陷，那就意味著有點(diǎn)先天不足的意思。
就算后期再怎么修補(bǔ)，也無法擺脫先天不足的劣勢。
而在每個(gè)周期里面對(duì)這個(gè)指標(biāo)進(jìn)行評(píng)估，就大致可以知道在后面的階段中的質(zhì)量情況。
如果構(gòu)建和集成測試的缺陷數(shù)/KLOC<0.5，系統(tǒng)測試的缺陷數(shù)/KLOC<0.2，那么一般不會(huì)有用戶使用缺陷。
一個(gè)周期內(nèi)的階段時(shí)間
TSPi強(qiáng)調(diào)在一個(gè)周期內(nèi)要把所有任務(wù)重復(fù)一遍，它也給出了各個(gè)階段任務(wù)的大致時(shí)間比例，可以作為參考。
如果評(píng)審時(shí)間達(dá)標(biāo)，其實(shí)會(huì)對(duì)質(zhì)量有一點(diǎn)的改善作用。
即會(huì)避免在單元測試的時(shí)候發(fā)現(xiàn)過多的缺陷，進(jìn)而避免先天不足的情況發(fā)生。
詳細(xì)設(shè)計(jì)時(shí)間>編碼時(shí)間
詳細(xì)設(shè)計(jì)評(píng)審時(shí)間>詳細(xì)設(shè)計(jì)時(shí)間*50%
需求評(píng)審>=需求分析時(shí)間*25%
規(guī)模度量
對(duì)于項(xiàng)目規(guī)模的度量，我們一般會(huì)使用模塊、LOC、敏捷中的點(diǎn)數(shù)進(jìn)行度量。
而作者提出了一種度量方式，挺有意思的：需求規(guī)格說明書SRS，PRD。
通過文本頁數(shù)，編號(hào)段落或者Shall語句進(jìn)行規(guī)模度量。
我覺得這個(gè)指標(biāo)對(duì)于BA和需求的小伙伴來說要求比較高。
因?yàn)楫吘宫F(xiàn)在80%以上的SRS等文檔并沒有進(jìn)行規(guī)范化、格式化。
編寫的粒度、范圍、結(jié)構(gòu)等等都沒有進(jìn)行規(guī)范化。
比如同樣的一個(gè)功能，我寫的粗了就只有2頁，寫的細(xì)了可能會(huì)有8頁。
再比如，我們?cè)趯懶枨蟮臅r(shí)候并沒有建立結(jié)構(gòu)需求語句。
所謂結(jié)構(gòu)需求語句，耳熟能詳?shù)木褪敲艚堇锩娴腁S... I want to... so that...
而這邊并不是寫一句話的user story那么簡單。
為了度量規(guī)模，需要寫的是更詳細(xì)的規(guī)格。
比如，Admin shall add new users by import excel.
統(tǒng)計(jì)整個(gè)SRS中出現(xiàn)了多少shall語句，就可以度量規(guī)模。
但是，前提是，你的語句寫的足夠規(guī)范。
如果我一時(shí)腦抽，寫了個(gè) want, need, should, will, can, is able to...那么度量的結(jié)果肯定不準(zhǔn)了。
寫在最后
前些天還和群里的小伙伴討論軟件團(tuán)隊(duì)的績效評(píng)估問題。
其實(shí)我覺得《團(tuán)隊(duì)軟件過程》中有一句話說的很在理：
團(tuán)隊(duì)度量不應(yīng)該以是否實(shí)現(xiàn)了目標(biāo)為標(biāo)準(zhǔn)，而應(yīng)該以設(shè)定目標(biāo)的意愿以及為此所做出的努力程度來評(píng)價(jià)團(tuán)隊(duì)。
