敏捷開發(fā)管理模式是否適合軟件外包企業(yè)

莊贇祺

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

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

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

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

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

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

（一）SCRUM

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

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

（二）DSDM

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

（三）XP

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

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

（一）溝通的威力

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

（二）勇于面對(duì)改變

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

（三）迭代是趨于完美的過(guò)程

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

（四）質(zhì)量保證

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

四、結(jié)束語(yǔ)

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

參考文獻(xiàn)：

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

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