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