最後一分鐘範圍更改？當然爲什麼不呢？

Question

有沒有人有他們可以發送有關在軟件版本中引入最新要求或範圍的危險的文章？常識對不對？然而，忽視常識是人的本性。

我有一羣企業利益相關者聲稱在過去的生活中擁有所有這些「IT /軟件工程」經驗，但一再問他們爲什麼不能在UAT期間甚至在UAT之後添加範圍。

Answer 1

並非罕見問題，是的。 :)

我知道COST是固定的，因爲客戶不願意爲附加範圍詢問任何額外費用。那是對的嗎？

如果是這種情況，可能這就是項目文件的「驗收標準」出現的地方。 UAT是否已經簽署？如果是這樣的話，你有更好的例子來把額外的範圍作爲附加項目來增加時間和成本。如果你沒有一個明確的「接受標準」，你需要說服爲什麼這是一個額外的努力。

以上純粹是出於商業和成本的角度考慮。從工程角度來看 - 是的，毫無疑問，由於額外的計劃，測試和「迴歸測試」，所涉及的文檔和交付週期等原因，會帶來額外的開銷。也許會有代碼重構也取決於添加的範圍。 「支持你的觀點，軟件項目中的額外範圍不僅僅是增加一層樓到多層建築，你可以專注於新建的樓層。」也許你會向高級管理層或業務用戶（無論你需要誰）解釋這一點，以便至少在下一次將這些範圍更改最小化。 （請記住，它們只能在現實世界中最小化，不能像理想世界中那樣被廢除）

稍微偏離您的問題，一天結束 - 必須從各個不同的角度查看項目 - 質量，時間和成本，你不能一起滿足所有這些。所以，如果你是一名項目經理，你需要發表你的觀點 - 可能會要求額外的時間或額外的資源，具體情況取決於案例。最好是承擔責任，現在站出來，在範圍和時間上比在項目結束時更加清楚。

如果您需要下次更好地處理它，請查看這些合約模型是否有助於您 - http://www.derailleurconsulting.com/blog/three-contract-models-for-scrum-projects。

話雖如此，我還要承認，作爲一名項目經理，我不得不接受一個有限的額外範圍（無額外費用），我優先考慮「客戶滿意度和客戶保留率」還要別的嗎。一旦客戶與我們建立了長期的合作關係，我們就更容易說服客戶瞭解範圍問題以及如何花費額外的努力等。當天結束時，我們無法擺脫業務規則和這不僅是我們正在解決的工程問題。