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