如何利用敏捷開發 管理軟體開發的不確定性
根據科技產業研究機構 Standish Group 調查，Waterfall 的開發方式失敗比例非常高。大致上會產生兩種改善觀點，其一認為團隊沒有做好該做的事情、沒有做好計畫、沒有釐清好需求、在每一個階段沒有做好確認與驗證。如果你採用了這種觀點，那麼解決方案就會落入了更要求「把事情做對」上。把計畫做的更好，增加更多的 Review， 要求更多的文件與簽名，更多的測試人力等等。但有沒有可能，問題不在於「做的不好」，而是在於「做事的方法」上?
1985 年出版的「人月神話」是資訊人必讀的經典書籍。作者將軟體開發的困難性區分為「本質性」的困難與「附屬性」的困難。 對於軟體「本質性」的困難(複雜性、隱匿性、配合性、易變性)，我們無法只是用要求更努力「把事情做的更好」的方式來改善。近代，在軟體技術層面發展了許多更好的架構設計、Design Pattern、物件導向程式語言等。這些都能讓軟體更好開發，但卻還是有很大比例的軟體專案仍舊使用著快 50 年前提出的 Waterfall 模式。一直到 1990 年代敏捷開發思維逐漸發展後，對於開發程序才逐漸有了不同的觀點。與傳統的 Waterfall 的開發模式相比，敏捷開發是一種應對快速變化需求的一種軟體開發模式，其中 Scrum 又是其中最流行的一種方式。
軟體專案不確定性 從計劃到完成差異 8 倍
由於軟體的「本質性困難」產生了「不確定角錐」現象。從一開始的計畫，到軟體的完成，可能有 8 倍的差異存在，不管專案的執行做的多好，也只有 1/8 機會準時完成專案。所以與其一開始就追求「完美計畫」，不如採取 「週期性」方式。將原本預計一年才完成的專案，切割成 2-4 週的週期，在最初的幾個週期中完成原本計畫中最重要、最有價值、風險最高的功能項目。
避免專案後期才發現 Bug，或客戶到系統完成後才知道自己想要的是什麼，讓不確定性風險縮小。同時，在每個週期最後都可以展示目前完成內容給客戶看，並計畫下一週期待完成事項。此過程就像開車，我們不會在一開始就把方向盤固定在一個方向，而是會根據路上狀況不斷調整與修正，甚至可能因為路況而決定繞不同的路，或更甚而調整目的地。
直覺上繞路與調整目的地都不是一個好的決定，對專案管理來說，專案目標是不允許變來變去的。傳統專案管理是希望在計畫完成後只要照表操課就能把事情完成，追求的是最小變數，但大部分軟體開發卻無法如此管理。 Cynefin 框架把問題分成簡單/繁雜/複雜/混沌/失序。這五類不取決於問題大小，而是根據問題不確定性區分。有可能是好幾億的工程專案，但仍屬於「簡單」的範疇。「簡單」類的問題存在 Best Practice，只要有專家制定好 SOP 後，接著就是資源與時間的簡單計算，也是最容易用機器自動化方式處理的範疇。
「繁雜」的問題則是不存在一個最佳解，但有 一些 Good Practice 可以參考，經過對問題與分析調查後可找出可行的解決方案。現在許多想用 AI 處理的問題就屬於這一類型的，沒有最好，只有更好。「複雜」的問題則參雜了更多的不確定性，需要隨著時間反覆探索來找出當下可行的作法，但隨著時間演進需要不斷調整做法來面對不確定性。而「混沌」與「失序」 則沒有因果可言，目前也沒有好的建議方法，這邊不做詳細的介紹，有興趣的朋友可以直接上網搜尋。
專案週期化 應對快速變化需求、技術及市場
從 Cynefin 框架來看，Waterfall 其實只適用於簡單類的問題，可根據問題的定義找出最佳計畫，然後照著執行即可。面對繁雜與複雜的問題，我們需要用不同方式來處理， 而 Scrum 就是其中一個十分合適的方法。將計畫切成許多週期，並在每個週期中不斷調整與修正，應對快速變化的需求、技術及市場。
但傳統週期性開發方式，在每個 Iteration 中還是會採取比較像是 mini-Waterfall 的方法， 在短週期中一樣切割了需求、分析、設計、開發、測試的階段與 SA、SD、PGR、Tester 等角色。雖然使用短週期來應對快速變化的軟體開發，但如果還是像 Waterfall 將工作與角色做切割，便會產生不同角色間的交接與 衝突問題。在角色交接上需要各個角色準備詳盡規格，交給下一階段的角色作為依據。 用規格交接會產生兩個問題，一個是寫詳盡規格本身就必須耗費許多時間。另一個問題是當對規格內容認知有落差，產出成品跟預期不同時，雙方將會產生責備與衝突，更不用談因此產生的重工問題及資源浪費。
Scurm 培訓團隊成員
每個人都是 Developer
Scrum 避免這樣交接與衝突的設計，是讓團隊成員都有能夠從需求、分析、設計、開發到測試，完成整個功能的能力。在 Scrum 團隊中大家都是 Developer，沒有區分SA、SD、PGR、 Tester 等角色。但每個人並不是因此在所有的能力上都是相同的，有的人可能是分析強一點， 有的人可能是設計強一點，但每個人都要有全功能的基本能力，也就是之前通稱的「T型人才」或是現在流行的「斜槓青年」。
在一些領域中要達成全功能是困難的。但是在軟體開發的領域中，擁有全功能能力的人是實務上已存在，一般人都可以透過學習來達到這樣的能力。因為每個人都有著全功能能力，也有著自己更專長的技能，於是團隊運作有了不需要多人交接即可獨立完成的可能性，可節省為了交接而產生的額外成本。除此外，也因為各有各自的專長，當我負責系統分析功能時，我可以先自行設計，完成後再找在專長系統分析的人一起 Review 與討論。讓原本因為工作交接相互責怪的文化，轉變成相互協助的團隊合作文化，更能夠在這樣的過程中自然而然的培養每個人的能力，吸收比自己厲害的人的專長。