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