重點摘要#
- 軟體與傳統工程產品不同，它並非真正存在於物理世界中
- 不能用建造橋樑的方式來管理軟體專案，因為軟體的需求和環境持續變動
- 軟體的「柔軟」本質既是優勢也是風險——可以靈活調整，但也容易被過度變更
- 需求文件不是藍圖，要做好隨時調整計畫的準備
詳細內容#
軟體工程經常被拿來與土木工程等成熟學科做類比，但這些類比存在根本問題。與這些傳統學科所創造的有形產品不同，軟體並不真正存在——至少不是以傳統意義存在。在 0 和 1 的世界中，我們不受制於經典工程範式背後的物理定律。
軟體與傳統工程的差異#
商業和軟體都是活的、持續變動的實體。商業需求會因為併購、行銷策略等因素快速變化。這使得用傳統工程方式來處理軟體專案非常不切實際：
- 你幾乎不可能被要求在建造到一半時移動一座橋的位置
- 但因為商業夥伴的併購，你很可能被要求為應用程式增加組織內容管理功能
實體工程採用「計劃工作、按計劃執行」（plan the work, work the plan）的方式。軟體則更適合「計劃工作、調整計劃」（plan the work, massage the plan）的方式。
靈活性的雙面刃#
軟體的靈活性也帶來了好處——你可以不按照特定順序來建造系統的各個組件，優先處理高風險的部分。這與橋樑建設中嚴格的施工順序形成鮮明對比。
然而，這種靈活性也帶來了問題：
- 架構師天生喜歡解決問題，容易過度迎合變更需求
- 業務方隱約知道軟體的「柔軟」本質，因此容易推動大幅變更
- 不要因為喜歡提供解決方案就輕易接受大型架構變更，這種決策可能摧毀一個健康的專案
不要因為軟體的靈活本質就輕易接受大規模架構變更。雖然軟體比實體建設更容易改變，但不表示所有改變都是免費的。
正確的心態#
以建造不可移動物體的心態來規劃是可以的——我們只是不能在被要求「移動」時感到驚訝或毫無準備。需求文件不是藍圖，我們創造的虛擬物件比實體產品更容易改變，而這是好事，因為改變的需求會不斷出現。
— By Chad LaVigne