敏捷開發與瀑布式開發成功率對比

根據科技產業研究機構 Standish Group 調

查，Waterfall 的開發方式失敗比例非常

高。大致上會產生兩種改善觀點，其一認為

團隊沒有做好該做的事情、沒有做好計畫、

沒有釐清好需求、在每一個階段沒有做好確

認與驗證。如果你採用了這種觀點，那麼解

決方案就會落入了更要求「把事情做對」

上。把計畫做的更好，增加更多的 Review，

要求更多的文件與簽名，更多的測試人力等

等。但有沒有可能，問題不在於「做的不

好」，而是在於「做事的方法」上？

1985 年出版的「人月神話」是資訊人必讀

的經典書籍。作者將軟體開發的困難性區分

為「本質性」的困難與「附屬性」的困難。

對於軟體「本質性」的困難（複雜性、隱匿

性、配合性、易變性），我們無法只是用要

求更努力「把事情做的更好」的方式來改

善。近代，在軟體技術層面發展了許多更好

的架構設計、Design Pattern、物件導向程式

語言等。這些都能讓軟體更好開發，但卻還

是有很大比例的軟體專案仍舊使用著快 50 年

前提出的 Waterfall 模式。一直到 1990 年代敏

捷開發思維逐漸發展後，對於開發程序才逐

漸有了不同的觀點。與傳統的 Waterfall 的開

發模式相比，敏捷開發是一種應對快速變化

需求的一種軟體開發模式，其中 Scrum 又是

其中最流行的一種方式。

如何利用敏捷開發管理軟體開發的不確定性撰文 | 叡揚資訊 雲端事業處 處長 楊東城

July 2018 | 叡揚e論壇 第90期 | 15

EIS-90.indd 15 2018/7/13 11:17

軟體專案不確定性 從計劃到完成差異 8 倍 由於軟體的「本質性困難」產生了「不確

定角錐」現象。從一開始的計畫，到軟體的完

成，可能有 8 倍的差異存在，不管專案的執行

做的多好，也只有 1/8 機會準時完成專案。所

以與其一開始就追求「完美計畫」，不如採取

「週期性」方式。將原本預計一年才完成的專

案，切割成 2-4 週的週期，在最初的幾個週期

中完成原本計畫中最重要、最有價值、風險最

高的功能項目。

避免專案後期才發現 Bug，或客戶到系統完成

後才知道自己想要的是什麼，讓不確定性風險

縮小。同時，在每個週期最後都可以展示目前

完成內容給客戶看，並計畫下一週期待完成事

項。此過程就像開車，我們不會在一開始就把

方向盤固定在一個方向，而是會根據路上狀況

不斷調整與修正，甚至可能因為路況而決定繞

不同的路，或更甚而調整目的地。

直覺上繞路與調整目

的地都不是一個好的

決定，對專案管理來

說，專案目標是不允

許 變 來 變 去 的 。 傳

統專案管理是希望在

計畫完成後只要照表

操 課 就 能 把 事 情 完

成，追求的是最小變

數，但大部分軟體開

發卻無法如此管理。

Cynefin 框架把問題

分成簡單/繁雜/複雜

/混沌/失序。這五類不取決於問題大小，而是

根據問題不確定性區分。有可能是好幾億的

工程專案，但仍屬於「簡單」的範疇。「簡

單」類的問題存在 Best Practice，只要有專家

制定好 SOP 後，接著就是資源與時間的簡單

計算，也是最容易用機器自動化方式處理的範

疇。

「繁雜」的問題則是不存在一個最佳解，但有

一些 Good Practice 可以參考，經過對問題與分

析調查後可找出可行的解決方案。現在許多想

用 AI 處理的問題就屬於這一類型的，沒有最

好，只有更好。「複雜」的問題則參雜了更多

的不確定性，需要隨著時間反覆探索來找出當

下可行的作法，但隨著時間演進需要不斷調整

做法來面對不確定性。而「混沌」與「失序」

則沒有因果可言，目前也沒有好的建議方法，

這邊不做詳細的介紹，有興趣的朋友可以直接

上網搜尋。

軟體系統分佈

| 叡揚e論壇 第90期 | July 201816

EIS-90.indd 16 2018/7/13 11:17

團隊成員能力與分工

專案週期化 應對快速變化需求、技術及市場

從 Cynefin 框架來看，Waterfall 其實只適用

於簡單類的問題，可根據問題的定義找出最

佳計畫，然後照著執行即可。面對繁雜與複

雜的問題，我們需要用不同方式來處理，

而 Scrum 就是其中一個十分合適的方法。將

計畫切成許多週期，並在每個週期中不斷調

整與修正，應對快速變化的需求、技術及市

場。

但傳統週期性開發方式，在每個 Iteration 中

還是會採取比較像是 mini-Waterfall 的方法，

在短週期中一樣切割了需求、分析、設計、

開發、測試的階段與 SA、SD、PGR、Tester

等角色。雖然使用短週期來應對快速變化的

軟體開發，但如果還是像 Waterfall 將工作與

角色做切割，便會產生不同角色間的交接與

衝突問題。在角色交接上需要各個角色準備

詳盡規格，交給下一階段的角色作為依據。

用規格交接會產生兩個問題，一個是寫詳盡

規格本身就必須耗費許多時間。另一個問題

是當對規格內容認知有落差，產出成品跟預

期不同時，雙方將會產生責備與衝突，更不

用談因此產生的重工問題及資源浪費。

Scurm 培訓團隊成員 每個人都是 DeveloperScrum 避免這樣交接與衝突的設計，是讓團隊

成員都有能夠從需求、分析、設計、開發到測

試，完成整個功能的能力。在 Scrum 團隊中大

家都是 Developer，沒有區分SA、SD、PGR、

Tester 等角色。但每個人並不是因此在所有的能

力上都是相同的，有的人可能是分析強一點，

有的人可能是設計強一點，但每個人都要有全

功能的基本能力，也就是之前通稱的「T型人

才」或是現在流行的「斜槓青年」。

在一些領域中要達成全功能是困難的。但是在軟

體開發的領域中，擁有全功能能力的人是實務

上已存在，一般人都可以透過學習來達到這樣

的能力。因為每個人都有著全功能能力，也有著

自己更專長的技能，於是團隊運作有了不需要多

人交接即可獨立完成的可能性，可節省為了交接

而產生的額外成本。除此外，也因為各有各自

的專長，當我負責系統分析功能時，我可以先

自行設計，完成後再找在專長系統分析的人一

起 Review 與討論。讓原本因為工作交接相互責

怪的文化，轉變成相互協助的團隊合作文化，更

能夠在這樣的過程中自然而然的培養每個人的能

力，吸收比自己厲害的人的專長。

July 2018 | 叡揚e論壇 第90期 | 17

EIS-90.indd 17 2018/7/13 11:17