寶馬集團 LeSS案例之巴伐利亞汽車制造商的LeSS轉(zhuǎn)型

背景

Valtech德國公司是選中的供應(yīng)商，以幫助其應(yīng)用敏捷開發(fā)來創(chuàng)建寶馬集團的新BMW i汽車的直銷流程。這需要新的IT支持系統(tǒng)，所有這些系統(tǒng)都已嵌入到現(xiàn)有的IT環(huán)境中，其中80多個系統(tǒng)會受到影響。有一個跨越許多項目的大型項目集來創(chuàng)建新的支持系統(tǒng)。

其中一個項目是新的統(tǒng)一銷售平臺（USP）系統(tǒng)。USP從頭開始實現(xiàn)，集成了30多個外部系統(tǒng)接口。BMW i推出的其他合作伙伴項目，仍沿用非敏捷過程模型。因此，跨項目的共同里程碑、報告和協(xié)作成為一個挑戰(zhàn)。

經(jīng)過2年多的開發(fā)，USP按時發(fā)布，并具有很高的質(zhì)量和客戶（比利時-荷蘭-盧森堡市場）滿意度。

階段1：在多個特性團隊之前

2012年2月，USP在充滿挑戰(zhàn)的環(huán)境中開始開發(fā)：

時間壓力大，因為上線日期已經(jīng)確定

直銷業(yè)務(wù)流程仍在討論中，尚未定義

因此，USP產(chǎn)品的范圍還不清楚

大多數(shù)參與者不熟悉寶馬集團的業(yè)務(wù)、銷售流程及敏捷方法

USP項目嵌入在傳統(tǒng)的項目集（BMW i項目集）管理系統(tǒng)中

由于上述情況，USP項目決定使用Scrum和敏捷工程實踐，來盡早和持續(xù)地獲取有關(guān)產(chǎn)品進度和組織進度的反饋。敏捷開發(fā)從一個Scrum團隊開始。這個團隊建立了合適的敏捷開發(fā)流程，搭建了合理的開發(fā)基礎(chǔ)架構(gòu)，找到了與業(yè)務(wù)部門的協(xié)作模式，并為敏捷開發(fā)奠定了堅實的基礎(chǔ)。

這個最初的團隊評估了所需的工具，搭建了開發(fā)環(huán)境和持續(xù)集成系統(tǒng)，嘗試了不同的Sprint長度，并實現(xiàn)了第一個業(yè)務(wù)功能，驗證了新組織是否可以正常工作。

從第一個Sprint開始，USP團隊在每個Sprint結(jié)束都演示了可運行的和經(jīng)過測試的軟件。

后來，團隊增加了一些人，這些人以傳統(tǒng)的職能和組件團隊的結(jié)構(gòu)進行了組織，這代表了更廣泛的BMW i項目集中使用的標準模型。

在USP 1.0版本之前團隊一直在使用這種結(jié)構(gòu)。

階段2：轉(zhuǎn)變到多個特性團隊與less

當(dāng)前的組織結(jié)構(gòu)對發(fā)布1.0版本來說已經(jīng)夠用了。不過，作為教練我們預(yù)見到，對于下一個更大的版本，這種組織結(jié)構(gòu)的擴展性不好。團隊需要更靈活（敏捷），因為優(yōu)先級和需求經(jīng)常變化。團隊需要能夠從產(chǎn)品待辦列表中選擇不同的條目，并交付完整的端到端特性。此外，還需要減少特性的周期時間以縮短“上市時間(time to market)”。

在先前的組織中，團隊只能做一種類型的功能或特定的組件工作。這限制了更改產(chǎn)品待辦事項的優(yōu)先級和團隊靈活地“轉(zhuǎn)到新工作”的能力。而且，專家小組間的交接和延誤，延長了平均周期時間。此外，還增加了協(xié)調(diào)和集成的工作量和問題。

因此，根據(jù)我們的建議，團隊同意重組為多個特性團隊并同時采用less。

我們的目標是創(chuàng)建五個新的跨組件和跨職能的特性團隊。

由于現(xiàn)有的商業(yè)合同和項目集的政策，USP項目組無法完全重組為特性團隊。例如，有一個UI設(shè)計治理小組負責(zé)整個程序的UI一致性。還有一個測試管理團隊，負責(zé)協(xié)調(diào)項目集范圍內(nèi)的跨項目測試活動，并為整個項目集提供報告。這個團隊不做測試工作；測試工作仍由實現(xiàn)團隊自己完成。不過，測試管理團隊對（實現(xiàn)團隊）“未完成（undone）”的部分做出了貢獻，例如組織外部公司做滲透（安全漏洞）測試。此外，按照項目集政策，這里還需要一個項目管理團隊，匯報給上層的（傳統(tǒng)）項目集管理團隊并負責(zé)人員、設(shè)施和設(shè)備管理。

自設(shè)計特性團隊工作坊

我們還達成一個共識，即通過自設(shè)計團隊工作坊（LeSS實驗之一），重組為特性團隊。

團隊花了3輪的時間（每輪20分鐘）形成了符合愿景的組織：所有特性團隊?wèi)?yīng)能夠獨立處理所有利益相關(guān)者/請求者的產(chǎn)品待辦事項。

在組建新團隊后，他們創(chuàng)建了新的團隊名稱，找到了自己的團隊空間，選舉了Scrum Master和“首席”開發(fā)人員（由于政策原因，這仍然是必需的角色）。

整個團隊的自設(shè)計工作坊大約持續(xù)了三個半小時。 有關(guān)自設(shè)計團隊工作坊的詳細信息，請點擊此處

團隊建設(shè)工作坊

自設(shè)計團隊工作坊是一個很好的開始。但是在自設(shè)計團隊工作坊結(jié)束時，有一些新成立的團隊，他們必須應(yīng)對新的動態(tài)。根據(jù)LeSS的說法，向特性團隊的轉(zhuǎn)變是對舊系統(tǒng)的重大更改。該項目組面臨著兩方面的擴展。一方面是跨團隊協(xié)作，按照一個產(chǎn)品待辦列表的優(yōu)先級與所有團隊合作。在LeSS環(huán)境中，Sprint儀式和同步會議覆蓋了這一方面。第二方面與團隊內(nèi)的可用知識有關(guān)。所有團隊都讓團隊成員了解不同的組件。這體現(xiàn)了團隊中的一個瓶頸，因此這種情況是擴展的障礙。為了在系統(tǒng)層面上進行改進，需要改善團隊內(nèi)部的知識共享。另外，項目管理團隊的目標是盡快使這些新團隊重新發(fā)揮作用（盡快開始工作）。因此，項目管理為每個團隊提供了進行額外的團隊建設(shè)工作坊的機會。本次工作坊的目的是降低社交障礙，啟動知識共享措施，尋找工作協(xié)議并在團隊挑戰(zhàn)中反思團隊動力。

工作坊日程：

這個工作坊大約用了三個小時，接下來就是午飯或晚飯。以下段落描述了部分的日程主題。

“團隊知識模型”和“一致同意的措施”

在此工作坊中團隊成員使用團隊知識模型?(TKM)來可視化團隊成員之間的知識分布。

團隊在業(yè)務(wù)水平和技術(shù)技能水平上建立了團隊知識模型。

在TKM模型中，按照與項目相關(guān)的各知識領(lǐng)域，所有團隊成員在技能水平（X軸）和日常挑戰(zhàn)（Y軸）兩個維度找到他們的位置。坐標軸分為三個區(qū)域：低中高。從挑戰(zhàn)維度看，低挑戰(zhàn)意味著團隊成員在該特定知識領(lǐng)域沒有任務(wù)或只有非常簡單的任務(wù)。高挑戰(zhàn)則表明團隊成員工作的任務(wù)很復(fù)雜。技能水平，可以理解或替代為LeSS中提到的守破離（Shu/Ha/Ri）對應(yīng)的經(jīng)驗水準。

上面的示例顯示了“測試專業(yè)（TEST FACHLICH）”領(lǐng)域的兩個成員(譯者注：圖中兩個粉色的X)。一位團隊成員表示，他的知識剛夠應(yīng)付日常工作（當(dāng)前邊做邊學(xué)）。另一位團隊成員在此領(lǐng)域有很好的知識，但不在該領(lǐng)域中工作（浪費了專家知識）。如果這兩個團隊成員結(jié)對完成該領(lǐng)域的任務(wù)，則兩者都會受益并迅速達到心流狀態(tài)。

此外，該模型表明，團隊具備了所需的基本知識，唯獨棕色的領(lǐng)域是個例外。在棕色的領(lǐng)域中，團隊需要其他團隊的幫助，以快速提高團隊知識。單擊此處了解團隊知識模型的更多信息。

在TKM中可視化知識分布后，團隊可以基于模型尋找合適的措施來改善團隊的知識分布，例如，確定特定主題的結(jié)對人選，組織團隊代碼道場等。一些團隊隨后提出需要跨團隊的知識共享，因此啟動了實踐社區(qū)。

通過此模型，團隊還可以獲取反饋，無論他們是否對產(chǎn)品待辦事項列表的工作有足夠的知識，或者是否存在某些知識空白。基于這個可視化模型，每個團隊都定義并商定了改進措施，例如誰將進行結(jié)對編程，組織代碼道場或測試道場，其他培訓(xùn)課程，結(jié)對工作，看書和事后分享……團隊開始意識到：作為持續(xù)改進的一部分，自己要對個人和團隊的學(xué)習(xí)負責(zé)。

“團隊愿景和團隊章程”

團隊愿景或團隊章程可以幫助團隊聚焦于同一方向。因此，在此活動中，團隊創(chuàng)建了愿景，例如“我們胸襟開闊，愿意改進并互相支持。”或團隊章程，其中一些團隊定義了“做什么與不做什么”之類的規(guī)則，或者定義了諸如“每天至少進行兩次結(jié)對編程”，“回歸測試保持綠色”的工作協(xié)議。

“團隊挑戰(zhàn)（室外）”

在戶外的挑戰(zhàn)下，團隊可以反思他們?nèi)绾魏献鳌＠鐖F隊溝通的工作方式，或在時間壓力下的行為。如果團隊在給定時間內(nèi)沒有成功，則團隊可以有多次迭代。這是個缺省的過程，旨在使團隊可以反思他們的方法。然后再開始下一輪。有些團隊三輪比賽才成功，有些則兩輪就成功了。挑戰(zhàn)之后，他們都達成了共識，那就是他們通過良好的溝通、檢視和適應(yīng)以及所有團隊成員的參與才能成功。

工作坊結(jié)束后，團隊按照自己的意愿去選擇午餐或晚餐。在那里，團隊成員分享了他們對工作坊的見解和經(jīng)驗，并加深了對團隊動力的理解。

一個產(chǎn)品待辦列表

根據(jù)LeSS的要求（因為它支持聚焦整個產(chǎn)品、透明性和簡化），只有一個產(chǎn)品待辦事項列表，所有特性團隊都為之工作。轉(zhuǎn)型到特性團隊后（而不是組件團隊和單功能團隊），每個團隊都可以完成端到端的客戶特性。產(chǎn)品待辦列表中的每個條目都代表了完整的端到端客戶特性。

為了滿足整個項目集的傳統(tǒng)項目報告要求，我們創(chuàng)建了一個自動報告的解決方案，該解決方案從一個產(chǎn)品待辦事項列表中提取數(shù)據(jù)，并以傳統(tǒng)的“瀑布式”項目集管理小組熟悉的方式進行展示。

產(chǎn)品所有權(quán)與設(shè)計治理小組

作為對一個產(chǎn)品待辦事項列表的補充，在LeSS中，只有一個產(chǎn)品負責(zé)人可以排序（排優(yōu)先級），因此，這位產(chǎn)品負責(zé)人具有強烈的產(chǎn)品所有權(quán)意識，從他那里會得到強烈而一致的愿景。相比之下，寶馬集團有一項默認政策，即治理委員會中確定內(nèi)容、范圍和優(yōu)先次序。如果要做出決定，則必須包括不同業(yè)務(wù)部門的許多利益相關(guān)者。因此，寶馬集團的項目有一個“設(shè)計治理”小組。該小組作為團隊排優(yōu)先級。當(dāng)然，這與標準的LeSS框架不同，卻是可能性的藝術(shù)。特別是從外部團隊（例如Valtech DE）而非內(nèi)部引入LeSS時新的工作方式，這種組織層面的妥協(xié)尤其普遍。

產(chǎn)品待辦列表的排序是通過與所有利益相關(guān)者的交談完成的。以下條件影響了順序：

法律方面

利益相關(guān)者目標日期/里程碑

預(yù)期的價值

可能降低的風(fēng)險

每個利益相關(guān)者的剩余項目預(yù)算

與LeSS原則“聚焦整個產(chǎn)品”有關(guān)，每個Sprint兩周一次，該（設(shè)計治理）小組與特性團隊和跨領(lǐng)域團隊的代表一起進行了整體的產(chǎn)品待辦事項列表梳理工作坊（PBR）。

設(shè)計治理小組組織了不同業(yè)務(wù)部門（領(lǐng)域?qū)＜遥┡c特性團隊之間的互動。他們與特性團隊一起確保，在將相應(yīng)的待辦事項條目納入Sprint之前，解決了并發(fā)需求的沖突。設(shè)計治理小組成員還組織并參加了特性團隊的“產(chǎn)品待辦列表梳理（PBR）”工作坊。

LeSS中的Sprint儀式

在第一階段，USP項目幾乎從一片空白開始。該系統(tǒng)是從頭開始構(gòu)建的。負責(zé)新款BMW i銷售流程的業(yè)務(wù)部門僅獲得了以傳統(tǒng)方式創(chuàng)建的一份系統(tǒng)建議。因此，將系統(tǒng)建議分解為產(chǎn)品待辦列表條目（PBI）是合理的。在本例中，我們編寫了具有驗收標準的用戶故事。在項目開始時，在很高的層面上完成（譯者注：指的是粒度較粗）。隨著時間的推移，團隊根據(jù)優(yōu)先級與業(yè)務(wù)部門的領(lǐng)域?qū)＜乙黄鸺毣@些條目。業(yè)務(wù)部門/領(lǐng)域?qū)＜遗c團隊之間存在1對1的關(guān)系。功能方面的協(xié)調(diào)是在治理小組和業(yè)務(wù)部門級別進行的。技術(shù)方面的協(xié)調(diào)則在團隊間完成。作為下個Sprint的預(yù)覽，Sprint中舉辦產(chǎn)品待辦列表梳理會議。在Sprint計劃會議第1部分結(jié)束時，舉辦同步會議。團隊在這兩個會議上協(xié)調(diào)技術(shù)方面。所有團隊的代表都參與了這兩個會議。

該項目組同意了以下對所有團隊有效的“就緒定義”（DoR）：

技術(shù)可行

UI模型設(shè)計完成

驗收標準已提供

產(chǎn)品負責(zé)人同意

安全性、角色和權(quán)利已定義

估算過

治理小組僅對下一個Sprint符合DoR標準的條目進行優(yōu)先級排序。團隊根據(jù)（開發(fā)）速率為接下來的一個半到兩個Sprint準備了最大數(shù)量的條目。

在USP的第二階段，轉(zhuǎn)變?yōu)樘匦詧F隊后，PBR的流程發(fā)生了變化。現(xiàn)在，該項目必須處理來自不同利益相關(guān)者的需求，有時會與其它需求或現(xiàn)有功能發(fā)生沖突。用戶故事作為唯一的條目類型不夠用了。利益相關(guān)者所需的功能與現(xiàn)有功能之間的差距必須表達出來。因此，項目組引入了“topic”一詞，用于描述所需功能與現(xiàn)有功能之間的差距。利益相關(guān)者的需求之間可能存在的沖突在topic級別解決。設(shè)計治理小組負責(zé)topic級別。他們解決了不同業(yè)務(wù)部門之間可能出現(xiàn)的沖突，定義了無沖突且大致細化過的條目。之后他們與特性團隊一起做進一步的條目細化工作，細化后的條目與階段一的條目可以做相同處理。

擴展協(xié)調(diào)與集成的技術(shù)

在LeSS中，眾所周知，真正強大的持續(xù)集成實踐對于成功擴展規(guī)模至關(guān)重要，因此，持續(xù)集成是LeSS“技術(shù)卓越”部分的指南之一。有了持續(xù)集成，協(xié)調(diào)和內(nèi)部開源、增加透明度和關(guān)注整個產(chǎn)品成為可能。因此，USP小組投入精力改進開發(fā)者行為（持續(xù)地集成），并建立了一個強大的持續(xù)集成（CI）系統(tǒng)和相應(yīng)流程。

CI系統(tǒng)的核心是主版本（master-build）概念。部署或驗證所需的每個工件（例如JAR文件，配置數(shù)據(jù)，測試等）都與主版本號綁定在一起。該系統(tǒng)的所有結(jié)果（例如，構(gòu)建產(chǎn)物，測試結(jié)果，日志和軌跡記錄）均關(guān)聯(lián)到相應(yīng)的主版本號并存儲到中心存儲庫。

CI系統(tǒng)由3個主要組件構(gòu)成，分3個步驟執(zhí)行：

編譯并生成可執(zhí)行文件。

部署和測試。在目標系統(tǒng)上部署主版本，執(zhí)行端到端測試，并將相應(yīng)的結(jié)果，日志和跟蹤存儲在中央存儲庫中。

報告結(jié)果，創(chuàng)建一個主版本歷史記錄表，其中顯示了主版本號和所有對應(yīng)的結(jié)果。然后通過電子郵件向感興趣的人發(fā)送報告的鏈接。

有關(guān)持續(xù)集成的技術(shù)視角表明，它具有高度的可擴展性，無論開發(fā)人員是在現(xiàn)場、在異地甚至在離岸工作都沒有關(guān)系。

每15分鐘創(chuàng)建一次的系統(tǒng)版本均帶有專用的版本號標記。最近成功的系統(tǒng)構(gòu)建（無失敗的單元測試和模塊測試）部署到類目標環(huán)境（target-similar）中。

之后執(zhí)行端到端的冒煙測試。冒煙測試是自動回歸測試的一個子集，反映了最重要的測試場景，以便在集成級別為開發(fā)人員提供快速反饋。測試結(jié)果鏈接到主版本號，并記錄在主版本歷史中。

只有通過了冒煙測試的主版本才可以進入下一階段。下一階段是自動回歸測試。作為“完成的定義”（DoD）的一部分，團隊將條目的驗收標準轉(zhuǎn)化為自動化的回歸測試（“可執(zhí)行的需求”）。所有可以運行的回歸測試均在此階段執(zhí)行。同時，還并發(fā)執(zhí)行了一些質(zhì)量檢測，例如靜態(tài)代碼檢查（Sonar）或性能測試。這些結(jié)果都記錄在相應(yīng)的主版本構(gòu)建歷史中。

所有測試均有標記關(guān)聯(lián)到相應(yīng)的產(chǎn)品待辦事項條目，由此關(guān)聯(lián)到USP不同領(lǐng)域的功能。因此可以查看產(chǎn)品的哪個功能領(lǐng)域存在問題。

通過逐級點開功能領(lǐng)域，所有小組成員都可以深入研究有問題的條目，并可以從功能角度分析問題，即哪一條驗收標準出了問題。當(dāng)然，在最低級別（未顯示）提供了與技術(shù)/代碼級別的關(guān)聯(lián)，例如，列表條目的預(yù)期數(shù)量為 <2> 但收到的結(jié)果卻為 <0> ，或其它的異常詳細信息……。

這樣，每個人都可以立即獲得有關(guān)主版本的當(dāng)前功能質(zhì)量的全貌。

反饋周期

在LeSS的大規(guī)模開發(fā)中，較短的CI系統(tǒng)反饋周期尤其重要，因為不可能大家一直在一起交談。因此CI系統(tǒng)需要成為一個發(fā)信號的工具，以便在出現(xiàn)問題時迅速告訴小組。然后人們找出跟誰一起聊可以解決問題。這樣，具有快速反饋的CI系統(tǒng)成為了協(xié)調(diào)的工具。

從簽入（代碼）開始計時，持續(xù)集成團隊能夠?qū)⒚盁煖y試的快速反饋周期時間保持在一小時到一個半小時之間。每天可獲得兩到三次回歸測試結(jié)果，回歸測試大約需要三到五個小時。

隨著系統(tǒng)功能的增加，測試規(guī)模也隨之增加。為了縮短反饋周期，必須進行并行測試。這需要更多的虛擬服務(wù)器，當(dāng)然也需要更多的硬件。主版本部署到多臺服務(wù)器上。根據(jù)標簽將測試劃分為功能領(lǐng)域（例如“財務(wù)測試”），并同時在多個服務(wù)器上執(zhí)行（不同功能領(lǐng)域的）測試。之后將測試結(jié)果合并到一個報告中。

結(jié)構(gòu)方面

除了用于自動化測試的環(huán)境外，還有兩個手動測試環(huán)境，與寶馬集團所有其他相關(guān)IT系統(tǒng)完全集成。僅在這兩個環(huán)境中，條目才可以按照“完成的定義”（DoD）被接受。此外，每個特性團隊都有自己的測試環(huán)境用于內(nèi)部探索性測試。他們能夠在這些測試服務(wù)器上添加新特性并對其運行自動化測試。好處是簽入代碼之前快速集成反饋。所有這些服務(wù)器都按照寶馬集團的staging流程通過中央Jenkins服務(wù)器進行部署。

所有其他利益相關(guān)者都可以看到主版本號，并在構(gòu)建歷史表中很容易地查看當(dāng)前已安裝軟件的功能質(zhì)量。綠色的冒煙測試和回歸測試是通用的DoD條件。因此，每個人都可以驗證當(dāng)前實現(xiàn)的版本是否會對現(xiàn)有功能產(chǎn)生副作用。

失敗構(gòu)建的協(xié)調(diào)

每次構(gòu)建/測試運行后，CI系統(tǒng)都會向用戶發(fā)送一封電子郵件，其中包含功能結(jié)果概述。該電子郵件還包含指向CI系統(tǒng)提供的功能和技術(shù)構(gòu)建詳細信息的鏈接。所謂的“每日回歸”是與每個團隊的代表舉行的簡短站立會議，用于協(xié)調(diào)活動，以防過夜的回歸失敗。

系統(tǒng)集成

在BMW i項目集中規(guī)劃了總體6個月的系統(tǒng)集成測試階段。對于所有相關(guān)項目都有固定的代碼凍結(jié)通告。因為USP項目能夠交付高質(zhì)量的軟件，所以BMW i項目集就要求更多特性，并在最后一刻收到來自市場方面的更改。因此，團隊跳過了USP項目的代碼凍結(jié)。在技術(shù)“上線”的兩周之前，USP每周都會提供新功能（仍然是兩周的Sprint）到整個系統(tǒng)集成環(huán)境。在此期間，全面的測試管理，包括市場上的測試設(shè)備發(fā)現(xiàn)的缺陷比寶馬集團的另一個類似項目少了95％。少數(shù)缺陷中的三分之一與USP功能無關(guān)。在“業(yè)務(wù)上線”后的五周內(nèi)，沒有發(fā)現(xiàn)與USP功能相關(guān)的嚴重問題，或是會阻塞業(yè)務(wù)且在很短的時間內(nèi)無法解決的問題。

因此，該小組的自動化測試和集成實踐為整體成功做出了巨大貢獻。

結(jié)論

在USP的指導(dǎo)中我們遵循了LeSS原則。“聚焦整個產(chǎn)品”非常重要，因此我們在開發(fā)過程中集成了所有相關(guān)的合作伙伴系統(tǒng)。作為“完成的定義”的一部分，該項目從一開始就定義并執(zhí)行了BMW i的整個項目集的集成測試。與功能測試自動化一起，為2014年秋季的成功發(fā)布做出了重大貢獻。根據(jù)我在同類項目中的經(jīng)驗，USP項目達到了卓越的質(zhì)量。

此外，該項目采用了透明性和以客戶為中心（LeSS原則）的方法，通過每個Sprint向所有團隊展示整個項目可運行的軟件，并根據(jù)客戶的反饋調(diào)整產(chǎn)品待辦事項，確保了很高的客戶滿意度。

通過經(jīng)驗過程控制，該項目能夠提供現(xiàn)實的、基于事實的、具體的進行中特性的進度預(yù)測（相對于“甘特圖進度”的錯覺），從而提高了可預(yù)測性和可靠性。高質(zhì)量贏得了多方的信任，包括整體項目集、傳統(tǒng)測試管理，客戶及合作伙伴系統(tǒng)。盡管其他合作伙伴系統(tǒng)不得不遵循傳統(tǒng)的集成測試階段（譯者注：在此階段代碼凍結(jié)），USP項目是個例外。直到技術(shù)上線前的兩周，USP項目被允許并能夠提供新特性（“晚期”的更改）！

LeSS和敏捷原則為整個項目提供了出色的指導(dǎo)，在許多情況下，它們是關(guān)鍵項目決策的基礎(chǔ)。

敏捷開發(fā)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。