廣泛應用敏捷開發的分析與研究

王蕾

摘 要 敏捷開發自20世紀90年代提出以來逐漸引起人們的廣泛興趣，近些年來，許多大型知名軟件企業對敏捷開發的應用也逐步積累了一定的實踐經驗。文章主要立足于探索敏捷的優勢，探究分析了敏捷為何在充滿挑戰的軟件開發過程中受到青睞。

關鍵詞 敏捷；靈活性；持續性；高效性

中圖分類號：TP3 文獻標識碼：A 文章編號：1671-7597（2014）02-0007-01

同其他生產穩定的工業產品比較而言，參與人員多樣化、開發周期靈活、更新速度快的軟件產品是一種相對特殊的商業產品。為了適應市場環境以及復雜的用戶群體，不論是處于研發期還是已經投入使用的軟件都常常面臨著變更及升級的需求。因此，變更可以看作是軟件的一般屬性，正是因為這個特殊的產品屬性而使得軟件的研發過程變得極具創新性和挑戰性。

1 敏捷開發的優勢及特點

1.1 簡捷性

敏捷開發崇尚簡單的建模方案。相比于在建模初期設計一個宏偉的能夠實現所有功能的軟件開發框架，敏捷開發更傾向于從客戶的基礎需求出發，并在后續的開發中基于此需求逐步細化并進行擴充。在大多數情況下，客戶的需求是頻繁變更的，而需求的變更將導致已建立完備的設計框架失去效用，并且失去效用的構件數量將與開發框架的細化程度成正比。也就是說，初期的模型計劃得越周全，隨著后續開發過程中需求的變更，那些完善的細節設計被修改或丟棄的可能性就越大，從而造成大量的資源浪費。反觀框架式的策略模型設計，大多數簡潔并且靈活的基礎設計在修改時并不耗費過多的資源，甚至在不符合新的需求變更時，由于并不消耗過多的資源而可被輕易的丟棄。

1.2 靈活性及持續性

敏捷開發采用迭代式的開發流程，它將整體開發過程分離成多個逐步細化但相對獨立并“完整”的階段性進程，在每一個階段中開發人員都能隨時調整產品方向。時下較流行的敏捷方法，如極限編程、Scrum等都有助于團隊成員隨時了解產品的進程，并基于整體的需求對構件進行深入研究并制定相應的修改措施，從而幫助產品及時地適應因需求變更帶來的改變。

較之傳統的設計模型如瀑布模型，敏捷開發更適用于頻繁變更的現代軟件產品研發。瀑布模型并不崇尚開發過程中的變更，它要求客戶在產品設計初期就提出詳盡的需求，并將后續的開發工作，如分析、設計、編碼、測試及客戶支持都建立于此基礎之上。正是因為這種環環相扣的設計開發模式，使得我們不難理解為什么變更不被傳統的設計模式所崇尚及接受，也正是由于傳統設計模式在處理需求變更時的阻力及粘滯性使得敏捷開發的優勢變得尤為顯著。基于敏捷的靈活性和可變性，開發團隊可在開發過程中及時根據客戶的意見對產品做出調整和反饋，而這種時效性是傳統設計模式所不能達到的。

1.3 參與性及高效性

敏捷中所涉及的參與并不僅僅是開發團隊中各個角色的參與，更重要的是讓客戶參與到產品開發中來。在傳統開發模型中，客戶通常是分離在開發過程之外的，因此客戶只能在產品交付時感知到期望產品與實際產品的差異。客戶作為利益相關者在傳統的開發模型中通常作為給予命令的一方而與開發團隊對立，但是在敏捷開發中，他們則扮演開發團隊中成員的角色。換言之，客戶并不只是在產品開發初期提出需求，在最終產品交付時進行檢查審核，而是參與整個開發過程并基于對當前工作的深度了解而提供更好的支持和更及時合理的意見。這種合作模式為客戶同實施開發人員的意見交流提供了更加便捷的環境，進而幫助開發團隊避免在最終產品交付時出現差異化的可能性。

此外，敏捷還十分強調傳統開發團隊中隸屬于不同職能部門中成員間的有效協作和高效溝通。傳統的開發模型按照開發過程中的不同需求將開發進程劃分為不同的階段，而每一階段只負責單一的問題，如需求分析、設計、編碼及測試等，分屬于不同職能部門的開發人員并不與本部門之外的人員產生交集，由此阻礙了彼此間的交流。迭代式的敏捷開發同時聚集了來自不同領域的專家，并保證其共享開放的工作空間，因此促進了開發團隊中成員間的信息流通，繼而有效地避免由于信息誤解或低效率傳播而帶來的成本消耗。

敏捷開發更能夠幫助利益相關者明確需求并減少無效工作。通常，開發團隊需要在開發初期逐步理解并幫助客戶精確認識到對于產品的預期目標，該過程會伴隨著整個開發過程，在傳統的開發模式下，最終可操作產品的交付通常會經歷一段相當冗長的階段，客戶只能在最終產品交付時才會發現產品缺陷，這段已消耗的時間很可能影響其后續的工作或是整個項目。敏捷開發避免了缺乏時效性的溝通，從而增強了客戶的滿意度，繼而使得整個開發進程更加高效。

1.4 團隊建設

使用敏捷模型的團隊成員每天都有可能面對需求變更，這將促使他們保持開放的心態和思想，時刻準備著使用前沿的科技甚至創造新的科技去解決棘手的問題，這樣的工作模式可以幫助開發人員提高應對突發問題的技能。此外，由于敏捷開發中團隊成員共享工作空間，因而保障了成員間的交流以及知識的傳播，與其他部門成員間的學習能夠促進和加深對彼此工作的理解，并建立有利于團隊建設的隱性情感依附。還需要強調的一點是，敏捷團隊中的成員都是作為項目的所有者存在，項目中的所有信息都是對等公開的，無等級制的透明化信息制度能夠更好地鼓勵項目成員表達自己的觀點，在促成項目完成的同時也增加了團隊成員的歸屬感。

2 結束語

敏捷通常被認為適用于小型的開發項目。然而在進行大規模的項目開發時是否應該使用敏捷的方法至今仍是研究者們討論的要點。從宏觀上來看，大型的項目始終可以分離成相對獨立的結構構件，那么對這些構件的敏捷即可看作是對整體項目的敏捷反應。也就是說，當把這些適用于敏捷方法的小型構件整合成完整的項目即是在一定程度上對產品的開發使用了敏捷的方法。這種大型項目中構件間的整合并不是簡單的構件堆砌，如何劃分構件以及如何整合構件這些新的問題仍舊需要更多的實踐經歷及案例分析來解答。

參考文獻

[1]T. J. Lehman， A. Sharma. Software Development as a Service： Agile Experiences. 2011 Annual SRII Global Conference （SRII）， Mar.-Apr. 2011.

[2]L. Cao， B. Ramesh， T. Abdel-Hamid. Modeling dynamics in agile software development. ACM Transactions on Management Information Systems， Vol.1，NO.1， Dec. 2010.

[3]M. Glas， S. Ziemer. Challenges for Agile Development of Large Systems in the Aviation Industry. Proceedings of the 24th ACM SIGPLAN conference companion on Object oriented programming systems languages and applications， pp.901-908， Oct. 2009.endprint