從Reifer的“敏捷方法定量分析”研究中學到的十個知識點

　　

I 敏捷方法的十個知識點

　　Reifer咨詢有限責任公司發表了一份名為敏捷方法定量分析的基准報告這份報告比較了敏捷方法軟件生產率成本持續時間和質量與傳統的計劃驅動項目的差異這份報告分析了個項目（其中有個敏捷項目）的工作數據跨越年使用了由個組織提供的完整工作數據

　　讀者可以在我們的敏捷研究中找到以下十個知識點我們所參考的基准報告中記錄了相關研究成果這份報告目前售價美元可在此訂購點擊這裡可以詳細了解國際軟件基准組織

　　 敏捷生產率——敏捷生產率（以產出/單元投入成本進行度量）高於已交付產品的由計劃驅動的項目的經驗基准該經驗基准取自年中在名義值上下浮動%的數據采用敏捷後一年內生產率平均最多能提升%到%但是這些提升取決於應用的領域並且受許多因素的影響（如勞動力構成結構產品復雜度項目規模等等）例如有一些項目需要通過認證的形式（比如飛行安全和安全認證等）這些項目看起來就不太適用於敏捷方法Capers Jones的數據證實了我們提出的觀點此類項目使用像RUP（統一軟件開發過程）和TSP（團隊軟件過程）之類的結構化過程可以更快地通過認證

　　驅動因子改善團隊工作使用輕量級過程重點關注產品可執行的代碼和潛在的霍索恩效應

　　問題開發維護或組織問題過程僵化和教條過於嚴格的管理外包問題缺少產品管理的核心

　　應對措施我們提出以下幾個提升敏捷生產率的建議

　　

• 　　理解影響生產率的變數（架構穩定性產品復雜度員工技能水平和經驗等）當你轉用敏捷時要處理好這些變數

• 　　收集生產率測量和度量結果這些數據有助於我們做必要的調整

• 　　改革時難免會遇到阻力建議先運行試點項目收集這些項目的度量和測量數據用這些數據說明敏捷是一種更好的商業運作方式

• 　　在試點項目中調整過程和敏捷方法找出達成商業目標的最佳方法

• 　　如果條件允許的話最好讓大家在一起工作以避免在第一個項目中就出現管理和合同上面的問題

• 　　使敏捷重點關注能夠帶來差異化的那些應用的開發

• 　　星星之火可以燎原敏捷的一次成功可以帶來更多的成功

　　 敏捷成本——敏捷成本（以開銷/單元產出進行度量）低於以計劃驅動項目的經驗基准該經驗基准范圍取自年間在名義值上下浮動%的數據采用敏捷後一年內平均最多能降低%到%的成本同樣這種成本變化在很大程度上也取決於所在的應用領域並且受許多因素（包括勞動力構成結構和工資水平）的影響

　　驅動因子降低人工費用率降低管理費用簡化溝通機制更加關注產品而不是過程

　　問題更重視開發而非規避維護成本機構重組和角色澄清僵化的過程治理過於嚴格外包問題以及不重視產品的管理

　　應對措施我們提出以下幾個降低敏捷成本的建議

• 　　理解影響成本的變數（這些變數與生產率有所不同）轉用敏捷時要處理好這些變數

• 　　基於事實做項目估算（通常所有sprints估算的交付物之和少於最終產品應有的交付物）

• 　　監控項目成本跟蹤預算開支

• 　　重視敏捷教育和培訓的早期投入

• 　　在工作開展之前選購適當的工具並設置適當的運作機制（戰情室任務板等）

• 　　轉用敏捷時應該盡可能遵循節儉和簡單的原則

　　 敏捷上市時間——敏捷上市時間（度量軟件從開始到最終交付的總體有效時間）比計劃驅動項目的經驗基准要短%到%在采用敏捷之後平均最多能縮短%到%（不同項目規模會有所差異）但需要注意的是一味地想要加速交付周期常常會遺漏一些需求使交付的功能和特性無法完全滿足客戶或用戶需求從而降低了客戶滿意度

　　驅動因子關注正在開發的工件在sprints期內快速開發在最終投入市場之前增量交付演示版本

　　問題sprints期內未能完成所有工作承諾待辦任務未能清空客戶或用戶可能沒有成為團隊成員管理者可能沒參加到敏捷工作中來

　　應對措施我們提出以下幾個縮短敏捷上市時間的建議

• 　　理解影響上市時間的變數轉用敏捷時要處理好這些變數

• 　　充分考慮環境因素把項目作為整體制定務實的時間估算然後再調整sprint和增量計劃

• 　　在項目開發過程中監控裡程碑達成情況

• 　　讓團隊控制sprint時間線

• 　　設立對增量時間線和內容的期望

• 　　堅持在每個增量結束時演示工件並爭取讓客戶或用戶市場人員和管理者都參加

　　 敏捷質量——敏捷質量（以發布後的缺陷密度進行度量）比計劃驅動項目的經驗基准要高%到%交付後的質量甚至能高出%到%同樣質量取決於應用的領域並受許多因素的影響其中包括質量控制和質保實踐

　　驅動因子過程監督執行不利過多地強調測試而沒有做整體項目的質量保證沒有產品質量目標在設計產品時未考慮質量缺少指導決策的質量文化

　　問題在敏捷初期沒有強調質量就急著直接編碼把測試視為質量保證不執行質量控制不收集質量指標不應用成熟的質量控制和質保實踐

　　應對措施我們提出以下幾個提升敏捷質量的建議

• 　　把發布速度優先的文化轉變為質量優先的文化

• 　　擁抱質量讓它成為所有工作過程中的一部分還需支持同行評審在每日站會上討論質量從版本控制資源庫中收集缺陷信息在任務板和版本狀態報告中展示這些缺陷

• 　　讓每個團隊成員互相檢查彼此間產品的質量可以舉辦一個競賽為了使活動更有趣味性可以為做得好的成員頒發獎品和獎狀

• 　　記錄質量度量和測量結果不論是軟件開發期還是軟件維護期都可以用這些指標量化產品的質量

• 　　經常分析質量問題的根本原因不要只關注問題的表面症狀還要關注導致缺陷的原因

• 　　永遠不要發布很可能有缺陷的產品當質量和發布速度產生沖突時應該堅持原則說到做到勇於承擔責任

• 　　使用精益和看板法原則能讓我們隨著產品開發過程關注工程質量在sprint期找出缺陷並修復它們或者把它們放到待辦工作中隨後解決

　　 敏捷的競爭優勢——敏捷最具競爭性的優勢在於它能讓組織發揮優勢改進不足使用敏捷不僅可以提高生產力降低成本加速上市時間它還能幫我們吸引和留住人才這些人才是智力成本能讓我們在競爭激烈的市場中脫穎而出但是有些應用領域不要使用敏捷方法敏捷在這些領域起不到應有的作用也沒有什麼意義比如需要認證資質的應用以及大型的分布式的復雜的開發等

　　驅動因子敏捷已經被過度誇大和使用任何新鮮事物都會被質疑許多公司並不把軟件作為競爭格局的一部分（例如軟件只是輔助性服務而不是創收的生產活動）

　　問題既要了解敏捷的優點也要了解敏捷的缺點采用敏捷需要做出一定的組織變更（比如一些新的角色和職責）對於組織來說轉用敏捷像采用別的新做法一樣充滿風險

　　應對措施我們提出以下幾個更能發揮敏捷優勢的建議

• 　　變更組織結構把敏捷融入到組織的主要流程裡

• 　　通過崗位職責說明書明確定義敏捷職位說明角色和團隊的概念然後為崗位配備工作人員雇用敏捷教練對這些工作人員進行指導和培訓

• 　　自上而下地轉變文化由領導命令驅動的風格轉變為自組織分享式團隊至少要讓你的軟件組織轉用敏捷

• 　　完善必要的治理使合規性保證不再依賴於上級或外部的監督讓敏捷團隊獨立自主即使需求超出了范圍也要相信他們可以應對但是當度量和其他指標顯示工作進展滯澀時你就需要監控他們的工作並幫他們做些調整了

• 　　爭取達成商業目標比如先完成優先級高的任務而不要把主要精力都放在那些即將要交付產品的項目上這種做法雖然可以滿足一個客戶（或用戶）但卻犧牲了其他的客戶（或用戶）

• 　　盡量讓事情簡單從產品架構到軟件產品本身都要遵循這一原則此外還可以把這一原則延伸到組織結構上承擔交付責任的組織也要盡可能地簡單

• 　　將組織重心從實現單獨的目標（按計劃執行分派的任務等）轉變成通過團隊協作為組織及其客戶提供價值把重點放在產出的工作產品上

• 　　營造一種鼓勵嘗試的文化無論嘗試的結果是成功還是失敗鼓勵那些勇於做決策冒風險努力去解決問題的人

• 　　當結果可以預測但沒有十足把握時由團隊自己做出決策

• 　　盡量創建更好的商業模式為個人企業和客戶提供更好的工作環境

　　 具有一定規模的敏捷——一直以來在大型項目中都難以應用敏捷方法基於我們的數據分析（個不同組織的個項目其中有很多已經使用了多年的敏捷）敏捷不適用於大型復雜項目雖然有一些大型項目也使用敏捷取得過一些顯著的成就但由於缺乏針對大型項目的體系和指南軟件工程實踐者需要面對很多不利條件從我們收集的數據來看當項目員工總數超過人而且他們處於不同的地理位置分屬多個民族時應用敏捷方法的工作效果是達不到平均值的另外從我們和Capers Jones的數據來看當用戶和客戶總數超過時敏捷就會出現問題因為大家對系統願景有著各自不同的理解或許造成這種局面的根本原因就是大多數大型項目並不直接面對用戶這與敏捷是有所背離的反之這些項目在真正投入使用之前要先交付給一些集成和測試組經歷各種嚴格的系統測試（性能可用性等）

　　驅動因子敏捷實踐在大多數情況下只適用於小型團隊和項目雖然也有人提出過一些針對一定規模項目的敏捷方法但由於它們並未重視和應用傳統的項目管理技術我們並不太認可這些方法此外正如前文所說敏捷項目應快速交付給客戶或用戶但大型系統要先經過系統集成和測試後才能交付使用

　　問題無法協調監控跟蹤和調整分散在不同地域不同團隊的開發人員無法跟蹤產品業績和裡程碑完成情況流程不當無法滿足客戶期望

　　應對措施針對大型項目的敏捷應用我們提出以下幾個建議

　　

• 　　借鑒敏捷的觀念通過建立自組織分享式團隊突破組織級障礙例如因為做計劃管理時矩陣式管理方式會產生很多沖突所以應捨棄這種方式

• 　　在具有一定規模的敏捷項目中你可以繼續沿用傳統的項目管理計劃日程安排和控制的概念用它們設定目標和跟蹤業績你們在項目運行過程中可以使用傳統方法在sprints運行過程中可以使用敏捷技術

• 　　不要讓敏捷組織和團隊成為特例而要讓它們成為常態並使它們能夠面對更多的客戶和用戶處理一定規模的問題這些正是傳統大型項目（比如通信項目）所要解決的問題

• 　　為團隊提供了推薦的大規模敏捷項目管理體系和指南

• 　　在軟件開發過程中做每件事都需要兼顧敏捷性和紀律性

• 　　針對敏捷確立系統工程並請客戶當測試代表除此之外內部討論時也不要忘了系統實際的用戶客戶或甲方因為最終完工交付的時候是由他們評判特性功能和性能是否達到要求

• 　　為了確定迭代項目和組織等各個級別開發基線的程度你需要定義並執行度量和測量

• 　　找出指南中不適用的過程和問題並完善它們特別要注意那些用於配置管理發布管理質量控制（或保證）和供應商管理的敏捷實踐

　　 敏捷系統工程——你需要更新系統工程實踐以提升敏捷化程度否則因為不適用的過程會使組織產生很多沖突舉個例子因為系統工程師開發系統需求並把它們從硬件到軟件進行逐層定位所以應隨著軟件開發過程同步開發系統需求未來的發展趨勢是系統扮演客戶但如果不暴露出各種操作角色就無法達成這樣的目標再舉一個例子由於架構是軟件運行的平台所以在過程初期應該擁有穩定的系統架構

　　系統工程經常無法做到這一點即便他們采納了軟件工程師針對面向特性和即插即用功能的建議最後再舉一個例子通常情況下測試工程師也隸屬於軟件工程師為了確保增量開發出的系統能夠滿足需求需要他們支持持續集成和測試的理念不幸的是系統工程師不接受這種按待辦任務交付的方式因為他通常都認為每次增量之間要交付的內容是不能延遲的為了集成和測試系統中的軟件部分測試工程師還需要與軟件團隊一起定置相應的機制和工具有時系統在交付使用之前需要讓實際用戶（或系統操作人員）用真實的設備先予以驗證

　　驅動因子過於嚴謹和理論化的系統工程孤立的系統軟件文化和過程缺乏真正的跨領域的和整體團隊的概念

　　問題太晚提供軟件需求未定義系統接口直到編程末期才開始關注系統測試而在初期根本就沒有關注系統測試和集成的機制建立得太晚系統和軟件過程不匹配缺乏跨領域團隊協作缺乏其他領域體制的尊重發生系統工程故障時互相推诿

　　應對措施我們提出以下能夠改善敏捷系統工程的幾個建議

• 　　邀請客戶或用戶代表參與到團隊中來作為團隊成員與大家在一起工作

• 　　真正擁抱整體產品團隊或跨領域團隊的概念平等對待團隊中的每一個成員讓客戶或用戶代表參與到團隊中成為團隊成員

• 　　引領工程改進而不要反被其制約

• 　　不僅僅讓系統硬件和軟件支持敏捷宣言還要讓工程支持敏捷宣言

• 　　嫁接所有的工程和制造過程使工作切換同步簡單

• 　　制定一個單一的基於敏捷的工程過程勝過讓每個獨立的領域（系統軟件硬件特定工程等）都有各自的過程

• 　　在過程早期專注於開發客戶需要的工件勝過專注於那些獨特的工程理論

• 　　抱著探險家的心態去挖掘需求勝過僅僅遵循規范的過程

• 　　在整個開發過程中把重點放在開發工作產品上勝過那些面面俱到的有些官僚主義的文檔

• 　　擁抱持續集成實踐使它成為所有工程的統一框架

• 　　集成還有一個好處它簡化了完備的系統為團隊提供了一套簡單的模型使團隊清晰哪些已經構建哪些已經准備測試了哪些正在測試哪些已經可以投入使用了

• 　　可以定義同步點在適當的時間集成半成品以處理過程中必要的同步

　　 敏捷軟件維護——敏捷是否適用於軟件維護？評審委員會還沒有給出最後的定論本階段的開發使用敏捷方法有哪些利弊？我們可以從Reifer咨詢公司近期針對軟件維護的研究成果中找到一些答案本次研究發現由開發期的預算和進度計劃是由需求驅動的會有較大差異而用於軟件維護任務的資源較為固定所以軟件維護團隊的一項很重要的任務就是充分考慮工作（修復變更更新優化等）的優先級使他們能在固定的預算下盡可能完成更多的工作其實完成那些積累下來的變更申請和待處理的故障報告只是他們最基本的工作任務

　　本次研究還發現同一個團隊要並行完成以下四種版本的開發任務

• 　　當前版本——維護團隊的主要任務是開發新的版本通過升級代碼為客戶完成需求變更問題修復和性能優化

• 　　現場版本——維護團隊的首要任務支持現場版本為保障系統運維執行必要的修復和補丁

• 　　完整版本——維護團隊的次要任務配置和定制近期的完整版並發布到各個現場他們的工作內容包括做更多的測試和協調各個現場

• 　　需求版本——維護團隊的次要任務目標是開發下個版本的內容（舉例來說必要時要開發原型去界定需求范圍）

　　為了在軟件維護期能夠更好地執行敏捷方法必須讓敏捷方法能夠處理以上四種版本的相關工作我們的研究表明與軟件開發期相比這些工作環節的組成和分布均有所不同例如這類工作在很多時候要用回歸測試的方式驗證最新的版本變更另外這類工作可能需要現場支持和運行測試的參與

　　驅動因子不清楚維護期的工作性質當計劃內的任務和緊急任務產生沖突時不清楚怎麼為維護活動或設施做預算才能更合理地完成功能增強問題修復性能優化等任務

　　問題分不清做的是軟件開發項目還是維護項目不適用於維護的過程或預算預算不足導致工作積壓每次變更都要重新驗證版本產品分布式管理的問題和缺乏產品管理規范

　　應對措施我們針對軟件維護期的敏捷提出以下幾個建議

• 　　考慮如何讓敏捷方法適用於上述四種版本的所有相關工作討論在軟件維護階段需要做哪些工作

• 　　提供一份指南解釋在上述四種版本的開發過程中如何應用敏捷技術和實踐例如如何讓sprint不僅能為完整版本引來價值還要在當下產生價值

• 　　軟件維護工作主要是保障系統的運行甚至可能要在現場做功能增強問題修復和性能優化你需要確定這些工作的優先級

• 　　設計適當的支撐架構（例如針對所有項目的配置分布質量供應商和風險管理實踐）在軟件維護期內使不同的設備上的不同軟件都能保持最新的發布即使它們是不同的版本和遺留系統

• 　　清楚維護設備和客戶支持職能需要單獨做預算你們在預算時要基於待辦任務中涉及的所有工作量而不僅僅是單獨的工程在協調計劃和員工時要充分考慮這些工作

• 　　持續擁抱持續集成和自動化回歸測試的實踐因為在維護期投入到驗證版本變更的測試工作量要占到總工作量的%這些活動能產生巨大的影響

• 　　堅持過程規范特別是處理多樣的發布客戶和產品版本時一旦放松就可能釀成大禍

　　 敏捷風險管理——你們必須要擁抱敏捷風險管理實踐特別是面向更具規模更加復雜的敏捷項目時雖然有一些現有的技術可以用來做敏捷風險管理（比如風險燃盡表）但在我們的數據中卻很少有組織使用過這些技術按我們通常的理解這些技術可能更適用於國防和通訊領域

　　驅動因子把風險管理看成重量級過程團隊領導並不把它當成項目管理（比方說沒有風險管理任務）缺少項目管理規范和實踐（特別是具有一定規模的敏捷項目）

　　問題移除在預算內按時交付高質量產品的不利因素盡可能地滿足客戶的預期提升識別風險和緩解風險的能力

　　應對措施我們提出以下幾個加強敏捷風險管理的建議

• 　　把敏捷風險管理實踐實際開展起來讓團隊管理者客戶用戶共同參與風險的識別量化排序和緩解

• 　　制定前十風險列表把它們放在任務板上在站立會和分派任務時掌控它們的狀態

• 　　按潛在的技術和編程影響排出前十風險列表使用類似風險燃盡表之類的技術去跟蹤這些風險的緩解過程

• 　　讓客戶或用戶參與到風險管理過程中讓他（她）們根據你評估的影響為風險排出優先級創建類似於風險委員會的組織讓大家就風險優先級達成共識

• 　　當風險合理存在並且不會造成嚴重後果時可以冒這個險

• 　　鼓勵冒險當你覺得有必要冒險並能夠最小化和控制冒險帶來的潛在後果時你就可以鼓勵冒險

　　敏捷外包——我們需要精確的敏捷外包實踐目前合同管理員和甲方並不清楚如何規定敏捷承包或分包的具體合同類型工作范圍工作狀態交付物裡程碑支付條款和條件我們可以通過這些條款准確地推導出敏捷合同中要使用的時間和資源而不是為了鼓勵組織高效地工作籠統地制定激勵措施

　　驅動因子敏捷是一個相對較新的商業模式幾乎沒有公司做過涉及到采購方的敏捷在實際工作中也沒有多少可供參考的合同樣本

　　問題缺乏針對工作效率的激勵和鼓勵機制沒有合約性的控制與保障措施甲方覺得敏捷無法控制所以不想采用

　　應對措施我們針對敏捷外包提出以下幾個建議

• 　　制定一套合同模版軟件甲方可以用它擬定會用到敏捷方法的軟件開發承包或分包識別裡程碑和交付物並在合同中規定如何鼓勵效率提升（比如激勵措施等）如何處理違規（比如撤銷條款等）

• 　　制定一份敏捷承包或分包樣本為敏捷采購提供一套有理有據的條款和條件（包括支付條件和裡程碑）

• 　　為了描述交付物的形式和格式制定一套交付物模版盡量提供電子文檔而不要到供應商的辦公室去拿紙制的文件

• 　　制定一份法律模版使客戶（或用戶）代表根據有限責任保護傘條款作為成員參與到開發團隊中

• 　　為甲方和合同管理員制定敏捷承包或分包的培訓和認證課程使大家在工作時能夠擁抱這些概念

II 主要研究成果

　　因為對於大多數調查過的組織來說敏捷方法是一種全新的商業模式所以在前文討論了大家比較感興趣的知識點很明顯還有許多問題（比如敏捷外包一定規模的敏捷等）一直困擾著組織仍然需要一段時間的過渡可能才能解決鑒於現在已經掌握的素材我們整理了以下五個主要研究成果希望在讀者采用敏捷方法時能夠有所幫助

　　

1. 　　敏捷方法最適合用於明確的業務用例在此前提下實施最大的障礙無非就是向新人解釋方法論的用法

2. 　　當你轉用敏捷方法時最主要的是要改變管理原則在過渡時期你需要制定策略落實計劃調整架構培訓員工訓練管理人員還需要運行敏捷試點項目找到如何在你的組織環境組織商業目標組織流程和組織歷史背景下運行敏捷項目的最佳辦法

3. 　　某些類型的軟件開發項目可能不適用敏捷方法前文白皮書中曾經提到那些安全和安保項目可能並不太適用敏捷方法而適用於其他同樣輕量級的方法（比如RUPTSP等等）因為這些項目會涉及到一些認證資質另外如果不解決外包問題就難以在一個采購環境中使用敏捷方法因為不容易界定任務是否實際完成了另外優秀的敏捷專家能幫你做出決策找出適用的方法時機和理由以及對客戶（或用戶）帶來的價值

4. 　　由於組織和流程不匹配缺少項目管理規范一定規模的敏捷項目一直難以運作很難處理組與組之間的控制權沖突為了避免這些問題我們推薦單一的工程原則該原則聚攏受到影響的小組探索真正的跨學科團隊的概念時刻記得通過敏捷思想改進流程充分利用那些傳統項目管理規范（比如項目管理協會在知識體系中[PMBOK]所提倡的那些規范）在這種情況下優秀的管理分析師所擁有的敏捷過程改進以及項目管理的技能知識和能力會帶來一定的幫助如果他具備你所經營行業和應用領域的相關經驗就能帶來更加顯著的幫助了

5. 　　在當前的競爭格局下轉用敏捷方法通常很有意義主要有三點原因首先你可以使用這一套方法論去趕超你的競爭對手他們極有可能已經准備使用敏捷方法了第二你可以使用敏捷方法吸引人才因為高效的人才希望自己的工作環境能夠使用到最新最好的技術第三個也是最後一個原因你可以向客戶展示你使用的敏捷技術向他們說明這就是他們所希望采用的最好的技術

　　你可能想要了解更多關於敏捷的信息比如敏捷的優勢和弱點敏捷投資回報率這十年的動態和我們關於敏捷軟件生產率成本和質量調查研究相關的細節我們建議你從或從這裡訂購敏捷方法定量分析報告這份報告在下列十個應用領域中按行業報告了這些敏捷軟件生產率成本和質量的結果

• 　　自動化

• 　　指揮控制

• 　　金融

• 　　國防

• 　　信息技術

• 　　醫療

• 　　移動應用

• 　　軟件工具

• 　　通信

• 　　電子商務

From:http://tw.wingwit.com/Article/program/Web/201405/30795.html