國際上，軟件度量的標(biāo)準(zhǔn)方法是“功能點”(FP)，這也是ISO標(biāo)準(zhǔn)，本身有近40年的歷史。是一種嚴(yán)謹(jǐn)?shù)?、可取得一致性結(jié)果的方法。
隨著敏捷方法論的出現(xiàn)，新的度量方法也就誕生了，那就是“故事點”(SP)——方法歷史較短，至今沒有形成國際標(biāo)準(zhǔn);是相對的，主要是基于團隊的自我感知。
我們遇到業(yè)界中三個常見的問題：
1、故事點與功能點有什么區(qū)別和聯(lián)系?
2、敏捷項目的度量能用功能點方法嗎?
3、故事點比功能點更快、更容易嗎?
第1個問題，——
故事點是一種“相對”的度量，敏捷小組先選定一個最簡單的故事，其規(guī)模=1，其他的故事的規(guī)模，與之相比較，用“斐波那契數(shù)列”來(1,2,3,5,8,13)相應(yīng)的表示。不同敏捷小組選定的基線是不一樣的。
而功能點則是有明確定義的，不同團隊可取得一致性的度量結(jié)果。
在估算故事點的時候，團隊總是難免要考慮到產(chǎn)品之外的因素，例如：需要投入的工作量。而功能點分析的時候，只考慮產(chǎn)出物自身的功能和特性，以及復(fù)雜程度。
故事點的方法，基本上是開發(fā)者視角。
而功能點方法，是用戶視角，或者說是業(yè)務(wù)視角?？梢酝瑫r為開發(fā)者和最終用戶服務(wù)。開發(fā)者用來管理項目的產(chǎn)出，最終用戶(Product Owner)，可以用此來建立預(yù)期——通過明確地去定義產(chǎn)品的功能和特性。
第2個問題，敏捷項目肯定是可以用功能點方法的。對于敏捷，這兩種方法都可以用來度量規(guī)模，并進行一系列的績效管理。
敏捷項目的每個sprint周期已經(jīng)固定了，一般是2個星期。所以，在這個層次，我們推薦敏捷團隊繼續(xù)使用故事點的方法。
而在整個項目的層次，例如在這敏捷項目開始時，或者有產(chǎn)出物時，功能點方法更加有效。
項目開始時，可以用功能點來估算整個backlog的規(guī)模以及成本、工期。而在項目結(jié)束時，可以用功能點來統(tǒng)計實際的產(chǎn)出規(guī)模，計算實際的生產(chǎn)效率;比較敏捷與其他方法的績效。
第3個問題，答案也是肯定的——故事點肯定是功能點更快、更容易。
使用故事點的方法，幾乎不用什么培訓(xùn)和練習(xí)，所有的人都會很快的掌握和應(yīng)用。
而功能點方法，使用者需要有專業(yè)知識，并經(jīng)過大量訓(xùn)練;需要了解用戶故事的詳細(xì)信息。
故事點方法提倡敏捷團體在一起討論，為用戶故事計數(shù)，以此來衡量故事的難度和所需的工作量。 如此，可以保證敏捷團隊都能夠很好地理解故事。
而功能點方法的使用，讓敏捷團隊的每個成員都有這方面的技能是不現(xiàn)實的，通常的做法就是在整個組織層面成立“功能點專家小組”，為各個敏捷團隊服務(wù)。
無論如何，將敏捷團隊成員納入規(guī)模估算的工作中，要比讓他們強迫接受功能點專家的結(jié)論要強。
“快和容易”不是關(guān)鍵，關(guān)鍵是你需要什么樣的度量，需要什么樣的信息——更好地管理產(chǎn)出物、制定決策、管理預(yù)期。
故事點度量的最大缺陷就是“缺乏一致性”，在一個敏捷小組的內(nèi)部，用此方法是不成問題;但是不能在多個敏捷團隊之間進行橫向比較。
對于整個組織而言，需要的是——建立生產(chǎn)率基線、缺陷密度基線、測試案例密度基線、產(chǎn)品路線圖、年度預(yù)算、人力資源計劃等等。
對于這個組織級的管理需求，使用功能點方法，可以有效地來建立度量基礎(chǔ)。
除此之外，功能點方法也可以幫助組織迅速提升業(yè)務(wù)分析、需求管理等方面的能力;可以有效地幫助IT組織從“成本型”向“價值型”轉(zhuǎn)型。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。