4 敏捷的挑戰(zhàn)-衡量交付的價值
對于傳統(tǒng)的、瀑布式的軟件開發(fā)項目，功能性和非功能性需求一般在前期就已經(jīng)確定了，在開發(fā)階段不允許（或很少）進行更改。因此，就可能會導(dǎo)致在經(jīng) 過長期的交付和測試階段后，軟件的需求變更可能已經(jīng)很小。
敏捷開發(fā)的主要思想是通過短的反饋循環(huán)快速交付軟件。敏捷開發(fā)是軟件行 業(yè)中主流的方法，其優(yōu)勢如下：
? 靈活性和適用性：敏捷方法，如Scrum或看板，優(yōu)先考慮適應(yīng)性。為了 使團隊能夠快速響應(yīng)客戶或市場需求，它們甚至可以在開發(fā)過程的后期更改需求、設(shè)計和優(yōu)先級。
? 以客戶為中心：敏捷專注于通過迭代開發(fā)周期為客戶提供價值。通過客戶或其它利益相關(guān)者的定期反饋可確保交付的產(chǎn)品與客戶需求一致。
? 快速交付價值：敏捷強調(diào)在sprint（小型增量迭代）中交付工作產(chǎn)品。這意味著軟件的功能部分可以快速交付，在開發(fā)過程的早期提供可見的交付。
? 質(zhì)量提升：持續(xù)的測試、頻繁的評審和迭代有助于提高產(chǎn)品質(zhì)量，及早發(fā)現(xiàn)并解決問題，可以降低最終產(chǎn)品出現(xiàn)重大缺陷的可能性。
? 增強團隊協(xié)作：敏捷可以促進跨職能團隊之間的協(xié)作。每日站會、定期溝通和對任務(wù)的共同所有權(quán)都培養(yǎng)了團隊合作和集體責任感。
? 透明度和可見度：敏捷實踐通過項目進度、挑戰(zhàn)和障礙對所有團隊成員可見的方式來提高透明度，有助于團隊及時發(fā)現(xiàn)和解決問題。
? 風險緩解：將項目分解為更小的迭代可以實現(xiàn)更好的風險管理?？梢约霸绨l(fā)現(xiàn)問題或障礙，并在更短的時間內(nèi)解決，從而降低項目的總體風險。
? 強調(diào)持續(xù)改進：敏捷方法強調(diào)持續(xù)改進。在每次迭代結(jié)束時，團隊都會反思哪些工作的好，哪些不好，并為下一次迭代做調(diào)整。
? 適應(yīng)性規(guī)劃：敏捷不依賴于僵化的長期規(guī)劃。計劃會根據(jù)反饋、不斷變化的市場條件或新的需求進行調(diào)整，從而實現(xiàn)更有效、更現(xiàn)實的規(guī)劃。
? 客戶滿意度高：讓客戶參與整個開發(fā)過程并提供滿足需求的功能，敏捷通常會帶來更高的顧客滿意度和更好的產(chǎn)品市場適應(yīng)性。
這些優(yōu)勢有助于敏捷在產(chǎn)品交付方面的普及和成功，敏捷產(chǎn)品更符合客戶需求，質(zhì)量更高，并能以更高效和適應(yīng)性更強的方式完成。
4.2 敏捷調(diào)查
在大多數(shù)企業(yè)中，每個團隊的預(yù)算是可以預(yù)測的（每個團隊成員的工作時間*每個團隊成員成本），但產(chǎn)生的價值卻并非如此。使用故事點度量的團隊有時可能看起來非常高效，但實際上可能并沒有產(chǎn)生預(yù)期的價值。如下圖所示。
在圖中，假設(shè)一個團隊開始開發(fā)最小可行產(chǎn)品（MVP），并且正在進行的開 發(fā)使用Scrum（一個用于項目管理的敏捷框架）。
在圖中的Y軸上，每次sprint的固定容量為1000工時。這些工時用于需要進行的各種活動。在第一次sprint中，可以在新增功能（綠色模塊）上占用大量 的工作量。當然，也有一些必要的任務(wù)不能直接提供功能規(guī)模，例如設(shè)置測試環(huán)境等。這些任務(wù)（紅色模塊）是必要的，但不會產(chǎn)生可見的價值。因此，團隊應(yīng) 該盡可能少在這些沒有產(chǎn)生可見價值的任務(wù)上耗費工作量。
隨著時間的推移，客戶可能會更改已開發(fā)的功能（藍色模塊），甚至刪除已開發(fā)的功能（橙色模塊）。在sprint中后期，可能會出現(xiàn)新的紅色模塊。比如：代碼重構(gòu)和bug修復(fù)， 在MVP上線后，可能還需要三線支持。
如前所述，許多團隊使用主觀的、相對的、工作量估算的故事點方法。他們將故事點分配給所有需要工作量的任務(wù)，但沒有考慮任務(wù)類型。因此，紅色模塊也會分配故事點，因為它們也需要工作量。下圖解釋了這一說法。
當看到開發(fā)的故事點時，管理層可能會對團隊的表現(xiàn)非常滿意，因為團隊每次sprint可以產(chǎn)生80個故事點，因此他們認為估算是準確的。然而，當查看以添加、修改和刪除功能綜合來表達提供的價值時，團隊績效會隨著時間的推移而下降。
例如，當 MVP 的功能規(guī)模為 500 功能點時，故事點度量方法并不能看出：MVP 何時準備就緒，是否能夠按時交付且與業(yè)務(wù)功能保持一致。而功能點度量方法可以。
功能規(guī)模測量的 Nesma 標準（ISO/IEC 24570-1983）中定義了特定時間段（例如，sprint、月份、版本、季度等）內(nèi)項目規(guī)模的概念，如下所示：
項目規(guī)模=新增功能+修改功能+刪除功能
項目規(guī)模是開發(fā)團隊創(chuàng)造的價值，與項目規(guī)模相關(guān)的度量指標如下：
? 生產(chǎn)率：工時/項目規(guī)模；
? 成本效益：成本/項目規(guī)模；
? 交付速度：項目規(guī)模/月數(shù)；
? Sprint 質(zhì)量：缺陷數(shù)/項目規(guī)模。
通過測量這些指標以及故事點，團隊、產(chǎn)品負責人和管理層可以了解團隊的真實績效，也可以使用ISBSG數(shù)據(jù)對團隊績效進行基準測試。
5 度量方法的特點
好的度量方法都有共同的特點，這些特點能夠有效地衡量團隊績效或項目進展：
1、相關(guān)性：應(yīng)與項目目標直接一致，必須度量對預(yù)期結(jié)果有實際影響的指標；
2、清晰度：應(yīng)該易于理解和解釋，模棱兩可或復(fù)雜的指標可能導(dǎo)致混淆和 誤解；
3、可度量：度量是可量化的，或者至少有一個明確的度量方法?？梢噪S著時間的推移進行一致的跟蹤和比較；
4、可實施：好的度量應(yīng)該是可實施的，并可以指出需要改進的地方；
5、及時性：應(yīng)及時提供信息，實時或定期更新的度量方法通常更有價值， 因為這樣有助于快速調(diào)整和決策；
6、一致性：在不同的時間、團隊或部門之間保持一致和可比性。一致性確保了評估進程的可靠性；
7、成本效益：收集和分析過程不應(yīng)過于耗費資源。使用該方法的成本應(yīng)取決于其提供的價值；
8、戰(zhàn)略一致性：應(yīng)與企業(yè)更廣泛的戰(zhàn)略目標掛鉤，因為這樣有助于衡量實 現(xiàn)這些總體目標的進展情況；
9、背景：需要了解度量方法的背景，在不考慮背景的情況下進行比較很可能會產(chǎn)生誤判；
10、閉環(huán)：良好的度量方法有助于形成閉環(huán)。
在下表中，從企業(yè)管理層面（包括利益相關(guān)者，如產(chǎn)品所有者、高級IT經(jīng)理和管理層）對故事點度量方法和功能規(guī)模度量方法的特點進行了評價。
表中各符號含義：+++：非常相關(guān)，++：主要相關(guān)，+：部分相關(guān)，-：相關(guān) 性不大，---：不相關(guān)
那么，為什么在使用功能規(guī)模度量方法的企業(yè)卻不多呢？在傳統(tǒng)的軟件開發(fā)時代，人們把許多項目的失敗原因都歸咎于功能點，因此功能點在當時使用并不 廣泛。此外，反對使用功能點還有一層原因：由于需要經(jīng)過認證的專家來度量功能規(guī)模，因此使用功能點方法的成本非常昂貴。
如今，有一種技術(shù)可以從用戶故事中自動度量功能規(guī)模。此外，由于sprint中開發(fā)的功能通常是有限的（通常每個sprint 不超過100個功能點），因此手動度量所需時間非常短。例如，使用功能規(guī)模度量方法可以在2到4小時內(nèi)度量一個Sprint的項目規(guī)模。Scrum大師或產(chǎn)品所有者都能夠很容易地學習該方法。
6 總結(jié)
故事點度量對團隊層面的規(guī)劃非常有用。但是，故事點方法不適用于進行團隊間的相互比較或與行業(yè)數(shù)據(jù)（如ISBSG數(shù)據(jù)）進行比較。
功能規(guī)模度量中的指標，如生產(chǎn)率、成本效益、交付速度和Sprint質(zhì)量，是客觀且可重復(fù)的，它們不依賴于非功能性和項目需求。
企業(yè)應(yīng)致力于提升團隊功能規(guī)模度量能力和使用自動度量功能規(guī)模的技術(shù)，從而幫助管理層提高其企業(yè)的價值交付能力。
以上就是軟件造價評估公司中基數(shù)聯(lián)為您帶來的“故事點和功能點度量方法的主要差異分析（下）”所有內(nèi)容，更多軟件開發(fā)成本估算知識敬請關(guān)注中基數(shù)聯(lián)！
