2009-01-15 64 views
10

這將是所有noob問題的noobist,但究竟是什麼範圍蔓延,它是什麼?什麼是Scope Creep?

+0

aka「feeping creaturism」。 – 2009-01-15 16:17:15

+0

顯然,我在當前工作中處理每個項目時都完全一樣。謝謝大家的答案。 – 2009-01-16 18:53:31

回答

25

範圍蔓延「是指項目範圍內不受控制的變化,當項目範圍沒有被正確定義,記錄或控制時,就會發生這種現象,通常認爲這是一種負面事件,應該避免。

Source

+0

只是爲了擴大「不受控制的變化」..我覺得它更容易解釋爲「未經批准的變化」。 – 2009-01-16 03:07:24

+0

@Mark Nold的正式批准並不意味着項目的範圍變更得到了管理,即它對成本,質量和時間的影響,與項目目標的一致性,對可行性的影響等都進行了評估。 「受控」意味着變更管理,因此其「不受控制」而不是「未經批准」。 – 2009-01-16 14:00:52

2

當一個項目不斷地變得比原來計劃的更大,更復雜時,因此永遠落後於進度並超出預算。

11

你從一隻老鼠開始,最後得到一頭大象。

換句話說需求的變化每天,你都應該提供看起來並不像什麼應該在項目

1

開始交付任何時候,你開始設置你的項目上有什麼某些參數。這些參數是您的範圍。你應該考慮你的項目應該做什麼,需要花多少錢,以及需要多少時間才能完成。當更多的功能,時間,金錢......進入項目時,這可以稱爲「範圍蠕變」,

7

Wikipedia表達它比我更完全。

+0

+1廚房水槽綜合症。 – 2009-01-15 21:39:41

1

範圍蠕變是指需求不斷修改或添加到當前產品版本時。例如,您向客戶/用戶展示演示,並請求新的報告/按鈕/字段。當開發人員想要添加新的「酷」功能等時,也可能發生這種情況,而不需要它們。最好通過管理項目發佈週期來預防。建議功能的人是件好事,但參與其中的每個人都需要了解對項目和預算的影響。考慮將新功能請求添加到列表中並定期開會以決定將哪些新功能添加到「下一個版本」。

1

在我看來,功能蠕變的情況下,需要有一個元素促成產品的崩潰。例如,一個城市的發展是好的 - 城市蔓延是不好的。

或者在UI設計的情況下,所有相關功能都卡在一個控制屏幕上 - 不斷添加新功能,以至於他們的屏幕出現混淆了更多人,而不是發現有用的功能。

爲了符合特性蠕變的要求,他們應該通過在系統生命週期中導致不必要的複雜性或引發不必要的扳手的測試。不符合該標準的原始計劃外特徵不應該被認爲是特徵性的蠕變。

範圍蔓延在相同的光的功能蔓延只的產品範圍的水平concidered ...例如:

你的團隊建設「空中吸盤」(TM),它從一個吸入空氣並將其運送到距離兩個街區的工廠。吸盤的範圍是它移動空氣。

然後管理實現吸吮器還需要吸水運沙。 Air Sucker從未設計用於運輸液體或顆粒材料,因此將吸盤的範圍擴大到必須重新設計以滿足新的運輸要求的程度。

1

如果您有適當的更改控制,可能是搖錢樹。

有一個有力的小船有一個小輕便小拖車着名的圖片。該汽艇被稱爲「原始合同」,電力船被稱爲「變更請求」

1

功能,預算,時間表:選擇任何2,但不是所有的3

4

有針對的範圍蔓延兩個定義。

  • 否定的。以不受控制的方式改變範圍增加成本和風險。

  • 正面。範圍以不受控制的方式變化,因爲我們的幻想項目計劃是錯誤的,我們開始學習我們不期望學習的東西。

大多數人似乎喜歡第一個。

然而第二個更準確。少數認識到範圍蔓延的經理 - ==學習能夠明智地管理並完成任務。

其他管理人員將不受控制的學習視爲威脅。該項目不會在幻想時間表或預算中創建希望達成的交付物。這意味着需要縮小範圍或擴大預算。

請注意,大多數敏捷方法似乎並不在乎範圍或範圍蔓延。由於對下一個版本的關注不多,整體情況變得不那麼具有威脅性和可怕性。

學習 - 在敏捷的背景下 - 也導致範圍蔓延,但這是一件好事。永遠不會有用的東西被推遲。當我們開始時看起來並不重要的東西變得加速。

1

範圍蠕變是對最初商定的規範/項目範圍/定義的任何更改。這種變化可能是由於發現了先前的未知因素,內部/外部市場的變化,技術變化或計劃的贊助商想要更多的東西。當沒有變更控制流程來審查和接受或拒絕變更時,它會對項目產生負面影響。

1

範圍蠕變如何影響產品進度? 有沒有辦法讓範圍從你的開發過程中消失? 你的PM如何處理範圍蠕變? 什麼是從範圍蠕變出來的最好功能? 等等

1

範圍蔓延就像色情:你知道它,當你看到它。

相關問題