廣泛應(yīng)用敏捷開發(fā)的分析與研究

王蕾

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

關(guān)鍵詞 敏捷；靈活性；持續(xù)性；高效性

中圖分類號(hào)：TP3 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1671-7597（2014）02-0007-01

同其他生產(chǎn)穩(wěn)定的工業(yè)產(chǎn)品比較而言，參與人員多樣化、開發(fā)周期靈活、更新速度快的軟件產(chǎn)品是一種相對(duì)特殊的商業(yè)產(chǎn)品。為了適應(yīng)市場(chǎng)環(huán)境以及復(fù)雜的用戶群體，不論是處于研發(fā)期還是已經(jīng)投入使用的軟件都常常面臨著變更及升級(jí)的需求。因此，變更可以看作是軟件的一般屬性，正是因?yàn)檫@個(gè)特殊的產(chǎn)品屬性而使得軟件的研發(fā)過程變得極具創(chuàng)新性和挑戰(zhàn)性。

1 敏捷開發(fā)的優(yōu)勢(shì)及特點(diǎn)

1.1 簡(jiǎn)捷性

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

1.2 靈活性及持續(xù)性

敏捷開發(fā)采用迭代式的開發(fā)流程，它將整體開發(fā)過程分離成多個(gè)逐步細(xì)化但相對(duì)獨(dú)立并“完整”的階段性進(jìn)程，在每一個(gè)階段中開發(fā)人員都能隨時(shí)調(diào)整產(chǎn)品方向。時(shí)下較流行的敏捷方法，如極限編程、Scrum等都有助于團(tuán)隊(duì)成員隨時(shí)了解產(chǎn)品的進(jìn)程，并基于整體的需求對(duì)構(gòu)件進(jìn)行深入研究并制定相應(yīng)的修改措施，從而幫助產(chǎn)品及時(shí)地適應(yīng)因需求變更帶來的改變。

較之傳統(tǒng)的設(shè)計(jì)模型如瀑布模型，敏捷開發(fā)更適用于頻繁變更的現(xiàn)代軟件產(chǎn)品研發(fā)。瀑布模型并不崇尚開發(fā)過程中的變更，它要求客戶在產(chǎn)品設(shè)計(jì)初期就提出詳盡的需求，并將后續(xù)的開發(fā)工作，如分析、設(shè)計(jì)、編碼、測(cè)試及客戶支持都建立于此基礎(chǔ)之上。正是因?yàn)檫@種環(huán)環(huán)相扣的設(shè)計(jì)開發(fā)模式，使得我們不難理解為什么變更不被傳統(tǒng)的設(shè)計(jì)模式所崇尚及接受，也正是由于傳統(tǒng)設(shè)計(jì)模式在處理需求變更時(shí)的阻力及粘滯性使得敏捷開發(fā)的優(yōu)勢(shì)變得尤為顯著。基于敏捷的靈活性和可變性，開發(fā)團(tuán)隊(duì)可在開發(fā)過程中及時(shí)根據(jù)客戶的意見對(duì)產(chǎn)品做出調(diào)整和反饋，而這種時(shí)效性是傳統(tǒng)設(shè)計(jì)模式所不能達(dá)到的。

1.3 參與性及高效性

敏捷中所涉及的參與并不僅僅是開發(fā)團(tuán)隊(duì)中各個(gè)角色的參與，更重要的是讓客戶參與到產(chǎn)品開發(fā)中來。在傳統(tǒng)開發(fā)模型中，客戶通常是分離在開發(fā)過程之外的，因此客戶只能在產(chǎn)品交付時(shí)感知到期望產(chǎn)品與實(shí)際產(chǎn)品的差異?？蛻糇鳛槔嫦嚓P(guān)者在傳統(tǒng)的開發(fā)模型中通常作為給予命令的一方而與開發(fā)團(tuán)隊(duì)對(duì)立，但是在敏捷開發(fā)中，他們則扮演開發(fā)團(tuán)隊(duì)中成員的角色。換言之，客戶并不只是在產(chǎn)品開發(fā)初期提出需求，在最終產(chǎn)品交付時(shí)進(jìn)行檢查審核，而是參與整個(gè)開發(fā)過程并基于對(duì)當(dāng)前工作的深度了解而提供更好的支持和更及時(shí)合理的意見。這種合作模式為客戶同實(shí)施開發(fā)人員的意見交流提供了更加便捷的環(huán)境，進(jìn)而幫助開發(fā)團(tuán)隊(duì)避免在最終產(chǎn)品交付時(shí)出現(xiàn)差異化的可能性。

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

敏捷開發(fā)更能夠幫助利益相關(guān)者明確需求并減少無效工作。通常，開發(fā)團(tuán)隊(duì)需要在開發(fā)初期逐步理解并幫助客戶精確認(rèn)識(shí)到對(duì)于產(chǎn)品的預(yù)期目標(biāo)，該過程會(huì)伴隨著整個(gè)開發(fā)過程，在傳統(tǒng)的開發(fā)模式下，最終可操作產(chǎn)品的交付通常會(huì)經(jīng)歷一段相當(dāng)冗長的階段，客戶只能在最終產(chǎn)品交付時(shí)才會(huì)發(fā)現(xiàn)產(chǎn)品缺陷，這段已消耗的時(shí)間很可能影響其后續(xù)的工作或是整個(gè)項(xiàng)目。敏捷開發(fā)避免了缺乏時(shí)效性的溝通，從而增強(qiáng)了客戶的滿意度，繼而使得整個(gè)開發(fā)進(jìn)程更加高效。

1.4 團(tuán)隊(duì)建設(shè)

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

2 結(jié)束語

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

參考文獻(xiàn)

[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