榮國平,張 賀,邵 棟,王 青

1(計算機軟件新技術國家重點實驗室(南京大學),江蘇 南京 210093)

2(中國科學院 軟件研究所,北京 100190)

1 背景與概念介紹

一個完整的計算機系統通常是由硬件以及運行其上的軟件所組成.這其中,軟件從誕生開始,其規(guī)模以及在一個完整計算機系統中所占的比重一直呈現上升趨勢.類似硬件產品的“摩爾定律”(即:硬件產品的性能,每隔約18個月性能翻番,成本下降),軟件產業(yè)也有一個類似的“摩爾定律”,即:類似功能的軟件產品的規(guī)模每隔18個月,其規(guī)模(比如代碼行)會翻倍,而用戶獲取該軟件或者服務的代價將會下降[1].Humphrey收集整理了一些典型軟件產品中規(guī)模(單位為千行代碼)隨著時間推移的變化趨勢(如圖1所示)[2].我們從中可以發(fā)現:在一些系統軟件產品(例如,IBM 的軟件產品和微軟 NT產品)和應用軟件產品(例如,航空領域軟件系統和電視機中的嵌入式軟件系統)中,軟件系統的規(guī)模都隨著時間的推移呈現出明顯的上升趨勢.“摩爾定律”給軟件系統的開發(fā)和維護帶來很多負面影響:首先,軟件規(guī)模的不斷擴大,會使得軟件開發(fā)益發(fā)困難,由此帶來成本超支、交付延后以及質量低劣等問題;其次,為了緩解摩爾定律的影響,尤其為了盡可能地避免收益下降,軟件供應商還需盡快交付產品或者服務,這將使得前述由于規(guī)模擴大所帶來的影響更加突出.此外,如果考慮到軟件在一個計算機系統中的比重也在不斷增加,那么軟件行業(yè)的“摩爾定律”對整個計算機系統的研發(fā)和交付的影響也將逐漸增加,進而對由“軟件定義的世界”的社會生活各個方面帶來巨大影響.

Fig.1 Moore’s law in software industry[2]圖1 軟件行業(yè)的摩爾定律[2]

從一定程度上看,上述各個問題就構成了所謂的“軟件危機”的關鍵要素.為了解決上述問題,對軟件開發(fā)進行有效的組織與管理非常重要,由此誕生并且演化了一系列的所謂軟件過程與方法.這其中,諸如瀑布模型、敏捷方法、CMMI模型以及DevOps等也已經成為軟件行業(yè)幾乎無人不知的概念.然而,如此眾多的模型和方法的提出,能否解決軟件開發(fā)(以及運維)的組織與管理問題?或者在多大程度上解決了這些問題?這就需要我們深入剖析上述模型或者方法的特征,系統分析和理解這些模型和方法被提出的緣由,并在此基礎上進行合理的決策、規(guī)劃和組織.本文正是基于這個目的,試圖在軟件工程概念提出50周年之際,將軟件開發(fā)的組織與管理相關方法的脈絡梳理清楚,從而在一定程度上回答上文提出的問題.

要將此事闡述清楚,我們首先需要對兩個非常容易引起混淆的概念進行明確的定義和解釋,即軟件項目管理和軟件過程管理(改進).從一定程度上說,目前在軟件開發(fā)的組織與管理中出現的大量方法上的爭議和由此帶來的各種誤解以及混亂,其根源就在于對上述兩個概念區(qū)分不夠清晰.

1.1 軟件項目管理

軟件項目管理被稱為規(guī)劃和帶領項目團隊的藝術和科學[3].顧名思義,其管理的對象是各類軟件項目.具體而言,軟件項目管理是應用方法、工具、技術以及人員能力來完成軟件項目,實現項目目標的過程.整個軟件開發(fā)過程中的目標識別、狀態(tài)跟蹤以及偏差糾正是軟件項目管理的三大核心要素.完整的軟件項目管理包含很多內容,例如成本和工作量的估算、計劃和進度跟蹤調整以及風險分析與控制等,都屬于軟件項目管理的范疇(可以參考第6版PMBOK來了解項目管理知識領域).盡管抽象概念上具有相似性(例如,所有管理活動都應該包含目標識別、狀態(tài)跟蹤以及偏差糾正這三大核心要素),軟件項目管理的具體方法和實踐會因為項目特征的差異呈現出不同的特點.軟件項目管理需要借鑒一些本領域或者其他領域的經驗教訓,由此產生了一些用來描述這些經驗和教訓的概念,例如軟件過程、生命周期模型等.下面分別加以介紹.

· 軟件過程

軟件過程是為了實現一個或者多個事先定義的目標而建立起來的一組實踐的集合[4].這組實踐之間往往有一定的先后順序,作為一個整體來實現事先定義的一個或者多個目標.需要特別指出的是:這里面所提及的一個或者多個目標就是軟件項目管理試圖要實現的目標,例如成本、工期以及質量等典型目標.因此,好的軟件項目管理離不開合理的軟件過程.一般來說,當我們討論過程改進的相關概念時,技術(包括工具)革新、人員培訓以及流程優(yōu)化等均屬于軟件過程改進的內容.因此,我們認為軟件過程也應該包括上述 3個方面在內.為了以示區(qū)別,我們可以將軟件過程區(qū)分為狹義的過程和廣義的過程:狹義的過程就是前文描述的一組有先后順序的實踐;廣義的軟件過程則應該包括技術、人員以及狹義過程這 3部分,如圖2所示.過程的作用則不僅僅是這個三角形中的一極,它更加關鍵的作用是連接技術和人員的粘合劑.只有將技術、人員以及狹義過程三者融合成一個整體,才是一個真正可以指導工作的軟件過程.在某些文獻中,會使用軟件開發(fā)方法[5,6]或者軟件開發(fā)過程等術語,其含義類似于狹義的軟件過程.從這個意義上說,諸如凈室 Cleanroom 方法[7]、極限編程 XP(extreme programming)[8]方法、SCRUM[9]方法、DSDM(dynamic systems development method)方法[10]、FDD(feature driven development)方法[11]、Gate方法[12]等均為軟件(開發(fā))過程;而更一般地,敏捷軟件過程/方法、輕量型過程/方法以及重型過程/方法等描述也是恰當的(使用這些形容詞來描述軟件過程的特征是否合理,我們在下文還將進一步討論).一個軟件過程既可以覆蓋從需求到交付的完整生命周期,也可以僅僅包括某些特定開發(fā)階段.例如,一個實現(implementation)過程就可能包括詳細設計、編碼、代碼評審、編譯以及單元測試等更為細小的開發(fā)步驟.甚至,為了確保代碼評審工作的完成質量,我們也可以進一步定義、管理和改進代碼評審過程.

Fig.2 A generalized software process includes techniques,people and narrowly defined software processes圖2 廣義軟件過程包括技術、人員以及狹義過程

· 生命周期模型

生命周期模型與軟件開發(fā)過程(即狹義軟件過程)的概念很像.在很多場合,甚至也會直接以某個特定的生命周期模型來指代某種軟件開發(fā)過程或方法.例如最為常見的瀑布開發(fā)方法,既是指一種以單一線性順序為特征的軟件過程,同時也是指一種常見的生命周期模型.但是,這兩者之間還是有一些細小的區(qū)別.

· 首先,生命周期模型是對一個軟件開發(fā)過程的人為劃分.同樣的軟件開發(fā)過程,因為目的不一樣,可能會被劃分和命名成不同的生命周期模型.例如,為了突出后續(xù)驗證確認階段與上游開發(fā)階段之間的對應關系,一個單一順序的軟件開發(fā)過程可以劃分和命名成V模型.但是,同樣的軟件開發(fā)過程,通常也可以劃分成為一個典型的瀑布模型;

· 其次,生命周期模型是軟件開發(fā)過程的主框架,是對軟件開發(fā)過程的一種粗粒度劃分.所有的生命周期模型往往只描述一個完整軟件開發(fā)過程的主要階段,而不會給出某個階段的內部具體細節(jié).比如:在一個典型的瀑布模型中,會包含一個需求分析階段;然而需求分析階段的具體步驟和流程,則一般不會在生命周期模型中給出描述;

· 最后,生命周期模型往往不包括技術實踐.生命周期模型的提出,主要是為了使大規(guī)模的軟件開發(fā)變得易于控制和管理,本質上仍然是分治法策略的應用.因此,生命周期模型中往往只定義管理實踐(例如,項目計劃、風險分析等);而一些典型的技術類實踐(例如,重構、測試驅動開發(fā)等)則不會出現在生命周期模型的描述當中.

典型的生命周期模型包括瀑布模型、迭代式模型、增量模型、螺旋模型以及原型法等.這些生命周期模型可以視作一個經典軟件過程的模版或者主框架,為進一步定義可行性更高、更具指導意義的軟件過程提供了基礎.當然,生命周期模型的這種特點,也使得當我們試圖理解和研究某個軟件項目開發(fā)的組織與管理時,僅僅考察所使用的生命周期模型是遠遠不夠的,還應深入到具體的軟件開發(fā)過程和開發(fā)實踐中.

1.2 軟件過程管理

我們在很多文獻中都能看到項目管理應當包括對軟件過程的管理這樣的論述.事實上,這種說法并不恰當.顧名思義,軟件過程管理,其管理對象正是上一節(jié)討論的軟件過程,而這種管理的直接目的是為了讓軟件過程在開發(fā)效率、質量等方面有著更好的性能績效(performance).如果將軟件項目管理視作傳統行業(yè)的產品生產管理的話,軟件過程管理則應該是對生產該產品的流水線的設計、建設、維護、優(yōu)化以及升級改造.軟件過程管理一般包括了軟件過程的建立、執(zhí)行、監(jiān)控、評估以及改進等活動.為了更好地開展軟件過程管理,我們同樣需要積累相關活動的經驗教訓,形成了若干可以參考的模型和方法,這其中最著名的軟件過程管理參考模型之一可能就是能力成熟度模型 CMM[13]以及其后續(xù)的集成模型 CMMI[4,14].探討一下該模型在實踐中被誤用和曲解的若干場景,可能有助于我們進一步理解軟件過程管理的概念.

· 首先,CMM/CMMI并不是一種具體的軟件過程或者軟件開發(fā)方法.

在不少文獻中,CMM/CMMI都被視作一種官僚化和教條主義的重型軟件過程,并且與當前軟件開發(fā)大環(huán)境格格不入.事實上,按照CMM/CMMI模型的要求,一個軟件組織應當定義適應本軟件組織特點的軟件過程,并且不斷優(yōu)化該過程,以更好地實現軟件組織的商業(yè)目標.然而實踐中,軟件組織往往為了迎合基于 CMM/CMMI模型的“證據驗證(verification)”(另外一種評估方法稱為“證據發(fā)現(discovery)”,因為實施代價高昂,極少被采用)評估方法,刻意準備大量文檔化證據,導致 CMM/CMMI被視作在軟件項目管理中必須滿足的某種標準(這一點類似于幾乎所有的ISO系列標準的貫標審核).顯然,這是對CMM/CMMI模型意圖和使用方法的曲解.

· 其次,CMM/CMMI并不能作為檢驗軟件過程優(yōu)劣的標準.

實踐中,很多人會將達到一定成熟度水平視作某個軟件組織的研發(fā)能力,并且試圖進行橫向比較,認為成熟度較高的企業(yè),其研發(fā)能力應該強于成熟度較低的企業(yè).在Leon J.Osterweil那篇影響極大的論文中,也將CMM/CMMI視作是檢驗過程優(yōu)劣的標準[15].而事實上,由于企業(yè)所處的環(huán)境以及要實現的目標等方面的差異,過程改進對于不同企業(yè)的含義是不一樣的.因此,成熟度等級不適宜脫離企業(yè)環(huán)境直接橫向比較;同處于相同的成熟度等級,也并不能說明這些企業(yè)的研發(fā)能力也是相同的.

· 最后,將CMM/CMMI與其他軟件過程或者軟件開發(fā)方法的比較是沒有任何意義的.

很多人習慣于將CMM/CMMI作為敏捷方法的對立面[16-18],試圖來解釋和說明敏捷方法的優(yōu)勢.事實上,這種語境之下所謂的“CMM/CMMI方法”其實已經不是一個過程管理的參考模型了,而是某個特定軟件組織為了迎合或者滿足 CMM/CMMI評估的需要所定義出來的某個具體軟件過程.顯然,將這個為了特定目的而定義出來的軟件過程的缺點視作CMM/CMMI模型的缺點是不合適的.

關于軟件過程管理,還需說明一點,按照Humphrey在《Managing the Software Process》[19]一書中對軟件過程管理這一術語的解釋來看,所謂“軟件過程管理”應該同時包含按照既定過程的執(zhí)行和不斷提升過程能力兩個方面的內容.因此,軟件過程改進應被視作軟件過程管理的一部分.其常用參考模型就是 PDCA(plan-do-check-act)[20]和 IDEAL(initiating-diagnosing-establishing-acting-leveraging)[21]這兩個過程改進的元模型.但是應該注意的是,軟件過程改進不能脫離現有的過程基礎,否則,過程改進就會成為無根之木.實踐中,軟件過程管理和軟件過程改進兩者不能割裂,既不能脫離改進談管理,也不能脫離管理談改進.因此,像 CMMI和 SPICE[22]這樣的模型,軟件過程管理參考模型和軟件過程改進參考模型兩種說法均可.

1.3 軟件過程的一種多維視角

實踐中,越來越多的人開始意識到:一個合適的軟件過程往往需要通過過程組合和裁剪,將多個不同類型的軟件過程的優(yōu)勢整合起來.例如:Boehm 等人提出一種策略來平衡敏捷和規(guī)范(discipline),從而發(fā)揮兩種類型的軟件過程的優(yōu)勢[23,24];Kuhrmann等人的多項工作都關注在影響軟件過程組合、裁剪和定制的項目上下文(context)特征上,試圖為軟件過程的組合提供參考[25-27].

顯然,為了對過程進行合理的組合和裁剪,必須首先建立起對軟件過程特點的正確理解.目前討論比較多的是將軟件過程分為敏捷和非敏捷兩類[23,28],同時認為,這兩類過程各具優(yōu)勢,有著不同的適用場景.Boehm 等人以“猴”(不能長途負重,但是可以采摘高處水果,比喻敏捷過程)與“象”(適合長途負重,不能采摘高處水果,比喻非敏捷過程)形象地比喻上述兩類過程[23],認為有必要通過組合和裁剪來融合這兩種類型的軟件過程,發(fā)揮各自的優(yōu)勢[23,28].這種方式的風險在于:單一維度往往并不足以描述一個軟件過程的全部特征,因而限制了對軟件過程的全面理解,進而影響了軟件過程元素的合理選擇和組合.例如,盡管同屬于敏捷陣營,XP方法和 SCRUM 方法關注的重點完全不同:前者關注工程實踐,而后者則更多的是一個包含很多管理實踐的過程框架.為了更加清楚地展示軟件過程多維度特征的概念,我們以一個立方體(即3個維度)來刻畫軟件過程特征(如圖3所示),下面分別加以闡述.

Fig.3 A three-dimensional perspective to characterize software processes圖3 刻畫軟件過程特征的三維視角

· 過程實踐(practice)vs.過程框架(framework)

在各種不同的軟件過程中,我們發(fā)現有些過程關注的重點是具體的實踐,而有的過程則提供了相對抽象的整體化管理框架.例如,極限編程 XP是一個關注具體實踐的軟件開發(fā)方法.典型地,在 XP方法中包括了像計劃游戲(planning game)、重構(refactoring)、結對編程(pair programming)以及持續(xù)集成(continuous integration)等典型的軟件工程實踐.這些具體實踐的相應描述為軟件開發(fā)提供了有用的指南.但是,如何來組織整個項目團隊以實現項目的目標,僅僅有這些軟件工程實踐還不夠,還需要有一個整體的過程框架將這些工程實踐裝入其間.例如,SCRUM方法就是一種非常典型的過程框架.SCRUM方法中的典型實踐包括計劃游戲、產品backlog、固定的 timebox、短迭代周期的 sprint、每日站立式會議、燃盡圖等.這些實踐以管理實踐為主,整個過程框架則提供了項目的全景圖.顯然,一個可以工作的軟件過程應當既提供整體觀(即過程框架),讓過程使用者(即工程師)形成統一的項目愿景;同時也應該提供非常具體的實踐指南,讓過程使用者知道該如何完成每一項關鍵任務.因此,實踐中我們可以看到,XP和 SCRUM 整合是非常常見的做法[29].此外,作為側重提供管理類實踐指導的 PSP(personal software process)[30]和TSP(team software process)[31]整合,也一定程度地體現了實際可工作的軟件過程應當兼有過程框架和具體實踐這一要求.

· 團隊(team) vs.個人(individual)

現代軟件開發(fā)一般都會以團隊形式展開,以期縮短從需求到上線之間的時間.因此,大部分軟件過程關注的都是團隊這一層級.相對而言,只有極少數軟件過程關注個體層次,例如PSP過程和Cleanroom方法.然而值得注意的是:即便軟件項目的開發(fā)是以團隊形式進行,在整個過程中,大部分的工作都是軟件工程師以個人工作的方式進行的,例如詳細設計、編碼以及單元測試等等.軟件項目的進度其實是取決于參與其間的每一位軟件工程師個體的工作進度,軟件系統的質量亦如此.從這個意義上說,指導和規(guī)范個體軟件工程師工作的軟件過程同樣是不可或缺的.Turk等人也指出:“團隊成員應該具備足夠的經驗和技能來定義和改進軟件,從而實現敏捷過程.這就要求軟件團隊應當由聰明、能干和經驗豐富的人來組成.”[32].顯然,軟件工程師不是天生具備上述技能的,因此軟件過程也應當關注個體軟件工程師,指導他們工作,幫助他們成長.

· 反應式(reactive) vs.前攝式(proactive)

這個維度描述的是在應對軟件開發(fā)過程中各種變更時的處理方式.顧名思義:反應式指的是在變更發(fā)生之后再應對,而前攝式則是在變更發(fā)生之前采取措施來減少發(fā)生變更的可能.更一般化地,我們也可以把變更推廣為軟件項目進展過程中的各類問題.相應地,反應式軟件過程和前攝式軟件過程則代表了兩種不同的項目管理策略.大部分敏捷(agile)方法都可以歸為反應式軟件過程.我們使用“反應式”和“前攝式”的主要目的是為了打破敏捷方法和非敏捷方法之間的傳統界限,便于過程的組合(process composition)和定制.例如,軟件重構(refactoring)盡管是一個典型的敏捷實踐,但是大部分情況下,軟件重構的目的是為了改善代碼結構,以應對未來可能的變更,減少返工代價.從這個意義上說,軟件重構應該歸為具有前攝特征的一個軟件工程實踐.只有打破上述傳統界限,才能使得在軟件過程的組合和定制時具有足夠的靈活性.

按照多維度的方法來刻畫軟件過程特征,XP方法可以用三元組(practice,team,reactive)來表示.類似地,TSP則可以表述為(framework,team,proactive).顯然,我們還加入了更多正交的維度進一步刻畫軟件過程的特征,為系統化的軟件過程組合提供條件[33].我們以XP、SCRUM、PSP以及TSP為例(見表1)來解釋軟件過程多維視角下的過程組合方式.例如:前文已經討論過,一個好的過程應該既提供整體觀(framework),也提供具體實踐指導(practice)[27,33].從這個意義上看,XP和SCRUM組合、PSP和TSP組合、PSP和SCRUM的組合以及XP與TSP的組合都是比較合理的過程組合方式;相反地,XP和PSP的組合以及SCRUM和TSP的組合則不大合理.在主流科研文獻搜索引擎上的檢索結果也表明,前者的組合方式(即 practice和 framework的組合)的相關研究顯著多于后者.此外,按照 Turk等人的提法[32],軟件過程還應該為個體軟件工程師提供實踐指導.從這個意義上說,除了PSP和TSP的天然組合之外,將PSP融入到其他軟件過程的做法也值得研究.事實上,研究者已經開展了一些相關工作[34-37].相比較于單一維度(即敏捷與非敏捷),多維度視角下的過程特征識別和過程組合顯然具有更好的針對性和可操作性.

Table 1 Characterization and composition of software process表1 軟件過程的特征刻畫和組合

2 軟件過程發(fā)展史

伴隨著軟件規(guī)模從數十行到數千萬行(甚至接近不可計數(部分原因是現代軟件系統的邊界已經越來越模糊,例如,基于互聯網的很多系統都是由大量的軟件服務(子系統)組合而成,很難定義邊界))這樣的發(fā)展歷程,其相應的軟件過程的演化也成為一段波瀾壯闊的發(fā)展史.期間出現的構成體系的軟件過程和方法有數十種,如果加上這些過程的一些變化,更是不計其數.正如前文討論的那樣,軟件項目管理是為了確保項目目標的達成.那么相應地,軟件過程則是軟件項目管理經驗的匯總,成為后續(xù)項目的參考,更好地支持項目管理目標的實現.因此,探討一下軟件項目目標達成所面臨的困難和挑戰(zhàn),對于我們理解不同的軟件過程是有益的.Brooks在《沒有銀彈》一文中總結了軟件開發(fā)的四大本質(essential)難題,即復雜度、一致性、可變性以及不可見性[38],一直被業(yè)界廣為認同.嚴格來說,只有不可見性是軟件的固有屬性,不會因為軟件項目的上下文環(huán)境的不同而發(fā)生變化;另外 3個本質困難都會隨著軟件項目上下文環(huán)境的不同而變化.這 4個本質難題對軟件項目管理帶來的挑戰(zhàn)往往相互促進,例如:隨著軟件開發(fā)的復雜度的提升,一致性、可變性以及不可見性所帶來的對軟件開發(fā)的負面影響也會不斷增加.在軟件發(fā)展的不同歷史階段,由于技術發(fā)展、應用領域以及商業(yè)環(huán)境等因素的影響,除了不可見性之外,另外 3個不同的本質難題的凸顯程度往往不一樣.例如,盡管互聯網時代的軟件系統比以往更為復雜,但是,由于要服務海量的最終用戶,軟件系統的可變性(需求變更)和一致性(快速演化)的問題反而更加突出.為了適應這種差異和變化,不同歷史時代的軟件過程也往往呈現了不同的特征.我們以軟件發(fā)展的 3個主要歷史階段為主線,梳理軟件過程的演化歷史,從中我們可以更加清楚地觀察到這一現象.

2.1 軟/硬件一體化(20世紀50年代～70年代中葉)

這是計算機軟件從萌芽狀態(tài)慢慢發(fā)展的一段時間.總體上,軟件是以硬件附屬品的形式存在,而不會單獨存在.當然,隨著技術的發(fā)展和人們觀念的轉變,軟件的地位也一直在上升.圖4描述了在企業(yè)IT方面的支出中,軟件成本和硬件成本比例的變化趨勢.如果我們假定“摩爾定律”對硬件和軟件的影響類似,那么我們可以明顯地看到,軟件的地位在不斷上升.大體上,軟/硬件一體化階段依據軟件在一個計算機系統中的比例可以細分為如下兩個階段.

Fig.4 Large organization hardware-software cost trends[39]圖4 大型企業(yè)中軟/硬件成本變化趨勢[39]

· 軟件完全依附于硬件階段

軟件在這個階段完全處于萌芽狀態(tài).有一些主要的特征決定了這個時代的軟件過程是非常接近硬件開發(fā)流程的.例如:軟件往往是用來支持硬件完成一些計算任務,其功能相對單一,復雜度有限,幾乎也不需要考慮軟件的需求變更;其次,作為計算資源的硬件,其每小時使用成本遠大于支付給軟件開發(fā)者的報酬;最后,項目團隊往往也是以硬件工程師和數學家為主,軟件工程師作為一種職業(yè)同樣是萌芽狀態(tài)[40].相應地,這個階段的軟件過程有著非常明顯的硬件工程過程特征,例如,往往采用線性的類似于瀑布模型的流程;同時,一些典型的硬件工程口號得到推崇,例如“measure twice,cut once”.對應到軟件領域,那就是對所編寫的代碼進行反復的多次檢查,確保無誤后,再上機計算.圖5是這個階段非常典型的軟件過程,我們可以看到線性順序的過程結構和大量規(guī)格定義的活動.

· 軟件作坊階段

隨著技術的進步,人們對計算機系統的認識加深,軟件應用領域也得以擴展.相應地,社會對軟件人員數量的需求也隨之增加,很多非軟件領域的人員涌入了軟件開發(fā)領域.所以,整個20世紀60年代的軟件開發(fā)極具軟件作坊特征.當然,還有其他一些原因,使得這個時代的軟件過程具有輕量級的特征:首先,大部分軟件功能仍然比較簡單,規(guī)模不大,復雜度有限,因此即便出錯,其錯誤修改代價也不大;其次,出現了一些更好的軟件開發(fā)基礎設施(例如高級程序語言),使得快速完成功能的編碼并且調試修改成為可能.此外,質疑權威的文化盛行,導致了牛仔式的個人英雄主義產生.上述這些因素,使得整個20世紀60年代最盛行的軟件過程就是所謂的“編碼加改錯(code and fix)”方式.盡管這種方式在現代軟件工程當中被認為是糟糕的做法,但從當時的角度來看,仍然不失為一種適應軟件需求時代特征的合理做法.當然,即便在20世紀60年代,也并不是所有的軟件都是規(guī)模小且復雜度低的軟件.因此,當“編碼加改錯”這樣的軟件過程應用在相對復雜的軟件開發(fā)中時,其問題也就出現了.除了極少數成功案例(如IBM的OS-360)之外,大量的有一定規(guī)模的軟件項目都失敗了,直接導致了在20世紀60年代末NATO科學委員會召集兩次會議[41,42]討論“軟件危機”,并且提出了“軟件工程”的概念.

Fig.5 Software development process for SAGE which is similar to hardware development process[43]圖5 類似硬件過程的SAGE軟件開發(fā)過程[43]

2.2 軟件成為獨立的產品(20世紀70年代～90年代)

盡管以盈利為目的的軟件公司在20世紀60年代已經出現,但是真正發(fā)展起來的軟件公司還是出現在20世紀 70年代之后.很明顯的特征就是軟件作為獨立的產品出現了.由于擺脫了硬件束縛,同時也受到用戶期望的影響,軟件的功能越來越強大,相應的軟件系統規(guī)模和復雜度也顯著增加.此外,由于軟件開始服務于更多領域的用戶,尤其是20世紀80年代出現了個人計算機之后,普通人作為軟件的主要用戶開始出現在歷史舞臺.這直接導致除了復雜度和不可見性之外,軟件功能需求的多樣化(以及變更)以及軟件產品兼容性要求(一致性)等開始變得重要起來.某種角度上說,Brooks總結的軟件開發(fā)的本質難題在這一階段才真正引起整個行業(yè)的廣泛認同.結合前文提及的軟件“摩爾定律”,商業(yè)公司所面臨的挑戰(zhàn)不僅僅是上述這些軟件開發(fā)本質難題,還有時間上的壓力,即:需要盡可能快速地將軟件產品推向市場,以期獲得較高的收益.

很明顯,盛行于20世紀60年代的牛仔式開發(fā)方法已經不能適應這個時代的軟件開發(fā)了.作為矯枉措施,兩種軟件開發(fā)方法在這個階段的初期獲得了重視:其一是形式化方法[44,45],該方法試圖通過數學手段證明程序的正確性,從而確保軟件產品質量;其二是自頂向下的結構化方法以及相應的瀑布生命周期模型[46].這其中,瀑布模型值得解釋一下.事實上,這也是業(yè)界對軟件過程誤解最多的概念之一.如圖6所示,這是一個典型的瀑布模型,其特征是,基本上順序的開發(fā)流程以及在每一個階段采用先嘗試后展開(即build it twice)的開發(fā)策略.如果仔細閱讀Royce論述瀑布模型的論文[46],我們會有如下發(fā)現.

· 首先,Royce提出的瀑布模型并不像大部分文獻中提及的簡單順序模型(在圖6中去掉左下角的嘗試過程以及每個階段的回溯步驟);

· 其次,Royce提出的瀑布模型也不是單一模型,事實上,他提出的是從先設計再開發(fā)、設計文檔化、“Build it twice”、規(guī)劃和監(jiān)控測試以及引入客戶這樣一個軟件開發(fā)過程的改進路徑;并且,他認為,隨著過程元素的增加,開發(fā)成功可能性會提升,但是開發(fā)成本也會上升,因此,開發(fā)團隊應該做好兩者之間的平衡;

· 最后,也不像很多文獻中提及的那樣,Royce本人對這樣的生命周期模型在大型軟件開發(fā)中持否定態(tài)度.事實上,他認為采用這樣的一個軟件過程是非常有必要的,尤其是考慮到大型軟件開發(fā)往往比預想的要更為復雜,因此,不能用過于簡單的軟件開發(fā)方法來應對.非常可惜的是,他的建議并沒有引起足夠的重視,直接導致了一個概念簡單、但是官僚死板的瀑布模型(DoD-Std-2167)[47]被廣為傳播,并且成為后來大部分“新”型軟件開發(fā)過程的擁躉對比和攻擊的對象.

Fig.6 Royce waterfall model[32]圖6 Royce提出的瀑布模型[32]

形式化方法在擴展性和可用性方面存在不足,而順序瀑布模型則被解讀成一個重文檔、慢節(jié)奏的開發(fā)過程.因此進入到20世紀80年代,如何提升生產效率和開發(fā)質量成為業(yè)界最為關心的話題.從軟件開發(fā)方法的角度看,80年代乏善可陳.然而在這個時代出現了一個影響至今的軟件開發(fā)技術,即面向對象技術.面向對象技術不僅有效緩解了復雜度、不可見性、一致性和可變性等軟件開發(fā)本質難題給軟件開發(fā)帶來的困難和挑戰(zhàn),也直接影響了軟件開發(fā)過程.例如,RUP(rational unified process)過程[48,49]就是一個典型的例子.仔細研究RUP過程,我們可以發(fā)現,它的流程定義、概念和術語、相關支持工具,幾乎都是圍繞著面向對象技術而展開的.面向對象技術的一些衍生技術,例如面向方面編程AOP(aspect oriented programming)、領域驅動設計DDD(domain-driven design)等,則在后來的軟件開發(fā)方法中也被廣為應用.20世紀80年代出現的另一個具有標志性意義的工作是以CMM 為代表的軟件過程改進參考模型,由于 CMM 不是一種軟件過程,這在前文已經有很多討論,這里不再贅述.

盡管沒有直接體現在軟件過程和開發(fā)方法的變化上,20世紀80年代的技術進步還是為20世紀90年代大量過程和方法的涌現奠定了基礎.當然,這一切的背后離不開軟件發(fā)展的新動向.

2.3 網絡化和服務化(20世紀90年代中期迄今)

進入20世紀90年代,人們對軟件的使用方式出現了一些變化:一方面,作為獨立于硬件存在的軟件,其功能繼續(xù)復雜化,規(guī)模繼續(xù)擴大(軟件“摩爾定律”);其次,軟件的用戶數量繼續(xù)增加,尤其到了后期,隨著互聯網和移動互聯網時代的到來,一款軟件系統或者線上服務動輒擁有百萬級以上的用戶量.同時,由于競爭的需要,需求不確定性和系統的快速演化成為一個日益突出的問題.最后,軟件分發(fā)和使用方式也出現了顯著的變化,從典型的光盤復制逐漸過渡到基于網絡的服務形式,即SaaS(software as a service)[50],使得軟件系統的版本更迭時間有了大為縮短的潛力.這些新情況的出現,使得軟件開發(fā)的四大本質難題中,可變性和一致性對軟件開發(fā)的影響更為突出,因而也催生了整個軟件過程歷史上最為紛繁的一個時代,大量的軟件過程在這個階段涌現出來.其中,具有迭代式開發(fā)特征的一系列軟件開發(fā)方法逐漸得到軟件行業(yè)的廣泛接受和應用.迭代式開發(fā)歷史悠久,其出現時間甚至可以前推至20世紀50年代[51].迭代式開發(fā)不適合視為一種具體的開發(fā)過程,例如,產生于20世紀80年代的增量式模型[51]、螺旋式模型[52]以及原型法[53]等均具有迭代式開發(fā)特征.盡管在細節(jié)上有些小的差別,但其本質都是類似的,即:將一個大型軟件系統的開發(fā)過程視作一個逐步學習和交流的過程,軟件系統的交付不是一次完成的,而是通過多個迭代周期,逐步來完成交付.顯然,這種方式與之前流行的單一順序過程有著顯著差異.如果說在此之前,迭代式開發(fā)只是軟件開發(fā)方法的選項之一,在軟件發(fā)展進入網絡化和服務化階段,具有這種特征的軟件過程得到業(yè)界的空前重視,演化出了一系列新方法.這些新的軟件開發(fā)方法在項目實踐中逐漸形成體系,終于在2001年的“雪鳥會議”上,17位軟件工程實踐者達成共識,以“敏捷”一詞來描述這些軟件過程的主要特征[54].

· 敏捷軟件開發(fā)方法

敏捷軟件開發(fā)(agile software development)是一組強調在不確定和混亂的情況下適應軟件需求快速變化的、基于迭代式開發(fā)的軟件開發(fā)方法和實踐.當前,敏捷方法是一種主流軟件開發(fā)方法,廣泛應用于各種軟件開發(fā)中,也包括很多規(guī)模較大的軟件開發(fā)中.

敏捷軟件開發(fā)主要由有經驗的軟件工程師和咨詢師提出,而非來自于學術界的研究成果.在 2001年“雪鳥會議”期間,與會者形成了一些關于軟件開發(fā)的共同觀點,即敏捷宣言[54]:“個體和互動勝過流程和工具;可以工作的軟件勝過詳盡的文檔;客戶合作勝過合同談判;響應變化勝過遵循計劃”.該宣言定義了敏捷軟件開發(fā)的核心價值觀和原則,而這些原則具體是由敏捷實踐以及敏捷實踐的組合——敏捷方法來實現的.

敏捷體系的一種比較公認的解構方式是按5個層次劃分,分別是價值觀、原則、方法、實踐和工具(如圖7所示).越是高層,其概念就越抽象,相應地,其內容也就越少.因此,我們可以用一個金字塔形狀來形象地描述敏捷體系的5個層次.

Fig.7 Five-Layers of agile method圖7 敏捷的5個層面

隨著敏捷軟件開發(fā)的發(fā)展,敏捷方法的數量逐漸增多,目前大約存在 20種左右的敏捷方法,這其中最受關注的敏捷方法主要有SCRUM、XP和Kanban[29,55],下面分別簡單加以介紹.

· SCRUM:著重于項目管理,尤其適用于難以提前完全規(guī)劃好的項目.

SCRUM 以經驗過程控制理論為依據,采用迭代、增量的方法來提高產品開發(fā)的可預見性并控制風險.SCRUM框架包括一組SCRUM團隊和與其相關的事務.SCRUM團隊以自組織、跨職能和迭代方式工作.典型地,一個SCRUM團隊有3個角色:(1) SCRUM Master,負責確保成員都能理解并遵循過程;(2) 產品負責人,負責最大化SCRUM團隊的工作價值;(3) 團隊,負責具體工作.SCRUM利用時間盒實現規(guī)律性.SCRUM中的Sprint是貫穿于開發(fā)工作中保持不變的一個月(或更短時間)迭代.所有的Sprint都采用相同的SCRUM框架,并且都交付潛在可發(fā)布的最終產品增量.

· XP(extreme programming):極限編程著重于軟件開發(fā)的最佳實踐.

早期的XP包含12個實踐:計劃游戲、短周期迭代、隱喻、簡單設計、測試、重構、結對編程、代碼集體所有制、持續(xù)集成、40小時工作制、在線客戶、編碼標準.2004年修改后的XP引入了更多的實踐,同時將這些實踐區(qū)分為基本實踐(例如坐到一起、完整團隊、結對編程等)和擴展實踐(例如真實客戶參與、增量部署、每日部署等).XP方法也有一個迭代式的過程框架,用來組合上述實踐.但是 XP過程框架中的管理實踐較少,后來逐漸被SCRUM取代.SCRUM和XP的組合,一度也成為敏捷開發(fā)的標準配置.

· Kanban:Kanban(看板)是日語單詞,是“可視卡片”(或標志)的意思.

在豐田公司,看板專指將整個精益生產系統連接在一起的可視化物理信號系統.看板的主要規(guī)則有:

(1) 可視化工作流:把產品切分成小塊,將每一塊寫在一張卡片上,然后將卡片貼到墻上;墻上的每一欄都有名稱,以此顯示每張卡片在工作流中所處的位置;

(2) 限定在制品WIP(work in progress):針對工作流的每個狀態(tài),明確限定正在進行中的工作項數量;

(3) 衡量并管理周期時間:完成一個工作項的平均時間,有時稱為前置時間(更貼切的術語可能應該是流通時間).優(yōu)化流程,讓周期時間盡可能短并盡可能可預測.

Pekka等人[56]分析了各種敏捷方法,并給出了它們之間的演化關系(由于此文發(fā)表于2003年,因此沒有包含看板方法和精益軟件開發(fā)方法),如圖8所示.

Fig 8 Evolution of agile method[56]圖8 敏捷方法演化圖[56]

如果以2001年敏捷宣言的提出作為敏捷方法的里程碑事件,我們可以發(fā)現:敏捷方法往往都從一些早期軟件工程實踐演化而來,而不是憑空出現.此外,這些方法出現的時間也較為集中,基本符合前文所述軟件逐漸走向網絡化和服務化的這一發(fā)展階段.換句話說,也正是這一發(fā)展階段,軟件的特點使得具有類似特點的一系列軟件過程被大量地應用在當時的各個軟件項目開發(fā)當中.

伴隨著敏捷軟件開發(fā)的發(fā)展,關于敏捷軟件開發(fā)方法和之前的傳統軟件方法(原文使用“傳統”一詞來描述單一順序過程,我們并不完全認同用這個詞匯)的爭議也越來越多.Nerur給出了兩者的區(qū)別(見表2)[57].

Table 2 A comparision between traditional software development and agile development[57]表2 傳統軟件開發(fā)與敏捷軟件開發(fā)的對比[57]

Version One公司每年都會進行一次全球敏捷開發(fā)的調查,目前已經進行了11次.雖然這不是嚴格意義上的學術研究,但在工業(yè)界和學術界的影響力都非常巨大,是持續(xù)時間最長、參與人數最多的敏捷調查.2018年發(fā)布的第11次敏捷狀態(tài)調查報告指出,94%的受調查者所在的企業(yè)使用敏捷方法.報告宣稱的敏捷帶來的益處排在前3位的是:(1) 88%的被調查者認為,敏捷幫助他們獲得了管理變更優(yōu)先級的能力;(2) 83%的被調查者認為提高了項目的可視化;(3) 83%的被調查者認為提高了團隊生產力.對于具體的敏捷方法,排在前3位的方法分別是SCRUM(58%)、SCRUM/XP整合(10%)和Custom Hybrid自定義(8%)[58].

敏捷方法作為與基于計劃的傳統軟件開發(fā)方法相對的軟件工程方法,從誕生開始就面對著眾多的爭議.很多實踐者往往從個人的經驗和觀點出發(fā)進行爭論,缺乏嚴謹的科學基礎.也有很多學者和實踐者并不認同敏捷軟件開發(fā),他們認為,沒有足夠的科學證據支持敏捷所宣稱的益處.對此,許多研究者對敏捷軟件開發(fā)開展了大量實證研究來確定敏捷軟件開發(fā)的有效性和局限性,同時也展示了當前敏捷軟件開發(fā)在工業(yè)界的使用情況供實踐者參考.

· 開源軟件開發(fā)方法

開源軟件(open source software)是一種源代碼可以任意獲取的計算機軟件.開源軟件開發(fā)方法是伴隨著互聯網在全球的快速發(fā)展而興起的.以Linux為例,Linux起步發(fā)展的時間(1993年～1994年)與Internet在全球的快速發(fā)展幾乎是同步的.嚴格來說,開源軟件開發(fā)方法的說法略顯牽強,更為確切的說法應該是一種基于并行開發(fā)模式的軟件開發(fā)的組織與管理方式.這種方法依賴于分散在全球的開發(fā)者和使用者的協作,而只有Internet才能為這種大規(guī)模協助提供交流溝通的工具.廉價的Internet是Linux模式得以發(fā)展的必要條件.

在缺乏自頂向下的嚴格項目管理和傳統上大家認可的軟件工程最佳實踐的情況下,開源軟件開發(fā)方法取得了巨大的成功,Eric Steven Raymond在《大教堂與集市》[59]一文中對開源軟件開發(fā)方法進行了深入分析.Eric提出了“Linus定律”:“如果有足夠多的beta測試者和合作開發(fā)者,幾乎所有問題都會很快顯現,然后自然有人會把它解決.”同時,Eric給出了一些具有指導意義的實踐,例如“早發(fā)布,常發(fā)布,傾聽用戶的反饋”“把你的用戶當成開發(fā)合作者對待,如果想讓代碼質量快速提升并有效排錯,這是最省心的途徑”“設計上的完美不是沒有東西可以再加,而是沒有東西可以再減”等,也得到了很多軟件開發(fā)者的接受和認同.

作為一種軟件開發(fā)方法,開源軟件開發(fā)的貢獻者(contributor)缺乏嚴格的人員和任務上的管理.為了保證開源軟件的質量,開源社區(qū)一般都有嚴格的代碼提交社區(qū)審核制度.開發(fā)者通常一次只允許提交少量代碼.代碼提交后會觸發(fā)社區(qū)代碼審核,經過開發(fā)社區(qū)的主要貢獻者(committer或maintainer)確認后才能夠通過代碼配置系統整合到代碼主分支上.

隨著開源軟件的快速發(fā)展,眾多軟件企業(yè)開始使用開源軟件或者將開源軟件集成到自己的商業(yè)軟件中.小到個別功能模塊,大到整個 IT基礎設施,我們都可以看到各種開源軟件的存在.同時,眾多軟件企業(yè)開始投入資源參與社區(qū)開源軟件的開發(fā).比如:Intel公司貢獻了大量Linux核心代碼;IBM貢獻了Eclipse;Google、Facebook、Netflix等公司均將公司內部很多項目開源,一方面為軟件社區(qū)提供了優(yōu)質的軟件,同時也加速了公司自身的軟件開發(fā)速度和質量.不僅如此,不少大型軟件公司也開始嘗試將開源軟件開發(fā)方法引入到內部的商業(yè)軟件開發(fā)中,提出了所謂的“內部開源(inner source)”方法[60],也獲得了很好的效果.

此外,開源軟件開發(fā)方法還啟發(fā)了一種稱之為眾包(crowdsourcing)[61]的軟件開發(fā)組織方式.眾包的方式繼承了開源軟件開發(fā)的大部分實踐,但與傳統開源軟件開發(fā)方法還存在一些差異.例如:在眾包方式下,往往是由確定的管理者(個人、小組或者公司)來主導軟件開發(fā)的內容和軟件系統的演化走向,管理者發(fā)布開發(fā)任務,而貢獻者往往會因為完成開發(fā)任務而獲得一定的報酬(類似一種雇傭關系);而在傳統的開源軟件開發(fā)中,貢獻者與開源系統的管理者之間是一種相對對等的關系,管理者一般不會向社區(qū)發(fā)布明確的開發(fā)任務,而貢獻者更多的是以服務自己和社區(qū)的目的來完成開發(fā)工作,一般都是無償的.

· DevOps

進入2000年,隨著互聯網應用的日益普及,用戶對軟件系統和服務提出了更多的要求,“多快好省”已成為大多數互聯網時代軟件用戶的基本期望.具體而言,功能要豐富、更新要及時、要穩(wěn)定可靠同時用戶獲取服務的成本不能過高.然而,有一些因素卻制約著這樣的目標的達成.

· 首先,由于互聯網時代的用戶已經經歷了較為長期的信息時代的熏陶,對于軟件產品和服務已有較為深入的理解;而作為軟件產品和服務的提供方,為了吸引用戶和流量,往往都提出了以用戶為中心的口號,綜合起來,用戶的需求多樣性問題更加突出;

· 其次,軟件產品和服務的地位已經從輔助社會生活發(fā)展到不可或缺的狀態(tài);服務宕機已經越來越成為一種難以接受的情形;

· 最后,長期信息化建設的結果使得軟件產品或者服務的部署環(huán)境錯綜復雜,軟件系統從通過測試到在生產環(huán)境部署和應用之間的鴻溝日益凸顯.

所有這一切,都使得人們對軟件產品和服務的需求與軟件產品和服務的開發(fā)能力之間越來越不匹配(請注意,這正是軟件危機的起源).DevOps[62,63]這種方法應運而生.從起源來看,DevOps是敏捷開發(fā)的延續(xù),它將敏捷的思想延伸至運維(operation)階段,以期快速響應變化和交付價值.目前,DevOps方法已對軟件產業(yè)產生了深遠影響,越來越多的軟件企業(yè)開始采用這種新的模式.DevOps之所以產生如此巨大的影響,我們認為這不是偶然的.這種方法本身具有的特性非常適合在:(1) 需求很難確定;(2) 需要快速響應變更;(3) 需要快速提供價值;(4)需要高可靠性、安全性等這樣的所謂互聯網時代軟件環(huán)境中得到應用.限于篇幅,完整闡述DevOps方法不大可能,我們簡單地對若干DevOps典型實踐和技術進行總結,從中可以大致理解DevOps是如何解決前文提及的“多快好省”的問題的.

· 首先,DevOps的方法論基礎是敏捷軟件開發(fā)、精益思想以及看板 Kanban方法.這是一種鼓勵快速迭代、同時盡快向用戶交付價值的軟件過程.用戶往往在項目早期就可以使用軟件系統的部分功能,并在其后持續(xù)獲得系統的更新和升級;

· 其次,以領域驅動設計為指導的微服務架構方式,幫助用戶重塑和分解組織業(yè)務架構,解耦復雜應用系統,從而支持不中斷服務的系統更新;

· 第三,大量虛擬化技術的使用,使得開發(fā)測試環(huán)境與生產環(huán)境幾乎沒有差別,新的功能模塊(或者服務)封裝在容器中,以類似集裝箱形式快速部署到生產環(huán)境中;

· 第四,一切皆服務XaaS(Xas a service)的理念指導,不僅大大降低了開發(fā)、部署和運維的難度,同時也降低了使用成本.甚至一些云服務提供商提出了函數即服務FaaS(function as a service)[64,65]的概念,按照函數執(zhí)行期間所需資源計費,極大地提升了計算機關鍵資源(例如 CPU、網絡等)空閑時間的利用率,從而大大降低了使用成本;

· 第五,構建了強大的工具鏈,支持高水平自動化.代碼從編寫完成到部署上線,幾乎不需要人工干涉.

上述這些實踐不是各自獨立的,而是需要相互配合以支持前文提及的軟件開發(fā)目標.從一些行業(yè)調查數據來看,我們觀察到了一些在以往難以想象的提升.比如,在不中斷服務的情況下,Google公司的服務更新達到了每天5 000次,Amazon的更新則達到了23 000次以上[66].作為一種新的軟件開發(fā)和運維方法,DevOps在工業(yè)界已有大量的應用和探索.相對而言,學術界對 DevOps的相關研究起步較晚,對這種方法的局限性的認知還不夠系統和全面.

3 發(fā)現和反思

綜合前文的梳理和討論,我們總結若干發(fā)現如下,試圖為軟件組織與管理方法在軟件過程元素的選擇、組合以及定制方面提供一些參考.

發(fā)現1.Brooks在《沒有銀彈》一文中總結的軟件開發(fā)四大本質難題,跨越了時代但仍然具有啟示意義.

在很多文獻中,會使用“傳統”一詞來描述歷史上的一些重型方法(尤其是瀑布方法),用以區(qū)分敏捷方法.事實上,作為敏捷方法基石之一的迭代式開發(fā)方法或者增量式開發(fā)方法起源于20世紀50年代,興盛于20世紀70年代,遠遠早于敏捷方法被正式提出的年代[51].此外,作為敏捷方法中極為關鍵的一種實踐,測試驅動開發(fā)(test driven development),其前身Test First Development在水星計劃(project mercury)中已開始應用,而其時代則可追溯到20世紀60年代.我們可以看到:軟件過程和管理方法試圖要解決的問題,過去發(fā)生了,現在還在發(fā)生著,未來還會繼續(xù)存在.正如 Brooks所總結的那樣,這是軟件開發(fā)中的一些本質(essential)的挑戰(zhàn)和困難.這一方面暗示著我們不大可能找到有效的方法來徹底解決這些問題;而另一方面也表明,我們在探索過程中逐漸積累的經驗也不會因為時代的變遷而消亡.

發(fā)現2.管理方法和過程不會獨立于技術而存在.

從面向對象技術的產生,并且由此引發(fā)了 20世紀 90年代軟件開發(fā)方法的大量涌現,我們就可以觀察到這樣的現象.正如軟件過程的定義(如圖2所示),廣義過程本來就應該包含技術元素在里面.另外一個典型的例子是 DevOps方法,如果沒有微服務架構設計和云計算來支撐,軟件系統功能的高質量和高頻交付是難以想象的.從這個意義上說,如何將管理實踐和技術實踐有機融合在一個軟件過程中,應成為在軟件過程的組合和定制時重點考慮的內容.

發(fā)現3.人的因素還是居于主導地位.

這一點是毋庸置疑的.軟件開發(fā)本質上看是智力勞動,因此整個開發(fā)過程中沒有辦法將人的因素完全排除掉.事實上,在廣義軟件過程中,人員也是其中的一極.比較公認的開始重視人在軟件開發(fā)中的影響以兩本書為代表,即《程序開發(fā)心理學》[67]和《人件》[68].其實,現代軟件工程方法都非常重視人的因素,幾乎所有現代流行的軟件工程方法都鼓勵自主方式(self-directed)的軟件項目開發(fā)[9,30].

發(fā)現4.相比較于軟件的發(fā)展,軟件過程具有滯后性.

這個原因易于理解,因為軟件過程本身就是經驗教訓的總結.往往都是在現實中出現軟件開發(fā)能力不能支持人們對軟件需求和期望這樣的問題之后,相應的軟件過程和開發(fā)方法才會開始演進,以解決上述問題.從這個意義上說,除非要解決的問題出現顯著變化,否則,對軟件過程的研究和探索的重點則仍然應該放在如何更好地使用現有過程和方法上,而不必去創(chuàng)造新的方法.

發(fā)現5.迭代式方式將成為主流方法.

受到應用大環(huán)境的影響,當前軟件開發(fā)所要解決的問題盡管仍然可以歸結為經典的 4個本質難題,但在程度上與過往相比已經有了翻天覆地的變化.某種角度上來說,單一的順序型開發(fā)過程很難在當前的軟件開發(fā)過程中得到應用,迭代式開發(fā)方法已經成為一種主流方法,甚至在未來較長時間內,應該都是主流方法.這種方式鼓勵的快速交付和反饋,使得用戶、開發(fā)者以及作為連接橋梁的軟件系統三者之間的互動更加頻繁,用戶和開發(fā)者對當前所需解決的問題以及未來演變的理解可以快速取得一致.顯然,這非常適合于當前越來越趨向于網絡化和服務化的軟件系統開發(fā)和使用的發(fā)展趨勢.

發(fā)現6.反應式開發(fā)最終應向前攝式發(fā)展.

軟件開發(fā)尤其是現代軟件開發(fā)面臨著很多不確定性,提升應變(reactive)能力是非常必要的.盡管如此,從控制風險、提升質量、降低返工成本等因素出發(fā),軟件過程仍然應該引入更多具有前瞻(proactive)特性的過程元素,在不確定中找到確定性因素,并進而強化確定性,消除不確定性,應該是一種基本的軟件項目開發(fā)策略.事實上,我們前文已經討論過,原型法、螺旋式開發(fā)以及以迭代式作為基礎模型的大量敏捷方法都將軟件開發(fā)過程當成是一個逐步學習和交流的過程,在這個過程中,開發(fā)者和用戶對軟件系統的理解越來越趨向一致,從而消除很多不確定因素.從這個意義上說,都是反應式開發(fā)發(fā)展成前攝式開發(fā)的策略的體現.

發(fā)現7.簡潔、直觀的過程.

我們發(fā)現,能夠讓開發(fā)者廣為認同和使用的軟件過程幾乎都有一種外在的簡潔.軟件開發(fā)本身具有的復雜性和不可見性已經使得開發(fā)者之間的交流面臨著諸多困難,因此,為了能夠形成一致的愿景,所使用的軟件過程必須具有一種外在的簡潔性.整個軟件系統應如何開發(fā)?應分成哪些階段?每個階段要實現什么樣的目標?每個階段與整體之間的關系是什么?諸如此類的問題,需要整個開發(fā)團隊達成共識.正因如此,我們不難理解具有外在簡潔性的SCRUM方法之所以能夠長期占據各類敏捷方法首位的原因[29].當然,按照Royce的說法,簡單的軟件過程是不能應對復雜軟件項目的開發(fā)的.因此,僅僅保持外在的簡潔是不夠的,還需要盡可能詳細地規(guī)劃每個主要開發(fā)階段的具體流程,才能形成一個具有指導意義的可以工作的軟件過程.

發(fā)現8.對軟件過程標簽敏捷或者非敏捷沒有意義.

國內外軟件過程社區(qū)都習慣于用敏捷或者非敏捷來給某種軟件過程或者軟件開發(fā)方法作標簽.同時,熱衷于通過各種案例來對比各自優(yōu)缺點,并試圖提出一些方法來選擇和定義合適的軟件過程.應該說,這種方式鮮有經得起推敲的成功案例:首先,對于敏捷或者非敏捷,事實上并沒有公認的標準,因此,敏捷和非敏捷的界限是模糊的,判斷某種方法是敏捷或者非敏捷,并沒有堅實的科學依據;其次,分屬于兩個陣營中的典型實踐其本質可能與該陣營宣稱的理念并不相符,甚至對立.例如:計劃驅動往往會被認為是非敏捷陣營的做法,然而,幾乎所有的敏捷過程都有一個計劃游戲的實踐來完成估算和項目計劃.這類項目的進度也經常被要求進行跟蹤,出現了偏差就需要糾正,確保實際進展與計劃一致.很明顯,這就是典型的計劃驅動做法.再比如:在很多文獻中,規(guī)范(disciplined)也被認為是敏捷的對立面[23].事實上,當我們觀察整個軟件過程的發(fā)展歷史時發(fā)現,不追求規(guī)范的那段時間恰恰就是軟件開發(fā)處于極度混亂的時期.盡管后來的形式化方法或者 Cleanroom方法有矯枉過正之嫌,但后續(xù)的一些軟件過程和方法對規(guī)范的要求其實一直都很高.例如,有些文獻把 XP列為規(guī)范要求最高的軟件開發(fā)方法之一[23].因此,敏捷或者非敏捷這種單一維度區(qū)分軟件過程特征的方式可能會帶來很多概念上的誤導和實踐中的混亂.應用本文提出的多維視角來理解軟件過程特征,進而選擇和定制軟件過程可能更為合理.

4 總 結

我們梳理并澄清了軟件組織與管理方面的若干概念,盡管這些概念早已存在,然而,大量的文獻中都采取了混為一談的方式來處理這些概念,從而導致很多理念上的爭議和實踐中的躑躅.更加嚴重的是:這樣的混亂使得我們在面臨特定軟件項目環(huán)境中,仍然不清楚如何有效選擇、組合和定制軟件開發(fā)過程,從而更好地實現項目目標,盡管這是軟件過程相關研究和實踐的基本目的.有鑒于此,我們結合軟件開發(fā)的四大本質困難在不同歷史時期的演變,論述了軟件過程的歷史演變,從中試圖探索事物發(fā)展規(guī)律,指導實踐.

本文的主要貢獻如下.

· 首先,梳理并澄清了軟件組織與管理方法中的兩個基本概念,即軟件項目管理和軟件過程管理.盡管看起來是實踐者本來應該掌握的概念,但在實踐中,這兩個概念被頻繁地曲解,導致很多爭論和理解混亂.如果不對上述兩個基本概念加以區(qū)分,軟件的組織與管理無法闡述清楚.事實上,這個問題在現有的相關主題的文獻中,是一個相當普遍的問題;

· 其次,我們提出了一種多維視角來刻畫軟件過程特征的方法.這不僅提供了對軟件過程特征更為清晰而準確的描述,同時也為軟件過程的組合、定制以及演化改進提供了基礎.相比較于用“敏捷過程”“傳統過程”等方式描述軟件過程的特征,我們提出的多維視角粒度更細,也打破了上述不同方法陣營之間的壁壘.同時,一些過程選擇和組合的基本規(guī)則,在多維視角之下也更加直觀,也更加容易實現;

· 第三,我們系統梳理了在不同歷史時期軟件開發(fā)的特征和相應的軟件過程的演變.發(fā)現:隨著軟件應用的發(fā)展,Brooks總結的軟件開發(fā)四大本質難題中的復雜性、可變性和一致性的相對重要性會發(fā)生變化,從而推動了軟件過程和開發(fā)方法相應的進行調整.在這個過程中,技術的發(fā)展是一個不容忽視的因素;

· 最后,我們總結了若干發(fā)現和反思,試圖為實踐者在軟件過程的選擇、組合以及定制時提供一些參考.