莊贇祺

在軟件工程領(lǐng)域，有過很多軟件開發(fā)模型，如瀑布模型、快速原型模型、增量模型、螺旋模型、演化模型、噴泉模型、RAD模型、敏捷軟件開發(fā)模型、XP極端模型。這么多的模型各有各的應(yīng)用場景、各有各的適用范圍。

如今，敏捷開發(fā)被越來越多的開發(fā)企業(yè)和團隊所接受。使用恰當(dāng)，不僅可以顯著提高開發(fā)效率，也可以縮短產(chǎn)品的開發(fā)周期。問題是，“敏捷”方法是否能適用到軟件外包行業(yè)，這個爭論由來已久，各有說辭。作為軟件外包商，我們發(fā)現(xiàn)，在一個長期的合作過程中，如果使用敏捷開發(fā)模式，不僅可行，而且的確能夠形成一個雙贏的局面。

一、敏捷開發(fā)主要理念和框架

敏捷開發(fā)主要以迭代式增量交付為基礎(chǔ)，小批量地交付可工作的軟件，其中一切都是從產(chǎn)品待辦事項列表開始的，我們都知道，大批量的工作同時展開是浪費之源，所以從源頭就需要將大塊頭的任務(wù)進行拆解，借助persona、場景分析、MVP 梳理等過程進行用戶故事的拆分，并進行排序和評估，從而安排每一個迭代的工作。迭代增量式交付一開始看上去總會很美，但很快就會遇到問題，其一是增量式的交付會帶來無止境的回歸測試，其二是不可避免的代碼腐化，其三是盡管需求可以拆分得很小，但由于固定的人只能做固定的事，在調(diào)配資源的時候就會捉襟見肘，這也是很多大公司面臨的問題。

對于這三個問題，敏捷開發(fā)都給出了自己的解決方案，它倡導(dǎo)將質(zhì)量內(nèi)嵌在開發(fā)過程中，質(zhì)量保障工作是貫穿始終的，技術(shù)水平的提升也讓自動化測試、持續(xù)集成成為可能，同時敏捷開發(fā)認(rèn)為代碼總是動態(tài)修改的，所以我們應(yīng)當(dāng)掌握的技能就是重構(gòu)和測試驅(qū)動開發(fā)，好的架構(gòu)是生長出來的，而非幾個架構(gòu)師用PPT 畫出來的，最后提倡學(xué)習(xí)型組織，技能擴展，一專多能的人才是現(xiàn)代軟件開發(fā)中最需要的，所以以特性團隊的方式取代老的組件團隊，一切以交付優(yōu)先，而這也就是PMBOK中提到過的強矩陣和弱矩陣之間的關(guān)系。

二、敏捷開發(fā)的幾種主流方法

（一）SCRUM

SCRUM是一種迭代的增量化過程，用于產(chǎn)品開發(fā)或工作管理。它是一種可以集合各種開發(fā)實踐的經(jīng)驗化過程框架。SCRUM中發(fā)布產(chǎn)品的重要性高于一切。

該方法由Ken Schwaber和 Jeff Sutherland 提出，旨在尋求充分發(fā)揮面向?qū)ο蠛蜆?gòu)件技術(shù)的開發(fā)方法，是對迭代式面向?qū)ο蠓椒ǖ母倪M。

（二）DSDM

DSDM（動態(tài)系統(tǒng)開發(fā)方法）是眾多敏捷開發(fā)方法中的一種，它倡導(dǎo)以業(yè)務(wù)為核心，快速而有效地進行系統(tǒng)開發(fā)像。實踐證明DSDM是成功的敏捷開發(fā)方法之一。DSDM不但遵循了敏捷方法的原理，而且也適合那些成熟的傳統(tǒng)開發(fā)方法有堅實基礎(chǔ)的軟件組織。

（三）XP

XP（極限編程）的思想源自 Kent Beck和Ward Cunningham在軟件項目中的合作經(jīng)歷。XP注重的核心是溝通、簡明、反饋和勇氣。因為知道計劃永遠趕不上變化，XP無需開發(fā)人員在軟件開始初期做 出很多的文檔。XP提倡測試先行，為了將以后出現(xiàn)bug的幾率降到最低。

三、敏捷開發(fā)的優(yōu)勢

（一）溝通的威力

肖伯納有一句名言“England and America are two countries divided by a common language?！币馑际怯兔绹潜灰粋€相同的語言所分隔的兩個國家。這里不是指的地理上的分隔，而是文化溝通上的差異，即便他們都說一種語言。不同的時區(qū)，不同的文化，不同的工作方法和原則，導(dǎo)致溝通成為了我們進行外包的一個瓶頸。敏捷開發(fā)既強調(diào)了溝通，又為順暢的溝通提供了方法和指導(dǎo)。其中持續(xù)的交付實際是在用實實在在的形式進行了項目的溝通，從而降低了最后的交付風(fēng)險。作為傳統(tǒng)開發(fā)模式，比如一個瀑布式的開發(fā)，六個月后，客戶才能第一眼看到自己想要的產(chǎn)品，這里面能產(chǎn)生錯愕的概率有多大，大家可以想象一下。

（二）勇于面對改變

需求變更在整個軟件開發(fā)的生命周期中是一個永恒的話題。也是客戶與服務(wù)提供方最糾纏不清之所在。改變的導(dǎo)火索可以來自方方面面，既有可能是一覺醒來后的靈光一現(xiàn)，也有可能是來自客戶外部商業(yè)環(huán)境的改變。如果處理得當(dāng)，這種變化可能協(xié)助雙方得到一個更優(yōu)秀的軟件，也能讓客戶對你的快速應(yīng)變產(chǎn)生好感。另外，我們總是陷在一個自己預(yù)設(shè)的陷阱里，客戶的要求改變永遠是對功能的增加。其實，一個過程中的再設(shè)計，有可能會降低開發(fā)的成本。

（三）迭代是趨于完美的過程

羅馬不是一天建成的。不要嘗試對完美的一步到位，除非你的用戶愿意犧牲寶貴的進入市場的時機。只用盡最大可能不斷地從客戶那里得到進程中的反饋，進而對開發(fā)加以修正，才不會出現(xiàn)最終和用戶意愿的大偏差。例如在雙方可以接受的情況下，定義若干個短促有效的迭代過程，第一時間發(fā)現(xiàn)問題，放到下一個迭代中去解決。

（四）質(zhì)量保證

敏捷開發(fā)這種快速交付，讓用戶能夠盡快試用你的功能，盡快發(fā)現(xiàn)問題，就整個開發(fā)周期而言，整體質(zhì)量一定會得到提升。在傳統(tǒng)開發(fā)模式中，我們都會或多或少遇到這樣的情況，因為開發(fā)時間的拖延，測試時間永遠是第一個被壓縮的階段。結(jié)果可想而知。更多的迭代引入了更多的測試周期和時間。

四、結(jié)束語

任何一種理論框架我們都應(yīng)當(dāng)辯證地去看，既然是管理項目，我們應(yīng)當(dāng)因地制宜，每一個項目因為它規(guī)模大小、產(chǎn)品面對的市場都有所不同，例如移動APP和大型通信類產(chǎn)品，300人的項目和10人的項目，在項目立項之時我們就應(yīng)當(dāng)確定項目管理的策略，究竟應(yīng)當(dāng)采取什么樣的管理方式、工具、過程，而這個過程恰恰是在PMBOK所處的理論層面上進行，進一步我們可以采用敏捷開發(fā)所提供的工具庫來實現(xiàn)我們的管理框架和策略。

參考文獻：

[1] 陶思俊. 從IT 項目管理看待PMBOK 和敏捷開發(fā)[J]. 邢臺學(xué)院學(xué)報，2015

[2] Taskcity. 再談敏捷開發(fā)的好處及敏捷外包的前景[J]. 51CTO，2009