無論你在技術領域工作多久，在某個時候你都可能遇到過比原計划更大、更復雜的項目：規格改變，新需求增加，你的工作量增加，團隊面臨更大的壓力以滿足最后期限。
這種現象被稱為“范圍蔓延”，它是所有相關人員的禍根，從項目經理到開發人員以及中間的每個人。
盡管人們對這個問題的認識有所提高，而且敏捷和 Scrum等現代流程旨在更好地管理變更，但范圍蔓延仍然普遍存在。根據PMI 2018 年的項目管理調查，52% 的項目經歷了范圍蔓延，比五年前增加了近 10%。
范圍蔓延是如何發生的，如何更好地管理它？讓我們來研究一下這個問題。
什么導致范圍蠕變？
當項目范圍發生不受控制的變化而沒有調整時間、成本和資源時，就會發生范圍蔓延。通俗地說：您無需額外時間或幫助即可完成更多工作。
很多時候，范圍會因為新需求的增加、客戶或市場需求的變化或技術的變化而發生變化。但通常情況下，規划階段缺乏明確性。事實上，明確范圍是企業組織中項目經理面臨的最大挑戰。
“當組織領導者不允許進行充分的預先規划時，范圍蔓延往往會發生，”項目管理研究所網絡項目主任斯蒂芬湯森德說。“因為人們傾向於盡快開始工作，所以計划期可能會縮短。因此，本應在流程早期確定的事情將在后續過程中被進一步了解。嘗試適應小的變化作為一次性可能一開始可能會奏效，但一系列一次性可能會迅速導致進度延遲和成本超支。”
敏捷並非對問題免疫
雖然在傳統的開發結構中可能很容易看到范圍蔓延是如何發生的，但它在敏捷開發中不應該是一個問題。還是應該？敏捷旨在擁抱變化並為不同沖刺中的范圍調整留出空間。盡管如此，有些人認為盡管采取了這些步驟，但仍可能出現范圍蔓延。
“你會聽到很多人說你不能在敏捷中進行范圍蔓延，但在我看來，這不是一個准確的說法，”Dataprise 的網絡解決方案主管 Nick McConnell 說。“是的，敏捷允許你在游戲后期引入新的需求以及換入和換出的能力，但是很多時候你會在項目后期和已經開發的東西中出現，有人會進來並想要添加新的需求或者想要完全替換它。
“因此，即使您對在早期周期中開發的東西采用了敏捷方法，您仍然可以通過在游戲后期進行接觸來注入范圍蠕變。”
McConnell 補充說，當一個較小的故事被一個更大的故事取代時，敏捷中也會發生范圍蔓延，這會影響預算和時間表。
變更管理是關鍵
你不能總是防止范圍蔓延，但你可以減輕它。它從全面的前期規划開始。您可以在時間表和應急基金中留出一些余地，以應對需求變化。但擁有變更管理流程也很重要。
“對於更重大的變更，團隊應該使用正式的變更控制流程，讓執行領導參與批准新要求和交付它們所需的資源
采取小步驟控制范圍
管理范圍的另一種方法是將項目分成更小的塊，這樣可以采用更集中的方法。雖然這是敏捷開發基礎的一部分，但它也可以應用於瀑布方法。
“與其嘗試做一個包羅萬象的項目，不如逐步淘汰它並進行非常高水平的第一階段，這實際上是發現階段，真正了解組織和業務以及一些預先確定他們的痛點，並為功能和特性制定路線圖，然后您可以根據時間表和預算進行適當的優先排序，”麥康奈爾說。
自下而上的溝通
雖然項目經理或Scrum Master 負責管理范圍蔓延，但負擔並不僅僅落在他或她的肩上。團隊成員通常首先注意到范圍蔓延。
最終，您可能無法防止每個項目的范圍蔓延，但適當的規划、戰略和溝通可以將其最小化。無論您的角色是什么，您都可以幫助控制它。
傳統與敏捷的范圍觀
傳統的瀑布方法建立在時間、成本和范圍三重約束的基礎上。調整這些變量中的任何一個都會迫使至少一個其他變量發生變化。交付一個成功的項目取決於平衡這三個相互競爭的變量。但正如我們所知，簡單地向項目添加資源並不總能帶來預期的目標。如果在軟件項目中后期添加資源，則會產生不利影響。
敏捷方法通過顛倒三重約束采取不同的方法。敏捷方法不是在開始時將范圍視為固定的，而是將時間（迭代）和成本（團隊成員）設置為固定的；然后調整范圍以側重於最高優先事項。敏捷是在預期范圍會演變的情況下構建的。目標是在預算成本和時間內滿足客戶最重要的要求。隨着項目的推進，敏捷允許新的需求或重新確定優先級。
