【研究報告解密】你的專案選對方法了嗎？從結構化到敏捷，揭秘適合你團隊的開發模式

這次找來的是一篇比較新的研究報告，於 2023 年發表在《International Journal of System Assurance Engineering and Management》。報告題為《結構化軟體開發和敏捷軟體開發方法的完整分析》（Structured software development versus agile software development: a comparative analysis)，由 Alok Mishra 和 Yehia Ibrahim Alzoubi 所著。

為什麼選擇這篇報告？因為我一直對不同的軟體開發方式（或專案管理方法）深感興趣。我相信，如果想增加專案的成功機率，我們必須先了解不同運作模式的長處與短處，才有可能優化現行的管理手法。

這篇研究剛好探討了軟體開發光譜上的兩端：一端強調管治、規則和流程（結構化）；另一端則強調靈活、合作和價值（敏捷）。這兩種截然不同的價值觀，在實際專案管理上會有什麼差異？什麼樣的專案更適合哪種方式？專案管理真的只有「二選一」這種出路嗎？

如果你也有同樣的疑問，我將在這篇文章中分享這份報告的重點，並搭配我的實戰經驗進行解析。如果你希望對專案管理有更深一層的體悟，請繼續往下閱讀。

敏捷和結構化軟體開發方式的特性

為了讓大家更直觀地理解這兩種位於光譜兩端的管理方式，我們在深入探討報告前，先簡單介紹一下它們的核心特性。

敏捷軟體開發（Agile）：擁抱變化的探險者

敏捷開發最顯著的特性就是「靈活」。我們可以把它想像成一場充滿未知的自駕旅行。

當你開車前往一個陌生的地方，出發前你肯定會設定好導航。但在敏捷的模式下，導航的路線並不是死板的。當你開到一半，突然想起需要先去另一個地方買東西，或者發現原定路線大塞車，你可以立即在下一個街角轉彎，靈活地修改路線，甚至調整最終的目的地。

敏捷的靈活，在於允許專案團隊根據「當下最高優先級」的事項來改變方向。它的目標是交付「真正能幫助用戶」的軟體，而不是盲目地執行最初的計劃。這種方法的核心在於與客戶保持高頻率的接觸與溝通，深入挖掘對方的真實需求。當市場風向改變、政策調整，或是發現原本做的東西不符合用戶期待時，敏捷團隊能以最快的速度進行急轉彎。

然而，「針無兩頭利」，這種方式也有其代價。

正因為敏捷強調靈活與應變，專案初期往往難以精確描述最終產出的軟體全貌（因為目的地可能會變）。此外，一旦專案的利益相關者眾多，溝通成本會變得極高且低效，容易導致某些關鍵需求被遺漏。再加上敏捷通常較不依賴文檔記錄，當問題發生時，追溯責任歸屬可能會變得模糊不清。

此外，敏捷方法還有一個極高的門檻：它要求客戶「持續參與」，並與開發團隊保持緊密的合作。

正如我在之前的文章中提過，要建立這種互信的合作關係絕非一蹴可幾。這不僅僅是流程上的調整，更需要專案中每一位參與者——從開發團隊到客戶端——在文化與觀念上做出根本的改變。如果客戶只習慣「發號施令」而不習慣「共同協作」，敏捷的效果將大打折扣。

結構化軟體開發（Structured）：嚴謹的建築師

談到結構化開發，最經典的代表莫過於瀑布式開發（Waterfall）。它擁有一套完善且嚴謹的體系，包含流程、階段驗收與詳盡的文檔。

如果同樣以開車為例，結構化方式就像是火車或公車的既定路線。在出發前，路線圖已經被嚴格制定，司機必須盡最大努力堅守這條路線。如果在途中想要改變路線，這可不是轉個方向盤那麼簡單——你必須先停下來，進行詳細的變更分析（Change Request），評估為什麼要改、改了有什麼優缺點、成本多少，經過層層審批後，才允許偏離原定軌道。

這種管理方式已經存在數十年了，它是許多傳統企業最熟悉的遊戲規則。專案啟動後，客戶非常清楚他們何時該進場驗收、何時該付款。更重要的是，因為專案是以「完全可預測」為前提來執行的，它能為管理層提供極具安全感的資訊：明確的完成時間（Deadline）、固定的預算和確定的功能範圍。對於許多高層人士來說，這種對未來的「確定性」往往是必不可少的。

但凡事有利必有弊。由於在專案初期就對整體進行了鉅細靡遺的規劃，一旦執行途中需要變更，往往牽一髮而動全身，需要修訂後續所有的計畫與文檔，這在瞬息萬變的市場中顯得既浪費時間又低效。

此外，這種方式假設客戶在專案第一天就能清楚知道自己「要什麼」。但現實往往是殘酷的——如果客戶無法釐清需求，或者意見分歧，專案就會陷入僵局。最慘的情況是，團隊花了半年開發，直到最後交付試用的那一刻，客戶才驚覺：「這不是我想要的！」此時，專案團隊將面臨進退兩難的災難性局面。

如何選擇應該使用那種方式

了解了這兩種開發方法的特性與優劣後，現在來到最實際的問題：身為專案經理（PM），面對一個新專案時，我到底該選擇哪一種方式帶領團隊呢？

本次分析的研究報告中，作者提出了一種基於「決策樹（Decision Tree）」的選擇模型。但我讀完後認為，純粹的決策樹在現實中可能過於非黑即白。因此，我保留了研究中的核心決策元素，並結合我的實戰經驗，將其改良為一套更直觀的**「傾向性評分法」**。

這就像大家熟悉的 MBTI 心理測驗一樣，我們不需要死板地二選一，而是透過評估以下幾個維度的傾向，來計算出專案的「屬性」。請看下圖：

中間代表0分，往左或右一格則相關方面加１分，如果選擇的是最左或最右的圈圈，則得３分。接下來讓我們逐一檢視有那些關鍵的評估元素：

1. 專案的複雜性與確定性
   請思考你即將面對的專案，在技術使用、法規遵循以及人際（利益相關者）關係上，是否都已經清晰明確？

• 往左選（結構化）： 如果這一切都相對清晰，變數很少，或者你和團隊對此領域已經信心十足。

• 往右選（敏捷）： 如果充滿未知、技術尚未驗證，或是涉及複雜難搞的人際政治。

2. 需求的清晰度

• 往左選（結構化）： 客戶能夠在專案前始時就完全清楚、邏輯縝密地表達出自己的需求，且看似也不太會更改。

• 往右選（敏捷）： 客戶只有一個模糊的概念，或者需求可能會隨著市場回饋而頻繁變動。

3. 時間限制

• 往左選（結構化）： 截止日期是絕對的「硬指標」（例如配合法規生效日），不可延後，且如果不準時交付會有嚴重後果。這時你需要結構化的計畫來控管進度。

• 往右選（敏捷）： 截止日期只是一個「期望值」，或者客戶更看重「儘早拿到可用的東西」而非「再一次性拿到完整的東西」。

  • 編輯註記：專案經理需小心識別，很多時候客戶口中的 Deadline 其實是可以透過談判調整範圍（Scope）來達成的。

4. 預算限制

• 往左選（結構化）： 預算是一次性審批的（Fixed Price），一經批准後難以更改。這通常需要前期精確的估算。

• 往右選（敏捷）： 預算比較充裕，或者是採用「實報實銷（Time & Materials）」的模式，允許隨著專案發展追加投入。

5. 客戶的參與程度

• 往左選（結構化）： 客戶參與度低，習慣「交鑰匙」模式，只在開頭提需求和最後驗收時出現，中間不希望被打擾。或者他們更多的時候並不會主動關注專案的情況。

• 往右選（敏捷）： 客戶非常積極，願意（甚至要求）參與每週的討論，並渴望隨時看到半成品給予回饋。

6. 團隊的默契與成熟度

• 往左選（結構化）： 團隊成員多為臨時組建，互不熟悉，或者成員較資淺。這時依賴明確的文檔和流程（SOP）來協作會更安全。

• 往右選（敏捷）： 團隊成員已經是老戰友，彼此默契極佳，不需要太多文字溝通就能理解對方的意圖。

【評分結果】
當你對以上各方面作了充分的評估後，請將「左邊」與「右邊」的得分各自加總。

• 如果左邊得分較高：建議考慮使用瀑布式（Waterfall）/結構化的方式來開發。

• 如果右邊得分較高：那麼敏捷可能會是更適合你們的選擇。

【勢均力敵怎麼辦？】
寫到這裡，你可能會問：「如果左右兩邊的得分很相近，難分軒輊，那我該怎麼辦？」

這正是這份報告最精彩的地方。作者指出，專案管理並非只有二分法。當分數接近時，代表我們需要一種結合兩者優勢的運作方法，稱之為「混合式軟體開發（Hybrid Software development approach）」。

到底混合式開發是什麼？是把兩個摻在一起做撒尿牛丸嗎？它又是如何解決單一方法的盲點？請讓我們繼續看下去。

混合式軟體開發方式 —— 剛柔並濟的藝術

「混合式開發」，顧名思義，就是將結構化與敏捷這兩種看似對立的方法，巧妙地融合在同一個專案中。它的目標很單純：保留兩者的優點，剔除各自的盲點，並賦予專案經理與團隊高度的彈性，去決定這杯「雞尾酒」的調配比例。

那麼，具體該怎麼混合呢？

報告作者建議的一種典型模式是：「頭尾結構化，中間跑敏捷」。

• 在專案的啟動與規劃階段（頭）： 主要採用瀑布式思維。我們依然會進行嚴謹的需求分析、定義範疇，並產出必要的高層級計畫與架構設計。這能滿足管理層對預算與時程「可預測性」的需求。

• 在實施與開發階段（中）： 切換成敏捷模式。團隊以短週期（Sprint）進行迭代開發，快速產出可用的軟體功能。

• 在交付與維護階段（尾）： 再次回歸結構化，進行完整的驗收測試與文檔歸檔。

這種混合模式帶來的效益是顯著的。它讓客戶能更早接觸到可用的軟體（敏捷的優點），同時又能確保專案留有必要的文檔記錄，供高級管理層或後續維護人員查閱（結構化的優點）。

當然，混合的方式千變萬化，並非只有這一種套路。你可以根據團隊與客戶的特性靈活組裝。例如：

• 你可以在規劃期保留「軟體規格說明書（SRS）」，但在執行期允許需求有 20% 的變更空間。

• 客戶雖然無法像敏捷要求的那樣天天參與，但你可以設定「每兩週一次」的展示會議，獲取反饋後，適度修正原本的規劃路線。

研究顯示，採用混合式開發的專案，通常能在降低開發成本、提升開發速度以及維持良好文檔管理這三者之間，取得最佳的平衡。

沒有標準答案，只有最適合你的配方

然而，混合式開發也有它的挑戰。不像結構化（如 PMP）或敏捷（如 Scrum）都有現成、完善的框架與證照可以依循，混合式開發目前並沒有一套放諸四海皆準的標準作業程序。

每一位專案經理都必須像一位調酒師，為自己的專案調配出專屬的混合管理方式。

這就像我每天喝的奶茶一樣，茶多一點會澀，奶多一點會膩。不同比例的配置，味道截然不同；而不同的團隊與專案，需要的「奶茶比例」也不一樣。

因此，如果你第一次嘗試混合式開發卻覺得卡卡的，甚至達不到理想結果，請千萬不要灰心。這不是你的問題，而是過程中的必然。只有經過多次的嘗試與微調，你才會找到那杯最適合你和團隊的「黃金比例奶茶」。

總結

回到文章最初，我們帶著三個疑問展開了這場探索：

1. 結構化與敏捷這兩種截然不同的價值觀，在實際管理上會帶來什麼差異？

2. 什麼樣的專案更適合哪種方式？

3. 專案管理真的只有二選一出路嗎？

通過這篇報告的解析與我的實戰經驗分享，相信你現在心中已經有了答案。你已經了解了瀑布式的嚴謹與敏捷式的靈活各自的代價與紅利；你也擁有了一套實用的「傾向性評分工具」，能幫助你在面對新專案時，不再憑感覺盲選，而是做出有邏輯的判斷。

最重要的是，我們發現了第三條路——混合式開發。世上並沒有一成不變的萬能公式，達爾文曾說過：「存活下來的不是最強壯的物種，而是最能適應變化的物種。」同樣地，適應性（Adaptability） 也是專案生存的根本。身為專案經理，你不應被特定的方法論所綑綁，而應靈活地為你的專案調配出最符合團隊體質的「黃金比例」。

請記住，無論你最終選擇了瀑布、敏捷，還是混合式，方法永遠只是手段，而非目的。

我們做的一切決策，並非為了證明某種方法論的優越，也不是為了讓自己工作輕鬆，而是為了同一個終極目標：讓專案成功交付價值。

我認為，這才是每一位專案經理在迷茫時，必須緊緊握住的原則。

希望這篇文章能為你的專案管理之路帶來一點啟發。如果你對這份報告有興趣，或者有不同的實戰經驗想交流，歡迎在下方留言告訴我。我們下個專案見！