首頁(yè)>項目團隊 > 正文

軟件項目團隊的績(jì)效量化

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


分享到:

免責聲明:
  1、項目經(jīng)理人發(fā)布的所有資訊與文章是出于為業(yè)界傳遞更多信息之目的,并不意味著(zhù)贊同其觀(guān)點(diǎn)或證實(shí)其描述。其原創(chuàng )性以及文中陳述文字和內容未經(jīng)本站證實(shí),對本文以及其中全部或者部分內容、文字的真實(shí)性、完整性、及時(shí)性本站不作任何保證或承諾,請瀏覽者僅作參考,并請自行核實(shí)相關(guān)內容。
  2、本站部分內容轉載于其他網(wǎng)站和媒體,版權歸原作者或原發(fā)布媒體所有。如文章涉及版權等問(wèn)題,請聯(lián)系本站,我們將在兩個(gè)工作日內進(jìn)行刪除或修改處理。敬請諒解!

關(guān)于我們 聯(lián)系我們 版權聲明 隱私保護 投訴建議 卓橡資源

Copyright ? 2021 項目經(jīng)理人 版權所有 京ICP備17062359號-3 如轉載本站文章,請注明原作者和原發(fā)布媒體
本著(zhù)互聯(lián)網(wǎng)分享精神,本站部分內容轉載于其他網(wǎng)站和媒體,如稿件涉及版權等問(wèn)題,請聯(lián)系本站進(jìn)行刪除或修改處理
客服電話(huà):010-89506650 89504891 非工作時(shí)間可聯(lián)系:18701278071(微信) QQ在線(xiàn):511524637
新聞與原創(chuàng )文章投稿:tougao#cpmta.com 客服郵箱:info#cpmta.com(請將#換成@)
項目經(jīng)理人——我國項目經(jīng)理職業(yè)發(fā)展門(mén)戶(hù)網(wǎng)站,隸屬卓橡公司