【摘要】敏捷開發方法為軟件開發指處了一條快速適應需求的路。本文在介紹敏捷開發方法及其實現方式的基礎上，對敏捷開發方法在SaaS系統開發中的適用性進行了分析。

　　【關鍵字】敏捷開發;SaaS

　　0引言

　　SaaS(SoftwareasaService，軟件即服務)是云計算技術飛速發展的重要產物之一。相較于傳統軟件，SaaS產品一般是面向ToC市場。因此在開發初期，產品的最終用戶很少參與到產品決策當中，開發團隊只能通過預期分析明確用戶需求，而這極大可能造成產品功能與實際需求之間存在偏差。此外用戶還會不斷地對產品提出新的期望，因此需要團隊根據使用反饋，對產品功能進行持續的優化調整。由此可見SaaS產品需要具備高適應性，能夠根據用戶的反應快速調整產品功能架構。這也決定SaaS系統的開發，不會是單向的，而是一個需要不斷經歷從開發到使用再到調整的重復性過程。

　　傳統軟件開發模式雖簡單易懂，但實操時其過程卻較為繁雜。而且傳統開發模式對過程中的各種文檔都有著極其嚴格的要求，因此很大程度上降低了開發效率。2001年，由MartinFowler，JimHighsmith等17位軟件開發專家起草的敏捷宣言發表，其核心是希望通過輕量型開發、測試驅動、快速迭代來提高系統適應性和靈活性。同時經過人們多年的實踐總結，目前已發展出了多種敏捷實現方式。

　　本文將在介紹敏捷開發及各種實現敏捷開發方式的基礎上，從SaaS項目的目標、團隊和開發過程3個方面，討論其適用性。

　　1.敏捷開發的特點

　　敏捷開發的核心包括4句開發宣言和12條開發原則。與傳統開發方法相比，敏捷開發有以下主要特點：

　　(1)敏捷開發強調的是適應變化而不是一成不變。軟件開發除了要應對諸多不可預見因素外，還要滿足不斷變化的期望，因此高適應性才更符合軟件開發的實際。敏捷開發通過縮短交付周期、多次提交中間成果、增加各方交流來提高開發適應性。

　　(2)敏捷開發更注重人的作用。從激勵團隊成員到重視開發團隊的自主性，敏捷開發希望團隊中的每個個體都可以將其自身特點和創造力充分發揮，讓項目更具有生命力

　　(3)敏捷開發更重視可用的產品而不是詳盡的文檔。傳統開發模式極度依賴文檔記錄，并認為只有在文檔中詳細地記錄、分析客戶需求，才能降低后續開發工作可能遇到的風險，避免大范圍的修改和重構。而敏捷開發認為保持輕量化迭代才更為重要，通過持續的集成、測試、調整，在保證軟件可用的前提下，不斷為現有系統增加新的功能，持續收集用戶反饋意見，逐步對系統進行優化調整，才能成功完成項目、交付滿意產品。

　　2敏捷開發的實現方式

　　從本質上看，敏捷開發只是一種簡明扼要的概要準則，其并未明確在進行軟件開發時需要具體應用何種方法、實施哪些步驟。但是經過多年的實踐總結，人們已經提出了多種敏捷開發的實現方式。其中，最廣為人知的當屬Scrum框架、看板(Kanban)框架、極限編程(ExtremeProgramming)框架

　　2.1Scrum框架

　　在Scrum框架中，用戶需求首先被收集、匯總，用以生成各種功能描述。然后各功能描述被分類、組合進而生成關聯任務。非關聯任務包括系統維護、技術升級等工作。各種任務匯聚在一起組成的列表構成產品待辦清單。Scrum中的迭代周期稱為沖刺(Sprint)，通常為2周到4周。每個Sprint周期會從產品待辦清單中選取部分任務組成Sprint待辦清單。Scrum團隊通過每日例會、評審會議來對Sprint開發進度和產品質量進行把控。

　　Scrum建議每個項目都至少配有一個敏捷專家(Scrummaster)和一個產品負責人(Projectowner)。敏捷專家負責遵循敏捷框架，為項目團隊提供指導和培訓，消除阻礙團隊進行工作的障礙和干擾。產品負責人負責明確項目利益相關者的期望，確定項目開發工具和技術，對迭代周期內的各種事項進行優先級排序。

　　2.2看板框架

　　看板框架的核心是將工作流程可視化。在看板框架中，復雜工作會被分解為一個個界限明確、難易適度的任務“卡片”，然后分配給相應團隊或個人。通過可視化管理能夠有效幫助人們識別項目的運轉情況、降低溝通成本，也有助于整個團隊發現任務“過剩”或“不足”的問題，及時調整任務計劃。

　　2.3極限開發

　　總地來說，極限開發與Scrum框架非常類似，都是通過短周期迭代完成系統開發任務。不同的是，在極限開發中，迭代開發周期更短，通常為1到2周;極限開發允許對迭代周期內的待辦事項進行調整，只要該事項還未開始;極限開發團隊嚴格按照待辦任務的優先級來完成開發工作，而不是隨機挑選[1]。

　　此外，極限開發還提供諸如結對編程(pairprogramming)、測試驅動開發(test-drivendevelopment)、精簡設計(simpledesign)等實操方法用以指導團隊的開發工作。

　　3.敏捷開發在SaaS項目中的適用性分析

　　3.1從項目目標來看敏捷開發的適用性

　　如前文所述，SaaS產品在開發初期，最終客戶很少會參與到項目決策當中，因此開發團隊對客戶的使用目標是通過預期分析得到的，這很可能造成產品功能與實際需要之間存在偏差。為減少偏差，開發團隊會持續跟蹤用戶反饋，在推進開發工作的同時，不斷對系統進行調整，完善整體功能架構�？梢哉f，在SaaS系統開發過程中會面臨諸多的不確定因素，因此系統是否具備高適應性便顯得尤為重要。

　　適應變化是敏捷開發的重要特點之一。通過一次次的迭代開發，不斷縮小產品與客戶預期之間的差距。即便既定的目標發生重大改變，采用敏捷開發的產品也能很好的適應。

　　此外，敏捷開發規定每次迭代結束后，都需向用戶提交最小可行產品(Minimumviableproduct,MVP)。MVP的關鍵在于，它不僅能向客戶展示各種可行的解決方案、讓客戶直觀體會到產品價值，而且通過不斷完善的功能，在增強客戶信心和期待的同時，能夠讓開發團隊對客戶需求有進一步的認識，為下一次的迭代開發做好準備。

　　3.2從項目團隊看敏捷開發的適用性

　　在傳統開發模式中，每個開發階段都對應不同部門。從需求分析、架構設計到研發、測試、項目實施，每個步驟都需要部門之間相互配合、分工協作，由此便產生了紛繁復雜的項目文件、對接文檔。一旦項目目標或者客戶需求發生改變，項目進行變更、調整的成本極高，因此涉及的各方人員都會產生抵觸情緒。

　　而敏捷開發團隊結構是趨向扁平化的，職能的劃分由此變得模糊。在項目中，產品經理要理解系統，研發要懂得設計，測試要熟悉客戶，而全部成員都要理解產品的設計理念。通過及時的、面對面的交流，降低了溝通成本，使得整個團隊可以更加專注于產品本身。通過激勵團隊成員，團隊中的每個個體都可以將其自身特點和創造力充分發揮，從而讓項目更具有生命力。

　　3.3從項目開發過程來看敏捷開發的適用性

　　3.3.1需求

　　在傳統開發模式中，需求明確的過程由需求分析師(Businessanalyst，BA)負責進行。其他人員只能被動等待。

　　而在敏捷開發中，團隊不必一次性明晰所有問題，以核心流程和核心業務為重點制定出迭代計劃后，團隊就可以啟動首輪的開發工作。其他細節可以留待隨后的開發過程中逐步填充進來。

　　3.3.2計劃

　　在傳統開發模式中，項目計劃是以里程碑模式形成的，即在需求、開發、測試、上線、初驗、終驗等過程提交相應成果。任何一個過程的延遲，都會對后續階段的工作產生重大影響。

　　而敏捷開發以增量迭代為目標，每個迭代周期結束時，提供對應的增量成果即可，這大大提高了項目的可執行性。

　　3.3.3測試

　　測試在傳統開發模式中往往是最后一環，也是最為困難的一環。由于測試后置，一些異常處理、極限處理的問題在開發時極易被忽略。而這些隱患會對系統集成測試產生重大影響，進而導致部分功能進行重構。

　　而敏捷開發提倡測試先行。以極限編程為例，其要求團隊開發人員，在系統需求分析階段就開始編寫代碼級的測試用例，這樣可以讓開發人員積極參與到需求討論和分析中來，從而深刻理解需求本質。

　　軟件開發論文范例：關于計算機軟件開發技術的相關探討

　　4結束語

　　敏捷開發是一種全新的軟件開發模式，其初衷是為了讓開發過程能夠適應快速變化的需求，使開發的系統具備更多的靈活性。這些都滿足SaaS系統的開發需求。因此敏捷開發適用于SaaS系統開發。

　　參考文獻

　　[1]Cohn,Mike.DifferencesBetweenScrumandExtremeProgramming.2007-4-6.

　　作者：顧超