對這文章發表回應
發表限制: 非會員 可以發表
發表者： 冷日 發表時間： 2008/3/14 8:42:16
| ALM專題系列之二 中小型企業最適用的敏捷式開發流程 |
| 應用軟體生命週期尋求方法論的解決方案，主要是為了實現管理手段，並整合開發角色、流程、技術等各層面。目前IT領域中，具體實現應用軟體生命週期的流程有兩種：整合的能力成熟度模型（CMMI）與敏捷式開發流程（Agile Programming）。前者適合大型企業或獨立軟體供應商等，具有為數較多的開發人員，以及講求制度的企業文化；後者則適用於各式開發團隊，也就成為我們此次探討的焦點。 應用軟體生命週期的方法論：角色、流程、工具 軟體開發生命週期方法論考量到角色、流程、技術等三個層面。對於中小企業的體質（例如開發團隊人數、企業文化、營運成本等）現況，雖然沒有絕對的方法論可規範軟體開發，我們也無法預期可以找到一個萬用的流程套用在所有專案上，其變因眾多，例如使用的技術、開發團隊的規模與地理位置、開發角色的工作風格、組織文化、市場風險等。此外，因為中小企業開發團隊人數不多，許多專案執行時，每個人常身兼多種角色，而敏捷式開發流程的彈性，則成為主流應用。 至於流程方法，主要是瀑布式（Waterfall Process）與敏捷式（Agile Process）兩種，後者也稱為反覆式（Iterative Process）。基本上企業的開發流程都可歸納為這兩種，只是本身並不知曉而已。這兩種流程的本質差異在於：如何將專案分解成更細小的部分，這也決定產品交付的次數與品質的優劣，瀑布式只交付產品一次，並決定品質與功能是否契合使用者需求；而敏捷式會交付多次，或者稱為多個發行版本（Release），功能會在反覆的開發過程中逐漸完整，而品質也會因為循序式的修正，而減少錯誤。 瀑布式開發流程無法預測軟體品質 以往，多數企業採用瀑布式開發流程，其問題在於軟體開發過程與結果無法事先預測。換句話說，可能在某個階段就偏離客戶需求規格，而團隊渾然不知，也缺乏有效可控管的修正機制。結果是造成重工（Re-work），或專案無法結案，因而耗費大量成本。 由於階段性的過程，所以瀑布式方法在前一階段完成後，才能進入下一階段的流程，而且必須經歷文件製作與核准的作業，耗費不必要的成本。貿然進入下一個階段會使得系統的結構不良。此外，瀑布式將軟體開發分割成多個階段，使專案不具彈性，無法針對客戶需求變更作快速回應。 過去，瀑布式之所以廣為採用，歸因於軟體複雜度低，需求與規格定義明確。如今，客戶很難釐清或清楚說明需求規格，使得許多開發過程常經歷劇烈的需求變動，增加軟體複雜度。許多採用瀑布式開發方法的廠商會向客戶要求，在初期先凍結需求規格，不允許任意的變動而修改規格，或僅能透過專案合約提出正式需求變更（Change Request，CR）表格，並以追加預算的方式執行。早期凍結需求的風險是最終產出物與客戶需求有嚴重的落差。一旦專案進入此階段，最嚴重的狀況是雙方的專案經理在談判桌上針鋒相對，使得專案無法結案，委託者拿到一個品質欠佳的產品，而開發一方也常收不到尾款，兩敗俱傷後收場。 敏捷式開發流程講求與客戶共同開發軟體 敏捷式開發流程特點是程式撰寫與測試為同一個開發循環內相近的活動，撰寫程式的程式人員也順便寫下測試程式。目前許多精巧型的開發團隊更採用測試先於設計，指的是撰寫程式碼之前，先寫測試案例。此測試程式的規格則與使用者討論後所制定，而寫程式是為了讓沒通過的測試案例通過測試，更能契合使用者需求。即使過程中使用者需求不斷更動，但因為使用者也參與過程，以及反覆性的週期，所以不至於產生需求落差。 敏捷式開發流程主要特性是以人為本的開發流程，所以注重開發角色的素質，以及各團隊成員間合作的默契。軟體開發雖然會因為需求變更而反複地變動，但仍遵循特定的流程，使得開發角色可以替換，不至於因為以人為本而疏於管理。為了平順地執行程式撰寫與測試反覆程序，敏捷式採用所謂的搭檔開發（Pair Programming）。這種搭檔方式並不一定是資深搭配資淺，也不是一人撰寫，另一人僅是觀看，而是共同創作、分享技術。 以臺灣的商業體系分類，大型企業動輒50~100人以上的開發團隊，適用CMMI的開發方式，而10人以下的中小型企業則適用敏捷方法，只是這樣的分法並非絕對，以微軟而言，雖然全球將近5000位軟體工程師，仍然可以將其拆開為5~10人左右的小型團隊，並套用敏捷式開發流程。 從市場面，也可以驗證敏捷式的開發方法確實適用。臺灣的軟體市場規模不如歐美，企業並不一定需要功能齊全、複雜度極高的大型軟體，而這類軟體需要大型開發團隊配合整合的能力成熟度模型等嚴密的流程，才能成功地產出。此外，以中小企業為主體的軟體市場，也無法負擔大型軟體的建置費用；由於市場規模小，容易飽和，所以供應商也必須快速推出新版，以吸引用戶購買，獲取利潤。歸納而言，小型團隊與需求頻繁變更，正是敏捷軟體開發方法的重要訴求，另一個現實面則在於，中小企業通常採用人治的管理方式，也就是很仰賴主管的直覺，敏捷式開發方法也正適用以人為本的開發方式。 敏捷式開發流程的特性：自動化的回歸測試、重構、持續整合 在瀑布式模型中，開發人員在需求分析中產生大量文件，到設計、開發、測試等一系列過程。相對地，敏捷式模型的重點在於先產出早期可檢驗與執行的軟體，系統從應用程式的一部份實作開始，特別是優先滿足使用者核心需求的功能，一般稱之為原型（Prototype），隨著客戶需求改變而不斷增加原型的功能。每次過程混合分析、設計、建立、測試等流程，反覆驗證系統架構，以保證客戶的需求，提升軟體品質。 敏捷式開發流程強調務實的、可預見結果的專案過程，使得專案關係人（Stakeholders）可明瞭的軟體開發實際進展情況，而不是憑文件想像軟體概念。在敏捷式開發流程的實務中，軟體團隊最關注的是結果。 依Martin Fowler所建議適合敏捷式開發流程主要特性，包括以下3種： 1.自動化的回歸測試（Automated Regression Tests） 以單元測試為例，單元測試的程式碼大小約等同於產品的程式碼。目前工具已具備這樣的功能。 2.重構（Refactoring） 重構是將一連串小的、可保留行為的轉換動作，實行到程式碼庫的工作方式。目前工具已具備這樣的功能。 3.持續整合（Continuous Integration） 又稱為收斂（Converge），當所有開發角色將程式碼放入程式碼庫時，都會自動啟動建構流程（Build process）。 以目前工具的發展，管理員可以要求各開發角色將程式碼存入中央儲存庫（Repository），系統會自動建立版本，並在建構過程中，列出程式錯誤。目前多數工具也可以執行完整的自動化回歸測試，並將結果包裝成為一個建構版本。文⊙張瑞隆 |