目標(biāo)讀者
本文讀者主要是從事或關(guān)心敏捷開發(fā)的工作者，他們相信敏捷代表了軟件交付方式的重大進步，并且希望敏捷管理會變得更好。
前言
眾所周知，敏捷的優(yōu)點是更快地交付、更好地滿足不斷發(fā)展的客戶需求。然而，賦予各個團隊管理自己流程的自由使得高層管理者管理敏捷團隊之間的活動變得困難——我們稱之為管理“大規(guī)模敏捷”。
具體地說，敏捷度量指標(biāo)，如故事點，可以管理單個團隊的活動，但對于計劃和監(jiān)控跨團隊的進度、績效以及評估未來開發(fā)的工作量幫助很小。
高層管理者負責(zé)制定預(yù)算和優(yōu)化資源分配，以便為組織交付最大的價值，并負責(zé)根據(jù)整個組織的預(yù)算跟蹤進度。對于只使用典型敏捷流程的軟件開發(fā)團隊來說，如果沒有跨團隊的工作績效數(shù)據(jù)比對，以上管理工作是無法準(zhǔn)確完成的。對于將軟件開發(fā)外包給使用敏捷但沒有任何績效度量標(biāo)準(zhǔn)的供應(yīng)商來說，這些管理任務(wù)會更加困難。
本文首先闡述了管理者在面對敏捷度量指標(biāo)管理受限時所面臨的挑戰(zhàn)，其次展示了如何將ISO軟件功能規(guī)模度量標(biāo)準(zhǔn)融入敏捷流程，從而使管理者能夠大規(guī)模地評估和控制敏捷交付。在不改變敏捷基礎(chǔ)流程的情況下，繼續(xù)獲得敏捷團隊在交付業(yè)務(wù)價值的速度和靈活性方面帶來的好處。
1、敏捷的好處
敏捷宣言引起了軟件交付的變革。敏捷的好處包括：
更早地交付；
更快地響應(yīng)需求。
也有證據(jù)表明，敏捷降低了開發(fā)成本和項目完全失敗的可能性。
2、敏捷度量的問題
敏捷度量的目標(biāo)是使用內(nèi)部團隊指標(biāo)規(guī)劃和控制開發(fā)進度，其中最常見的是“故事點”。然而“故事點”并沒有相對客觀的定義。一個故事點代表了一個用戶故事的 “規(guī)?；蜷_發(fā)難度”。這混合了兩個獨立的概念，并沒有給敏捷實踐者或管理者提供什么是一個故事點以及如何度量。
因此，每個團隊自行定義“什么是一個故事點”以及它所表示的“任務(wù)有多大”。在實踐中，這解釋為“我們估計需要多少工作量來處理這個任務(wù)”。
為給定的用戶故事確定故事點大小的過程——例如“規(guī)劃撲克”——是有價值的，主要是幫助團隊理解需求。就團隊而言，可以將故事點用于評估下一次迭代的工作量，但是故事點的“規(guī)模”并不適合個體團隊以外的績效評價和任務(wù)評估，也就是說，不適合管理“大規(guī)模敏捷”。
為了更準(zhǔn)確的管理開發(fā)任務(wù)，一個組織需要一種客觀的、標(biāo)準(zhǔn)化的方法進行評估和度量，這種方法對所有類型項目都應(yīng)該是有效的并且獨立于開發(fā)技術(shù)和開發(fā)人員的效率。
3、使用軟件功能規(guī)模測量標(biāo)準(zhǔn)方法管理 “大規(guī)模敏捷”
3.1 軟件功能規(guī)模測量方法概述
軟件功能規(guī)模測量方法（即功能點法），如IFPUG、Nesma、COSMIC等均有相關(guān)國際標(biāo)準(zhǔn)，本文不再過多贅述。
3.2 在敏捷中度量軟件規(guī)模
在討論何時進行軟件規(guī)模度量前，首先需要識別三個層級的度量指標(biāo)。參見下圖，該圖從敏捷管理SAFe框架衍生而來。
圖 1 大規(guī)模敏捷管理框架
簡單來說，只有使用標(biāo)準(zhǔn)化的功能規(guī)模測量方法，才能在系統(tǒng)和發(fā)布級別進行適當(dāng)?shù)墓浪恪⒂媱澓涂刂?。新建系統(tǒng)早期的功能規(guī)模估算可以采用類比法。
在團隊級別，可以選擇軟件功能規(guī)模測量標(biāo)準(zhǔn)或繼續(xù)使用現(xiàn)有的故事點。對于敏捷團隊來說，多種方法的組合可能是最成功和最可接受的。例如：
●使用標(biāo)準(zhǔn)的軟件功能規(guī)模測量方法評估整體系統(tǒng)，有助于目標(biāo)項目規(guī)劃和資源分配；
●在回顧期間（或者在每月一次的DevOps環(huán)境中）,使用標(biāo)準(zhǔn)的軟件功能規(guī)模測量方法,在發(fā)布或迭代級別評估已交付或完成的規(guī)模以評價團隊績效，并為未來的評估需求積累歷史數(shù)據(jù)；
●允許團隊使用已經(jīng)建立的敏捷過程來進行短期的（迭代）工作評估，例如 “規(guī)劃撲克”估算故事點。
一些組織已經(jīng)開始使用軟件功能規(guī)模測量標(biāo)準(zhǔn)方法來評估已交付的軟件，并評估從單個用戶故事一直到迭代或發(fā)布級別的整個可交付成果。每個組織都應(yīng)該選擇自己認為最適合的方法來度量團隊層面的用戶故事（故事點或功能點）。
3.3 使用功能規(guī)模估算
在評估系統(tǒng)、發(fā)布或迭代級別的工作量時，首先需要在該級別上評估要交付的軟件產(chǎn)品規(guī)模，并結(jié)合同一級別的以前交付的相似軟件的“實際”生產(chǎn)率（而不是“速度”）數(shù)據(jù)。
建立這些評估過程應(yīng)謹慎,特別是以下幾點：
●通過測算大量具有共同特征的歷史開發(fā)項目的規(guī)模和工作量來建立規(guī)模/工作量模型。雖然生產(chǎn)率數(shù)據(jù)可以從外部基準(zhǔn)測試服務(wù)中獲得，但我們建議每個組織收集自己的歷史數(shù)據(jù)，因為敏捷活動中有很多變量會影響生產(chǎn)率；
●在項目早期評估新建系統(tǒng)的規(guī)模，可以使用標(biāo)準(zhǔn)的軟件功能規(guī)模測量方法；
●在項目早期，當(dāng)軟件需求不明確時，可通過類比法和專家判斷進行評估，但估算結(jié)果仍然需要保持相同的度量單位。
3.4 在敏捷合同中使用軟件規(guī)模度量
當(dāng)客戶和供應(yīng)商存在合同關(guān)系時,具有敏捷開發(fā)能力的供應(yīng)商通常會主張簽訂基于時間和材料 (T&M)的合同。供應(yīng)商的理由可能是，如果客戶希望在需求明確之前就開始敏捷開發(fā)，那么投標(biāo)價格除了包含不同級別開發(fā)人員薪資外，就沒有其他任何可參考的信息了。
然而純粹的T&M合同是極不平衡的。一份T&M合同對供應(yīng)商來說是100%安全的——無論交付什么都能得到報酬——但留給客戶的只有通過總預(yù)算來控制成本?？蛻魶]有管理機制來判斷付款進度、供應(yīng)商績效以及供應(yīng)商的服務(wù)是否物有所值。
一種有助于平衡客戶和供應(yīng)商之間談判優(yōu)勢的解決方案就是根據(jù)“價格/單位規(guī)模”來簽訂合同,其中交付(或開發(fā)) 的功能規(guī)?？捎脴?biāo)準(zhǔn)的軟件功能規(guī)模測量方法來評估。然后客戶在其需求的總規(guī)模上承擔(dān)風(fēng)險；供應(yīng)商承擔(dān)報價單價的風(fēng)險。此外，客戶也必須在供應(yīng)商合理地給出單價之前明確相關(guān)要求，并確保交付的功能可以轉(zhuǎn)化為業(yè)務(wù)價值（只有在使用該功能時才可能實現(xiàn)）。最終，雙方需要就“完成”的功能何時可以度量和結(jié)算達成一致。
4、標(biāo)準(zhǔn)化的軟件規(guī)模度量方法
很明顯,自組織敏捷團隊的價值觀與更高管理者的價值觀和合理控制需求之間存在著“文化沖突”。因此，如果管理層希望在現(xiàn)有的敏捷開發(fā)團隊中引入一種標(biāo)準(zhǔn)化的軟件功能規(guī)模測量方法，就必須仔細考慮敏捷文化，以免破壞團隊，喪失敏捷開發(fā)帶來的好處。
最重要的問題是什么時候度量（見上文3.2）以及由誰來度量。“誰”這個問題的答案取決于組織的規(guī)模以及客戶和敏捷團隊之間的關(guān)系（合同或非正式的）。
實際上，團隊?wèi)?yīng)該自我度量，并將軟件規(guī)模度量視為對敏捷過程不可或缺的幫助，而不是額外的任務(wù)。（經(jīng)驗發(fā)現(xiàn)，使用標(biāo)準(zhǔn)化軟件規(guī)模度量方法可以有效保障需求的質(zhì)量和完整性。）
在項目早期，大型組織在發(fā)布開發(fā)計劃或簽署合同時引入軟件規(guī)模度量方法，組建度量專家小組是非常有益的，比如：
●內(nèi)部：項目管理辦公室；
●外部：提供功能規(guī)模度量服務(wù)的外部專家供應(yīng)商。
成立度量專家組的優(yōu)勢在于其度量的客觀性、準(zhǔn)確性和效率。
組織無論采用哪種解決方案，定期收集度量數(shù)據(jù)并作為組織學(xué)習(xí)的基礎(chǔ)都是至關(guān)重要的。
至于如何向缺乏這些方法經(jīng)驗的組織引入軟件規(guī)模度量方法，以“自底向上”的方式進行肯定是更好的。換句話說，在一個試點項目中，首先在團隊層面引入軟件規(guī)模度量方法，當(dāng)獲得滿意的結(jié)果并且組織獲得信心時，再橫向擴展然后向上（到發(fā)布和系統(tǒng)級別）。
5、總結(jié)：功能點與故事點對比
6、結(jié)論
設(shè)定目標(biāo)和預(yù)算并據(jù)此進行績效評價是每個組織的標(biāo)準(zhǔn)做法。本文并不是把敏捷軟件開發(fā)活動排除在這些標(biāo)準(zhǔn)的業(yè)務(wù)實踐之外。
“故事點”對于控制或評估單個團隊以上級別的敏捷活動幾乎沒有幫助。而功能點方法可以很容易在更高級別上替代故事點，而且不會對敏捷過程的價值產(chǎn)生任何負面影響。在單個用戶故事和迭代的層面上，每個組織可以自行決定是使用標(biāo)準(zhǔn)化的軟件規(guī)模度量方法或故事點進行短期評估。
在已建立的敏捷開發(fā)的團隊中引入標(biāo)準(zhǔn)功能點法應(yīng)謹慎處理。本文旨在不破壞敏捷文化的前提下，讓組織相信使用客觀控制和度量方法的好處，同時也不會失去敏捷在交付軟件時的速度和靈活性。（本文由北京中基數(shù)聯(lián)科技有限公司翻譯，僅供學(xué)習(xí)參考使用，版權(quán)歸原作者所有，轉(zhuǎn)載請標(biāo)明出處。若有侵權(quán)請聯(lián)系我們刪除。本文內(nèi)容原文鏈接：https://www.isbsg.org/2021/10/18/2021-it-confidence-conference/）
以上就是軟件造價評估公司中基數(shù)聯(lián)為您帶來的“使用功能點法管理敏捷活動”所有內(nèi)容，更多軟件開發(fā)成本估算知識敬請關(guān)注中基數(shù)聯(lián)！
