<tr id="yjjbo"></tr>

      1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>
      2.   
        首頁>項目團隊 > 正文

        軟件項目團隊的績效量化

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


        分享到:

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

        關于我們 聯系我們 版權聲明 隱私保護 投訴建議 卓橡資源

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

        久久精品99国产精品日本,欧美熟妇黑人ⅩXXXXX,两个小婕子和我做受HD
            <tr id="yjjbo"></tr>

            1. <ruby id="yjjbo"><option id="yjjbo"></option></ruby>