欧美一区二区在线视频,免费欧美黄色,国产黄色免费

　　引子

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

　　軟件平臺(tái)是什么？

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

　　五項(xiàng)首要挑戰(zhàn)

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

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

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

“我聽說，敏捷界都認(rèn)為組件團(tuán)隊(duì)不好，因?yàn)樗鼈冏霾坏蕉说蕉素?fù)責(zé)。”

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

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

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

　　A. 直接修改核心平臺(tái)代碼：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　結(jié)論

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

　　關(guān)于作者

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