在亞洲地區 Scrum 的導入往往會因文化差異和實務需求的衝突而面臨挑戰，而我的專案以機房建置、網路維運為主，具有以下特性：
1. 需求清晰且穩定：專案從招標到執行，需求多已被確認，沒有頻繁變更的空間或必要性。
2. 交付時程緊湊：業主多要求固定的交付日期，若拆分多個 Sprint 無法加快交付速度。
3. 高度依賴實體設備與基礎設施：建置的每一步驟（例如機櫃安裝、配線）都必須按既定順序完成，這是典型的「瀑布式」流程。
以實際情境和成本效益為例，來闡述為什麼 Scrum 不一定適合我們的工作模式？
Scrum的核心價值在於應對變化和快速迭代，但機房並不需要頻繁適應變更，強行導入 Scrum 反而可能拖慢流程。
Scrum 強調「分權式管理」，要求團隊能自行決策並快速調整，但在我們的承攬專案中，這種模式與實際運作需求並不契合！
客戶與高層的強烈控制需求：機房建置涉及高成本設備和精密操作，任何變更都需要客戶與公司高層批准！
Scrum 中的自主管理在這種高度受控的環境下，無法真正實現。
職場文化強調尊重權威和資歷優先，而 Scrum 中的角色（如產品負責人、Scrum Master）對公司團隊來說，容易造成以下問題：
團隊內需增加專職角色（如 Scrum Master），這對於以專案為核心、資源有限的承攬業務來說，是額外負擔。
在團隊內部，工程師可能更傾向聽從業主或前輩，而非Scrum Master的引導，這可能導致 Scrum Master 的職責被弱化，無法真正協助解決問題。
時間表與績效的矛盾
機房維運項目通常有緊湊的時間表和固定的里程碑，例如：某次協助客戶機房改善流程包括空間規劃、電力需求評估、機櫃與網路線的安裝等，每一步都依賴上一個階段的完成。
瀑布式的方式讓每個節點都清楚，工程師只需按照計畫執行，最終準時交付且無返工。
若強行導入 Scrum 的情境：
假設 Sprint 目標是完成「機櫃安裝」的一部分，但電力配線尚未完成或空間評估發現問題，這會導致 Sprint 無法如期達標，還需要重新安排，延誤進度且增加成本。
Scrum需要定期 Sprint Review 和頻繁的 Stakeholder 參與，但高層或客戶是否有時間和意願參與？如果無法得到即時回饋，Scrum 等同於增加無效會議。
責任分配模糊：Scrum 團隊提倡共享責任，但我們的業務模式需要明確的責任歸屬，否則一旦出現問題（例如設備損壞或突發狀況），責任推卸風險會增加。
而一個團隊適不適合敏捷，其實公司文化就能感覺出來，與其扒著 scrum 這個詞不放，如果沒有這樣的需求，Scrum 就是瀑布，因為驗證做完，也沒人給你 feedback，那幹嘛不直接往最終目標瀑布下去就好了？
至於工作能不能開心？主要還是看團隊氛圍，而不是瀑布還是敏捷。
留言列表
