敏捷開發效益與心得
目前市場上客製化應用軟體系統開發，雙 方簽約時依照需求建議書 (RFP) 和專案 工作說明書 (SOW) 決定合約金額，簽約後則 安排需求訪問及需求功能確認，接下來就是系 統開發、整合測試、使用者測試、相關功能確 認及上線。表示該客製化應用系統的開發需求 範圍功能、金額與開發交付時程期限都是固定 的，若無法及時交付，軟體公司將因上線延後 而導致被罰款。
然而敏捷開發的精神則是依照固定的人力資源 在固定的期限內開發出最需要的功能，而不是 要具備所有想要的功能。這表示在每一個開發週期 (Sprint) 依照實際安排的開發人力，由產 品負責人 (Product Owner) 來定義要開發的功 能，且開發進行方式將依照複雜性而決定是否 採取漸進方式來開發。(圖 1) 但實務上履約的 驗收仍然以合約簽訂的內容為依據。而現階段 幾乎所有客製化軟體系統合約簽訂，仍然是以 waterfall 架構為主。
目前在較大型或複雜的客製化軟體開發，在開 發過程中往往是以模組方式分別進行開發，直 到各個模組均已經完成時才開始進行整合測 試，當不同模組串接做整合測試時，遇到問題 往往前後模組都需要調整與修正，甚至於要大幅度修改，造成整合測試需要花費更多的時間 與修正，造成重工且效率差。
若在開發過程中於每個開發週期中，我們以流 程觀點做小規模的整合測試，如此便可以提早 發現問題並提早解決，避免一錯到底的情況 發生，相對的也能降低開發風險，這也是我 們在現行 waterfall 合約下要導入敏捷開發的目 的。換言之，即是採取分段式 (Sprint 週期) 開 發，在每一開發週期要是安排小規模的流程整 合測試，這也是所謂的 Sprint 開發與 Demo/ Retrospective 模式。
Run Sprint 方式
以敏捷開發觀點來看，開發的時間和資源是固 定的，在這個限制下，即時開發出最需要的功 能，而不是很多想要的功能。因為在合約規範 中，已經訂出範圍及交付時間，所以無法完全 採用敏捷開發架構，而是依功能與前後流程關 係及其重要性，訂出每一 Sprint 的範圍，且 在該客製化系統中所有主要功能都要能涵蓋在Sprint(s) 之中，以確保所有主要功能皆可正確 且準時完成。
在敏捷開發團隊分工合作中，主要有以下三種功能角色:
- Product Owner:產品負責人，需求管理與驗收產品為所有利害關係人的代表
- Scrum Master:確保 Scrum 流程順暢執行 3. Develop Team:開發團隊
與專案開發團隊對應關係:
PM:根據合約內 RFP/SOW/SRS (軟體需 求說明書) 規範，負責需求管理與確定每個 Sprint 需要開發的項目功能，以及 Scrum 順 暢執行。
現行 Sprint 週期是設定每二週為一週期，在 第二個星期四安排 Demo /Retrospective，現階 段在開發過程中，因考慮交付時程，工作仍以 派工為主、自取為輔，如此在開發成員間可相 互協助。
我們在過去三年在執行敏捷開發過程中，客戶 參與開發過程中有下列三種情形:
- 參與部分，但又停止
- 未參與
- 參與，但遇到困難經雙方溝通與達成共 識，也瞭解每一 Sprint 目標，持續參與， 並於每次 Demo 時提出回饋供後續的改進
是否要邀請客戶 (甲方)
一起參與系統開發
客戶能一起參與，對開發一定有好處，但也一 定會有影響，所以事前的溝通及對敏捷開發的 方式及過程有充分的瞭解，在這種情況下，我 們鼓勵客戶一起參與 Sprint Demo 並於 Demo 後提供看法。
透過彼此持續溝通想法，軟體開發也會做必要 的調整。簡單說如果能提早發現問題，就提 早調整及修復，不要等到 UAT 階段發生才處 理，此時往往耗工耗時。在此階段問題溝通要 能客觀分析，彼此想法不同時，要釐清是雙方 對需求認知不同，還是新需求以及其必要性。
過程中遇到的問題與如何克服
在不同的 Sprint 週期中，原設定功能範圍先 後順序需要再調整，加入新需求 (CR) 但交付 時程不變，初期團隊的磨合，因採派工方式 (派工為主，自取為輔)，容易產生工時認定問 題，進而影響專案開發時程。
新手老手的經驗不相同，團隊需要彼此磨合， 約進行 2 或 3 Sprint 週期後才會逐步進入佳 境，進而形成所謂「有機開發團隊」(Organic Develop Team)，其特質為主動、協同合作、互補和目標清楚一致。
在有客戶參與的 Sprint 過程中，往往因期望 不相同，要求系統能更好，會提出各樣需求建 議與問題，此時雙方就需要有良好的溝通並加 以歸類，若是問題則排定處理時間。新增需求 (CR) 且是必要的則透過 CCB (change control board) 議定，若非為必要的 CR 則等系統上線 後再安排。也確保上線時必要的功能都涵蓋。
採取敏捷開發的優點
可經由分散式的整合測試 (Sprint demo)，降低 風險，縮短並降低 UAT 的問題。不僅團隊成 員協同合作能力提昇、團隊之間能共用共享技 能，在團隊工作增加時能有更多的靈活性。 在溝通時可亦透過站立會議 (daily stand up meeting)，可讓團隊成員學習如何有效地時間 管理。問題描述更簡潔清楚，溝通更有效，也 會關心其他成員。
在敏捷開發過程中，對客戶的好處莫過於雙方 互動溝通彼此了解，在執行端作業更順暢效率 提升，管理端效率，效能，監督，管理更好。 客戶也能透過參與 Sprint demo，快速檢視已 完成的功能，進而提升滿意度。
未來展望
不同的客戶，不同的專案特性，雙方如何合 作，都是不同的挑戰。彼此有很好的互動，溝通，加上敏捷開發合作模式，才能使客戶對客 製化系統更加滿意。