引子

　　過去十年間，敏捷軟件開發(fā)贏得了大好發(fā)展局面，被眾多不同規(guī)模組織采用^[1]。敏捷方法宣揚一整套價值觀，并且提出了一系列實踐活動去幫助獲得并維護(hù)這些價值。盡管從一開始，敏捷方法常以提升作為工作單元的小團(tuán)隊的效率為中心，但最近有趨勢將敏捷方法拓展到企業(yè)層面^[3]。然而，在企業(yè)層面會產(chǎn)生新的問題，可能需要重新考慮敏捷軟件開發(fā)的某些價值觀與實踐活動。構(gòu)建軟件平臺來實現(xiàn)企業(yè)范圍重用策略，是主要問題之一。在本文中，我列舉了五項首要挑戰(zhàn)，敏捷組織在決心采取軟件平臺戰(zhàn)略時應(yīng)該準(zhǔn)備面對它們。

　　軟件平臺是什么？

　　軟件平臺是由一組子系統(tǒng)和接口構(gòu)成的一個通用基礎(chǔ)架構(gòu)，支撐相關(guān)產(chǎn)品在其上開發(fā)^[4]。可以把軟件平臺看作實現(xiàn)組織層面重用的一個戰(zhàn)略手段。很多組織曾表明，應(yīng)用軟件重用能帶來很多好處，如：減少開發(fā)和測試工作從而更快交付產(chǎn)品、開發(fā)和維護(hù)成本更低、重用部件具備更高品質(zhì)、重用被證明過的解決方案風(fēng)險更低、更容易估算項目的時間與成本。

　　五項首要挑戰(zhàn)

　　采用軟件平臺策略是一個根本性的改變，需要組織重新審視并調(diào)整已有的做法。單就敏捷而言，如果不加考慮地沿用某些敏捷原則和實踐，反而會制造新的挑戰(zhàn)。在本文中，我們會集中討論五個主要問題，即：特性團(tuán)隊、團(tuán)隊自主管理、業(yè)務(wù)價值、代碼所有權(quán)以及穩(wěn)定性。雖然這里列出的可能不是全部，但它們應(yīng)該是最明顯的。另外，根據(jù)組織的不同，這里每一項挑戰(zhàn)對于軟件平臺影響的嚴(yán)重性可能有所差異。

　　1. 特性團(tuán)隊還是組件團(tuán)隊

　　在給定系統(tǒng)中，特性團(tuán)隊通常承擔(dān)端到端職責(zé)，圍繞特性（也就是所謂的故事）展開工作。另一方面，組件團(tuán)隊更側(cè)重于交付一個子系統(tǒng)，這個子系統(tǒng)與其他子系統(tǒng)交互以發(fā)揮作用。敏捷方法重視向最終用戶交付可直接感知的價值，因此更傾向于特性團(tuán)隊而非組件團(tuán)隊，但這并非完全否定組件團(tuán)隊存在的必要性。不過，實施者普遍感覺組件團(tuán)隊總是不那么被看好，從項目經(jīng)理或技術(shù)領(lǐng)頭人那里常聽到下面的論調(diào)：

“我聽說，敏捷界都認(rèn)為組件團(tuán)隊不好，因為它們做不到端到端負(fù)責(zé)。”

　　然而，就平臺開發(fā)而言，有需要把二者結(jié)合起來。例如某些服務(wù) —— 尤其后臺服務(wù)重要且基本，開發(fā)成本昂貴，可能有必要安排專門的組件團(tuán)隊來進(jìn)行維護(hù)，而不應(yīng)交給具體項目中的特性團(tuán)隊去負(fù)責(zé)。

　　特性團(tuán)隊與組件團(tuán)隊的交叉合作很重要。有時需要組件團(tuán)隊來構(gòu)建和維護(hù)特定核心服務(wù)——這些服務(wù)有可能會大范圍影響產(chǎn)品，抑或需要特殊領(lǐng)域知識或?qū)ｉL。有時候需要另外一些與應(yīng)用層有密切互動的組件團(tuán)隊來與特性團(tuán)隊更緊密地合作，以理解他們的需求。

　　為了交付應(yīng)用級特性，特性團(tuán)隊通常承擔(dān)著端到端的職責(zé)。在端到端的開發(fā)中，特性團(tuán)隊除了使用平臺中的服務(wù)，偶爾還需要對平臺做些修改以滿足需要。修改有以下兩種方式：

　　A. 直接修改核心平臺代碼：

　　應(yīng)該允許特性團(tuán)隊填補平臺的欠缺之處，視需要還允許新添一些組件。這是推薦的做法，但首先要滿足以下兩個前提：

1. 特性團(tuán)隊對平臺組件所作的任何修改和擴(kuò)展，都必須經(jīng)過主管該部分的平臺團(tuán)隊的審核。這是為了確保改動技術(shù)上可靠，并且防止違反任何設(shè)計及結(jié)構(gòu)上的規(guī)制和準(zhǔn)則。如果代碼有跨平臺的要求，那么跨平臺性也要納入審核范圍。
2. 特性團(tuán)隊?wèi)?yīng)該有權(quán)對平臺組件進(jìn)行回歸測試，這樣他們就可以在提交更改前在本地針就不同的配置環(huán)境生成產(chǎn)品。否則平臺不穩(wěn)定將造成用戶認(rèn)為平臺不可靠。

　　B. 從核心平臺代碼創(chuàng)建分支

　　有些時候，特性團(tuán)隊所要求的改動，可能與使用平臺的其他產(chǎn)品產(chǎn)生無法解決的沖突。舉例來說，有個新產(chǎn)品需要平臺提供某種行為，而現(xiàn)存組件與要求的行為僅有略微的差別。如果組織覺得同時支持新舊兩種方式有價值，那么有必要讓組件團(tuán)隊和特性團(tuán)隊展開合作，針對所有產(chǎn)品對組件的各方面要求，提煉出其中共通的部分，再充分發(fā)掘差異的部分。可以使用配置管理和可變更性管理的技巧^[6]來支持這個步驟。

　　如果來自應(yīng)用層的某個需求會導(dǎo)致平臺的變更，最好從平臺團(tuán)隊（也就是組件團(tuán)隊）抽調(diào)至少一名成員臨時加入負(fù)責(zé)這個變更的特性團(tuán)隊。特性團(tuán)隊所作的決定要經(jīng)過該名成員確認(rèn)方能生效。這樣的協(xié)作與確認(rèn)會加快審核過程，這種參與還會促進(jìn)組織內(nèi)的知識流通，因為它提供了一個機會讓特性團(tuán)隊里的開發(fā)者更好地理解領(lǐng)域知識并了解跨平臺問題。在日常的Scrum會議中，每一位平臺團(tuán)隊成員都應(yīng)該匯報他們參與特性團(tuán)隊的討論后的結(jié)論（例如所采取的決定、必要的變更）。

　　2. 團(tuán)隊自主管理：

　　還有一個問題可能會妨礙軟件平臺開發(fā)，這就是高度自主管理的團(tuán)隊。當(dāng)一個高度自主管理的團(tuán)隊的成員呆在一起很長時間后，這個團(tuán)隊會有漸漸變成孤島的危險。在組織內(nèi)放任孤島的出現(xiàn)會產(chǎn)生嚴(yán)重的后果，如代碼冗余、可重用資產(chǎn)的低可見度、虛假的重用資產(chǎn)以及平臺分裂等。有時內(nèi)部的關(guān)于平臺的決策發(fā)生沖突，導(dǎo)致出現(xiàn)平臺不同分支，即萌生平臺分裂的情況。再過一段時間后，分支間的差異會巨大到使平臺只能應(yīng)用于某個特定操作系統(tǒng)或產(chǎn)品，甚至于失去共通的基礎(chǔ)模型。

　　再者，高自主性造成團(tuán)隊將特定問題作為團(tuán)隊的內(nèi)部問題去考慮，忽視自身的決策對平臺以及平臺上其他特性團(tuán)隊的影響。而當(dāng)團(tuán)隊和業(yè)務(wù)單元具備聯(lián)邦主義（Federalism，一種治理關(guān)系，常見于較大的敏捷組織）特色時，會給平臺相關(guān)的決策造成更大的挑戰(zhàn)。例如，有時需要就平臺重用與否做決定，是重用現(xiàn)存的平臺，還是換個方向，如單獨為當(dāng)前業(yè)務(wù)目標(biāo)構(gòu)建一個獨立的變體。一方面，公司作為軟件的擁有者，有經(jīng)濟(jì)上的理由推行重用，但在公司層面常常難以兼顧具體業(yè)務(wù)事項錯綜復(fù)雜的全部細(xì)節(jié)，因而下這樣一個決定就很有挑戰(zhàn)性。另一方面，如果做決定的權(quán)力被賦予直接受重用問題影響的團(tuán)隊和業(yè)務(wù)單元，有很多因素都可能把決策過程導(dǎo)向錯誤的方向。試舉一例：單個團(tuán)隊傾向于選擇看得到短期利益的方向，而非從長遠(yuǎn)目標(biāo)來考慮（如維持平臺的生命力）。況且還有“非我發(fā)明（Not-Invented-Here）”綜合癥，會讓團(tuán)隊排斥重用別人開發(fā)的組件，偏好自己另起爐灶。

　　3. 業(yè)務(wù)價值意識：

　　在敏捷組織中很強調(diào)貢獻(xiàn)業(yè)務(wù)價值，這早已被證明為敏捷軟件開發(fā)的重大的優(yōu)勢。不過如果對于什么是業(yè)務(wù)價值理解得不成熟，這種理解的廣泛性反而會成為障礙。障礙并非來自以業(yè)務(wù)價值為導(dǎo)向的思維本身，而是來自圍繞著這種思維產(chǎn)生的誤解。比方說，“只有客戶看得見的才有價值”這樣的觀念就很有害，尤其是在軟件平臺的問題上。下面的論調(diào)不算少見：

“我認(rèn)為所謂價值就是提供給客戶的有用而且能用的功能”^[2]

　　可是業(yè)務(wù)價值并不總是立竿見影，也不一定直接對客戶發(fā)生影響。重構(gòu)即為一例。

　　轉(zhuǎn)換到平臺戰(zhàn)略會帶給組織很多經(jīng)濟(jì)上的好處，但從最終客戶的角度來說沒有變化。在嚴(yán)格根據(jù)對當(dāng)前客戶的影響來衡量業(yè)務(wù)價值的環(huán)境里，很難去激勵團(tuán)隊和個人去接受平臺模式。與能夠和客戶進(jìn)行第一手交流的特性團(tuán)隊相比，可能會錯誤的認(rèn)為專注開發(fā)并且持續(xù)完善核心服務(wù)的團(tuán)隊貢獻(xiàn)的價值較小。因此要對業(yè)務(wù)價值有更深刻的理解，方能將面向客戶與面向業(yè)務(wù)兩方面的價值兼收并蓄。不要只是問：“這個對客戶有什么好處？”，我們還應(yīng)該問：“這個對業(yè)務(wù)有什么好處？”。第二個問題根本上源自第一個問題，畢竟任何業(yè)務(wù)的成功都依賴于它能否滿足當(dāng)前客戶并吸引新的客戶。但是重要的是要明確這個區(qū)別才能糾正認(rèn)識上的偏差。

　　4. 對代碼和產(chǎn)品所有權(quán)意識：

　　團(tuán)隊和產(chǎn)品所有者往往很注意保護(hù)他們的資產(chǎn)和產(chǎn)品，讓轉(zhuǎn)換到平臺戰(zhàn)略更加困難。這主要是因為擁有組件的團(tuán)隊寧愿把這個組件抓在手里，而不愿在平臺里維護(hù)一個共享的組件。而且在平臺語境下，代碼所有權(quán)不像在條塊分割的開發(fā)方式下那樣明確和清晰，平臺里被多個團(tuán)隊和產(chǎn)品共享的組件，說不清該由誰擁有。

　　克服這個問題的方法是宣傳平臺以及其上的產(chǎn)品歸集體所有的思想。這可能需要一個內(nèi)部的開源模式，可以讓特性團(tuán)隊為平臺作出貢獻(xiàn)并對他們貢獻(xiàn)的代碼臨時承擔(dān)起責(zé)任和獲得所有權(quán)，直到它足夠成熟、健壯后再把責(zé)任移交給組件團(tuán)隊。而對產(chǎn)品所有者來說，需要一種更加講求協(xié)作的做法來決定如何把需求傳遞給他們的團(tuán)隊，既要考慮客戶的短期要求還要考慮維持平臺的長期需要。

　　5. 敏捷性與穩(wěn)定性的矛盾：

　　在構(gòu)建平臺的傳統(tǒng)模式里，先平臺后產(chǎn)品的思想占據(jù)統(tǒng)治地位。可以在一些軟件開發(fā)范式中發(fā)現(xiàn)這個思路，例如“軟件生產(chǎn)線工程（software product line engineering）”強調(diào)開發(fā)領(lǐng)域部件而后才是應(yīng)用部件^[5]。這樣的先后順序意味著，在產(chǎn)品下層的平臺的開發(fā)取得實際的進(jìn)展之后，組織才會開始構(gòu)建產(chǎn)品。可在敏捷型的組織里，在軟件平臺開發(fā)上更傾向于采用一種產(chǎn)品驅(qū)動的方式。按照這樣的做法，平臺除了衍生自從現(xiàn)成的產(chǎn)品，也可以從正在進(jìn)行的項目的需求中產(chǎn)生，在這些項目里，開發(fā)中的產(chǎn)品作為平臺的第一批用戶，與被依賴的平臺同時開發(fā)。

　　特別在產(chǎn)品驅(qū)動開發(fā)平臺的情況下，要在平臺的穩(wěn)定性與保持變化的靈活性之間取得平衡很具有挑戰(zhàn)性。雖然在敏捷環(huán)境下團(tuán)隊必須保證對手頭產(chǎn)品積極應(yīng)對以滿足當(dāng)前客戶，但也必須認(rèn)識到平臺穩(wěn)定性非常地關(guān)鍵，因為很多產(chǎn)品依賴這個平臺作為共同基礎(chǔ)，所以應(yīng)該值得信賴，不應(yīng)該變化得過于頻繁。對基礎(chǔ)架構(gòu)組件和核心服務(wù)而言，被放到一個正在進(jìn)行的項目中去面對不斷變化的需求可能會帶來很大的風(fēng)險。

　　當(dāng)產(chǎn)品所有者要求對平臺進(jìn)行修改時，如果牽涉到象可用性（usability）這樣橫向貫穿性的方面，會出現(xiàn)一個兩難選擇。第一個選項是遵循敏捷原則批準(zhǔn)這個變更請求以滿足手頭的客戶，于是所有依賴于變化的這部分平臺的產(chǎn)品都會受到影響從而導(dǎo)致不穩(wěn)定。另一個選項是不理這個請求，在有證據(jù)表明這也是其他產(chǎn)品的共通問題時再加以處理，但要付出引起客戶不滿的代價。

　　要破解穩(wěn)定性與敏捷性的矛盾首先要能夠識別每個需求的實際的業(yè)務(wù)價值。關(guān)鍵的是要權(quán)衡面向業(yè)務(wù)的價值和面向客戶的價值，以此決定應(yīng)該馬上回應(yīng)該請求，還是在證明其是普遍需要前擱置它，還是為了業(yè)務(wù)目標(biāo)而完全忽視它。

　　結(jié)論

　　把敏捷方式拓展到到企業(yè)范圍會產(chǎn)生一些后果，我們需要理解并加以應(yīng)對。通過軟件平臺來推進(jìn)重用是一個企業(yè)關(guān)心的問題，需要調(diào)整敏捷方法和實踐以支持業(yè)務(wù)戰(zhàn)略和目標(biāo)的需要。我們要應(yīng)對的五個主要挑戰(zhàn)包括：找到一種混合的團(tuán)隊組織方式能夠支持組件開發(fā)和特性開發(fā)、避免條塊分割的思考方式以及團(tuán)隊聯(lián)邦主義、重新審視業(yè)務(wù)價值的定義以囊括那些可能不直接關(guān)系用戶的方面、構(gòu)建一個更加整體的、協(xié)作的代碼與產(chǎn)品所有權(quán)模式，最后是基于對需求的業(yè)務(wù)價值的理解在敏捷性與穩(wěn)定性之間找到平衡。

　　關(guān)于作者

　　Yaser Ghanam即將從Calgary大學(xué)的計算機科學(xué)系博士畢業(yè)。他為本科生擔(dān)任軟件工程臨時講師。Yaser擁有阿聯(lián)酋Sharjah美國大學(xué)的計算機工程的學(xué)士學(xué)位，兼修工程管理。他專注于兩個專業(yè)領(lǐng)域：心理學(xué)和應(yīng)用數(shù)學(xué)。Yaser由于他的博士期間研究獲得過重要獎項，還獲得了2009年NSERC研究成就獎。在2010年冬天Yaser被提名入圍學(xué)生會優(yōu)秀教學(xué)獎。攻讀博士期間Yaser在調(diào)查如何通過敏捷方法來達(dá)成軟件重用和定制化。2010年夏天Yaser作為訪問學(xué)者前往芬蘭赫爾辛基大學(xué)，主持了在領(lǐng)先的IT和電信公司內(nèi)的實地研究。Yase曾在眾多會議上進(jìn)行過發(fā)表，如軟件生產(chǎn)線大會、極限編程大會和敏捷大會等。Yaser還是《Software: Practice and Experience》雜志下一期特刊的特邀合作編輯。

　　參考文獻(xiàn)

　　[1] Ambler, S. 2008. Agile Adoption Rate Survey Results.

　　[2] Customer Value Driven Development

　　[3] Leffingwell, D. 2007. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley.

　　[4] McGrath, M. 1995. Product Strategy for High-Technology Companies. Homewood, IL: Irwin.

　　[5] Pohl, K., B?ckle, G., and Linden, F. 2005. Software Product Line Engineering: Foundations, Principles and Techniques, Springer.

　　[6] van Gurp, J., Bosch, J., and Svahnberg, M. 2001. On the notion of variability in software product lines. Proceedings of the Working IEEE/IFIP Conference on Software Architecture, pp. 45-54.

　　查看英文原文： The Top Five Challenges of Building Software Platforms in the Agile World

it知識庫：在敏捷世界中構(gòu)建軟件平臺的五項首要挑戰(zhàn)，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。