國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
19
軟體工程轉向元件式開發(Component-based software engineering)，使得系統中的 元件可以獨立開發。開發後的元件對外藉由介面彼此溝通，元件內部的執行程序 則透過封裝的概念隱藏。因此若系統架構固定後，元件之間銜接性將大幅提升，
增加系統未來延伸性。二、開發環境的精進，簡化開發者製作使用者介面的程序，
且增進系統撰寫的效率，縮短系統建立的時間，也增加系統雛型展示給使用者回 饋的機會。三、在系統發展初期多數使用者的需求模糊不清，若能請使用者增加 進駐到開發團隊的比例與時間，使用者在回饋開發雛型的成本和時間便能降低，
新的使用者需求也可以獲得馬上的改善。四、不同專案因受到組織內外在因素的 影響，進而調整系統開發流程與方式使得系統發展方法論逐漸走向客製化。(R.
Baskerville & Pries-Heje, 2004; Cockburn, 2002; Brian Fitzgerald, 2000)
第二節 敏捷式系統發展方法論探討
敏捷式系統發展方法論使用時機
敏捷式系統發展方法論認為當環境不斷改變以致市場難以預測時，使用敏捷 式系統發展方法可以增加系統開發的彈性，符合市場需求(Beck, 1999)。目前企業 在使用敏捷式系統發展方法論仍抱持實驗性態度(Brian Fitzgerald, Hartnett, &
Conboy, 2006)。透過觀察以往的研究，可以發現企業在使用系統發展方法論時多 是擷取方法論部份的過程，因為只有此部分的方法論對這家公司在系統開發時有 貢獻。正因如此找到使用敏捷式系統發展方法在不同時機的貢獻更顯重要。
Boehm(2002)認為傳統的規劃導向系統發展方法(著重於在系統開發初期就 完整規劃的方法，如；瀑布式系統發展方法論、結構模型等)與敏捷式系統發展 方法(著重於在系統建置前才規劃的方法)在使用上的界線各是光譜的兩端。
Boehm 提出以風險管理的概念來選擇規劃方法。他並定義系統風險暴露(risk exposure, RE)為規劃可能的損失(P(L))與市場規模損失(S(L))的乘積(RE=P(L)*S(L))，
而這些損失包含利潤、聲譽、系統生命週期品質等其他項目。圖 2 中從左上至右
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
20
下的線是指，當一個企業在開發系統時若是在發展初期就投入大量資源規劃，它 面臨高時程風險、高重製風險或高估市場發展等市場因素，同時也可能發展出不 適當的計畫。但若為適當的計劃，企業在持續投入時間與資源後，因提高計畫完 整度所以面臨的市場性問題自然較少。相對而言從左下至右上的線是指，初期投 入少量資源規劃，而產生簡易的規劃報告。因為簡易規劃的延誤性低，可以取得 早期市場，但在企業持續投入時間與資源後，計畫若發現不適用可能導致無法取 得完整的市場價值。因此在圖 3 中可以看到，我們若是採用不同系統發展方法時，
他的風險因素也會做變動。圖 2 中所解釋的是將所有系統的開發過程座總和，若 在其中取出使用規劃導向方法的專案，則其風險因素就會往右移。若是採用敏捷 式系統發展方法，其風險因素就會往左下移動。Boehm 以電子化的服務業為例，
系統需求者所需之系統不僅需要可以快速提供價值，同時也需有品質的保證。而 在高度規劃後推出可能會造成市場推銷的延遲而錯失規模成長的機會，相對而言 在低度規劃後立即推出則可能造成因規劃不適切而造成系統結構錯誤等問題。
圖 2 計劃投入/風險暴露圖 I 資料來源：(Boehm, 2002)
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
21
圖 3 計劃投入/風險暴露圖 II 資料來源：(Boehm, 2002)
Boehm 認為系統規劃的詳細度會根據使用不同的系統發展方法論產生高低 的不同，因此所面對的市場規模風險也不相同，敏捷式系統發展方法可以在初期 就直接進入市場，並且透過對市場變動快速地回覆以降低整體風險性，相對而言 採用規劃導向系統發展方法論若遇到市場變動時要投入大量的資源以重新規劃，
但可能會因此產生不利於市場競爭之風險。
因此 Boehm 歸納出以下幾個屬性，包含開發者的特質(擁有的系統發展技術、
溝通或尋找支援的能力)、客戶的特質(客戶在開發流程中的參與度)、系統需求的 特質(需求的穩定性)、系統架構、重構(refactor)的成本、產品與開發團隊規模、
開發系統的核心目標，並藉由分析這些屬性來選擇適當的系統發展方法。一般來 說除了公司本身使用的開發方法外，開發人員也可以將敏捷式與傳統式系統發展 方法視為一個光譜的兩端，上述的屬性則為光譜中的面向。組織選擇使用系統發 展方法時依照上述的屬性檢視組織內部情況、客戶情況、系統特質、慣用開發方 法等來做為選擇系統發展方法時的依據，或是將兩種系統發展方法搭配混合並擷 取各自的強項做為開發流程與準則。
彈性開發的特徵與敏捷式系統發展方法相近，開發者於開發時採取不同的流 程發展系統以提高彈性度(Teece, Pisano, & Shuen, 1997)。Harris, Collins, 與
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
22
Hevner(2009)採用動態能耐的觀點來解釋何時使用彈性開發，彈性開發可以應用 在市場變動性且技術變動性高的情況。因此，企業內部應該允許開發團隊在面臨 高市場變動時能自由調整作業流程以輔助系統的發展。
另外藉由控制理論來說明彈性開發的操作。Harris 等人強調系統範圍指標與 持續性的使用者回饋可視為彈性開發的控制依據，並認為假若在分析階段時便完 整的知道系統發展範圍，則可以採用規劃導向的開發方法。反之若只能得知粗略 的系統範圍時，則可以採用拼湊式(Ad hoc)的開發方法。規劃導向的開發方法在 實作系統前已決定多數系統規格，開發團體主要依循規劃建置系統程式。拼湊式 開發方法是一個有機的過程，因此有賴系統開發者自行監督開發以達成組織目標。
這兩種方法除了以系統範圍做分界外，同時它們都是在系統發布時才回饋使用者 意見，如下圖第一、二部份所示。
圖 4 彈性開發示意圖 資料來源：(Harris, et al., 2009)
Harris 等人將回饋程度的高低分成發布時回饋與持續式回饋，以 RUP 和 XP 為例，RUP 因為系統範圍定義詳細，因此在每個開發週期後才進行回饋；XP 則 利用每天發布、搭配開發以及協同客戶代表等方式，讓開發相關人員能在開發時 也持續進行回饋。相對而言，若系統範圍完全模糊而採用拼湊式開發，則回饋大 多需要等到開發完成後才會收到。因此本論文中所討論之敏捷式系統發展方法是 屬於持續性回饋且系統範圍中的部份為預先定義、部份為開發時定義。因此 Harris 等人將它定義為控制與彈性導向的組合 。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
23
最後 Harris 等人建議除了時間壓力與系統規模的考量外，在選擇使用傳統的 規劃導向、拼湊式導向或是控制與彈性導向時，必頇了解當下面對的系統範圍、
開發人員間的互動關係。
Maruping, Venkatesh,與 Agarwal(2009)驗證了在市場需求變動程度高時，若 採用敏捷式系統發展方法是有利的。他們提出使用敏捷式系統發展方法論時頇考 量成果控制指標與開發者自我控制指標。成果控制指標是一組專案期望的目標，
如產品期限、錯誤率等，以及完成目標後能得到的獎勵。成果控制指標也會影響 專案品質，因為敏捷式系統發展方法論相信彈性來自於開發者透過不同管道來達 成任務，然而開發進度可能受到不同解決管道的差異而面臨無法達成成果指標的 風險。因此定義明確的成果控制指標能讓開發者專心於達成目標。
自我控制代表個人對於自主權的控制，也就是個人對於活動的需求、應該採 取的行動，以及執行的方式做主。因此自我控制鼓勵個人設置目標，並且調節和 監測進度以實現目標。開發者自我控制雖然在一些系統發展研究中被認為可以促 進系統發展效益(Bailyn, 1984; Henderson & Lee, 1992)，但是因為使用敏捷式發展 方法時開發團隊必頇分配工作、持續整合模組、重構程式等，而這些都有賴於彼 此間之協調。因此若開發者自我控制的程度高，使用敏捷式系統發展方法論可以 將開發者的進度與團隊進度保持一致，Boehm(2002)也認同此觀點。
敏捷式系統發展方法論使用時機綜合觀點
綜合上段的觀點，使用敏捷式系統發展方法論與規劃導向發展方法論為一橫 軸的兩端，因此在採用的時機上可以考慮四個屬性，一、開發者特質，二、回饋 特質，三、系統需求特質，四、系統成果控制。以下針對每個屬性中適合敏捷式 系統發展方法論使用的時機做探討。
一、開發者特質
開發者在使用敏捷式系統發展方法論時，可以分為兩個層面，第一層面是開 發者個人觀點。對開發者而言使用敏捷式系統發展方法論在開發系統時擁有的彈 性較大，因為可以依據自己的方法解決問題，以產生滿意解。但是開發者可能陷
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
24
入自我控制程度不彰的情況而導致開發進度參差不齊，因此在擁有自主權的情況 下，維持開發者的紀律是很重要的。第二層面是開發團隊，績效制度在團隊中應 該採取共享制，以促進團隊合作、學習。相對而言若開發團隊無法達到績效共享，
則應該謹慎規劃後再開發，因而適用於規劃導向開發方法。
二、回饋特質
回饋的時機可以分為兩種，第一是團隊內，第二是與使用者間。團隊內的回 饋可以促進工作的分配、進行和互相學習。使用者若能持續性的回饋則可以在採 用後共同進行開發。敏捷式系統發展方法相對於規劃導向方法而言，規劃導向方 法的工作是在一開始就清楚地定義，且重新分配工作的所需時間較長，另一方面
回饋的時機可以分為兩種，第一是團隊內，第二是與使用者間。團隊內的回 饋可以促進工作的分配、進行和互相學習。使用者若能持續性的回饋則可以在採 用後共同進行開發。敏捷式系統發展方法相對於規劃導向方法而言，規劃導向方 法的工作是在一開始就清楚地定義，且重新分配工作的所需時間較長，另一方面