引子

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

　　軟件平臺是什么？

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

　　五項首要挑戰

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

　　1. 特性團隊還是組件團隊

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

“我聽說，敏捷界都認為組件團隊不好，因為它們做不到端到端負責。”

　　然而，就平臺開發而言，有需要把二者結合起來。例如某些服務 —— 尤其后臺服務重要且基本，開發成本昂貴，可能有必要安排專門的組件團隊來進行維護，而不應交給具體項目中的特性團隊去負責。

　　特性團隊與組件團隊的交叉合作很重要。有時需要組件團隊來構建和維護特定核心服務——這些服務有可能會大范圍影響產品，抑或需要特殊領域知識或專長。有時候需要另外一些與應用層有密切互動的組件團隊來與特性團隊更緊密地合作，以理解他們的需求。

　　為了交付應用級特性，特性團隊通常承擔著端到端的職責。在端到端的開發中，特性團隊除了使用平臺中的服務，偶爾還需要對平臺做些修改以滿足需要。修改有以下兩種方式：

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

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

1. 特性團隊對平臺組件所作的任何修改和擴展，都必須經過主管該部分的平臺團隊的審核。這是為了確保改動技術上可靠，并且防止違反任何設計及結構上的規制和準則。如果代碼有跨平臺的要求，那么跨平臺性也要納入審核范圍。
2. 特性團隊應該有權對平臺組件進行回歸測試，這樣他們就可以在提交更改前在本地針就不同的配置環境生成產品。否則平臺不穩定將造成用戶認為平臺不可靠。

　　B. 從核心平臺代碼創建分支

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

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

　　2. 團隊自主管理：

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

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

　　3. 業務價值意識：

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

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

　　可是業務價值并不總是立竿見影，也不一定直接對客戶發生影響。重構即為一例。

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

　　4. 對代碼和產品所有權意識：

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

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

　　5. 敏捷性與穩定性的矛盾：

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

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

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

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

　　結論

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

　　關于作者

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

　　參考文獻

　　[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知識庫：在敏捷世界中構建軟件平臺的五項首要挑戰，轉載需保留來源！

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