《敏捷軟件開發(fā)：用戶故事實戰(zhàn)》

敏捷軟件開發(fā)

用戶故事實戰(zhàn)

[美] 邁克·科恩（Mike Cohn） 著

王凌宇? 譯

推薦序

肯特·貝克（Kent Beck）

如何確定一個軟件系統(tǒng)應該做什么？然后，怎樣和相關的人溝通這個決定？本書研究了這個復雜的問題。這個問題很難，因為不同的相關人，各自的需求也不相同。項目經理想要跟蹤進展，程序員想要實現(xiàn)這個系統(tǒng)，產品經理想要靈活性，測試人員想要度量，用戶想要一個可用的系統(tǒng)。在這些充滿沖突的觀點中，想要達成一個每個人都支持的集體決定，并且維持數(shù)月或者數(shù)年的平衡都是很困難的事情。

邁克·科恩（Mike Cohn）在本書中探討的解決方案，與以前解決這個問題的嘗試方法，需求分析，用例和場景的目的是一樣的。是什么如此復雜？你寫下你想做的事，然后你照著做。解決方案的層出不窮，表明這個問題并不像看起來那么簡單。這些解決方案的不同在于你寫下了什么，何時寫的。

用戶故事通過兩條信息來啟動這個過程：每個系統(tǒng)需要實現(xiàn)的目標，以及實現(xiàn)這個目標所需要的大致成本。這只需要幾句話，卻能提供其他方法沒有給出的信息。遵循“最后責任時刻”（last responsible moment）的原則，團隊成員在實現(xiàn)特性之前，才將特性的大部分細節(jié)寫下來。

這個簡單的時刻轉換有兩個主要的效果。首先，團隊可以很容易在開發(fā)早期就開始實現(xiàn)“最優(yōu)”的特性，而那時其他特性仍然是模糊的。在添加新特性時，定義每個特性細節(jié)的自動化測試能夠確保已實現(xiàn)的特性繼續(xù)正常工作。其次，在早期對特性進行成本考慮時，可以鼓勵從一開始就優(yōu)先考慮特性的優(yōu)先順序，而不是最后為了滿***付日期而忙亂地縮減功能。

邁克在用戶故事方面的豐富經驗使本書充滿了實用的建議，讓用戶故事成為開發(fā)團隊的利器吧。祝愿大家在做開發(fā)時能夠更加明確、自信。

譯者序

2001年，敏捷宣言誕生，現(xiàn)在敏捷方法已經在全世界范圍內廣泛應用。而早在1996年，極限編程就提出了“故事”（story）的概念，這是用戶故事的起源。2004年，本書正式出版發(fā)行。書中對用戶故事理論系統(tǒng)化的闡述，操作實例化的說明，實際應用中的價值呈現(xiàn)，使用戶故事由單一實踐上升至系統(tǒng)化的方法，本書也當之無愧成為用戶故事方法的里程碑之作。雖然還存在一些不足，但是“用戶故事”無疑已經成為精益敏捷方法的基石之一。

用戶故事方法獨有的價值，奠定了它在精益敏捷方法中的基石地位。

首先，用戶故事實現(xiàn)了產品需求的敏捷化，進而將軟件產品研發(fā)過程中的需求、開發(fā)、測試主要環(huán)節(jié)系統(tǒng)化的連接起來。需求模糊不清，變更頻繁，做出的功能客戶不認可已經成為產品團隊普遍面臨的痛點問題，怎樣在有限的時間內及時交付給用戶真正想要的產品，已經成為產品團隊的夢想。但是在實現(xiàn)高效的開發(fā)之前，首先應該解決的是如何確保團隊做的工作是正確的，用戶故事覆蓋了產品研發(fā)過程中的需求領域，對如何獲取用戶真實的需求并實現(xiàn)敏捷化提供了切實可行的解決方案。

通過有效的對話溝通和迭代式的細節(jié)完善等操作，用戶故事實現(xiàn)了需求的敏捷化；通過優(yōu)先級排序和故事點的應用，用戶故事實現(xiàn)了需求與開發(fā)的連接；通過驗收標準的持續(xù)明確，用戶故事實現(xiàn)了需求與測試的連接。用戶故事是一根線，它打破了傳統(tǒng)管理中的職能墻，把需求、開發(fā)、測試環(huán)節(jié)進行了有機的連接和敏捷化的融合。

其次，用戶故事方法彌補了目前業(yè)界通用的精益敏捷方法在產品需求領域的不足，是團隊進行全價值鏈敏捷轉型不可或缺的關鍵要素。

目前業(yè)界通用的精益敏捷方法，無論是敏捷Scrum，還是精益Kanban，甚至是規(guī)?；艚軸AFe等，在需求領域，不管是簡單的還是復雜分層級的需求描述，最后都會落在用戶故事上。雖然精益敏捷基于實踐持續(xù)演進，但是到目前為止，用戶故事仍然是需求領域的核心方法。

第三，用戶故事方法撬動了敏捷項目管理計劃領域，促進了項目相關方之間的協(xié)同合作。

故事點是用戶故事中獨有的概念。故事點的使用，巧妙地讓用戶故事能夠有效地進行計劃，將產品需求與項目計劃進行了有機的連接，并支持在項目執(zhí)行過程中持續(xù)進行可協(xié)商的適應性調整。

用戶故事更強調與用戶之間進行口頭對話和溝通。用戶故事中的很多實踐活動，用戶代理、故事編寫工作坊、估算故事、利用故事計劃發(fā)布和迭代等，都強調客戶、用戶和整個項目團隊的協(xié)同工作。用戶故事在客戶和項目團隊之間搭建起真正的橋梁，促進了項目相關方能夠向共同的目標協(xié)同努力。

可以說，用戶故事給方興未艾的敏捷項目管理領域貢獻了特有的實踐智慧。

第四，用戶故事方法是組織進行業(yè)務敏捷轉型不可或缺的工具。

市場商業(yè)環(huán)境紛繁復雜，用戶需求模糊易變，產品交付周期日益縮短，企業(yè)組織面臨的現(xiàn)狀越來越嚴峻。怎樣更好的應對這些現(xiàn)狀？實現(xiàn)組織級業(yè)務層面的敏捷轉型是企業(yè)應該優(yōu)先考慮的方向之一。組織級業(yè)務敏捷轉型需要企業(yè)高屋建瓴的進行規(guī)劃，但是在落地實施層面更需要切實可操作的工具方法。

用戶故事從用戶價值的角度出發(fā)，在用戶需求實現(xiàn)過程中時刻提示團隊關注用戶目標，并且將研發(fā)過程中需求、開發(fā)、測試主要環(huán)節(jié)進行了系統(tǒng)化的連接，能夠最大限度地促進團隊盡快及早向用戶交付價值，從而滿足用戶真實的需求，適應市場的趨勢，進而實現(xiàn)企業(yè)的商業(yè)目標。

用戶故事方法就是從上到下貫通組織業(yè)務敏捷轉型，并且可落地化操作的有效工具之一。

作為一名精益敏捷的踐行者，我在多年推廣的過程中意識到，理論只是理論而已，只有通過落地實操的方式給團隊組織賦能，解決實際問題才能產生價值?？上驳氖?，在我們去實操之前，本書擺在我們面前，不僅從理論上，還從實操方面給出了大量的實例化案例來教會我們怎樣使用用戶故事，仔細品味這些案例，都會給大家?guī)碛袃r值的參考。在后續(xù)的實施中，我相信用戶故事會給大家?guī)眢@喜。

最后，我把本書獻給我的妻子王曉蘭和我的兒子，在翻譯的過程中，我的妻子正在輔導兒子學習英語，這使得我們家的翻譯學習氛圍更加濃厚，同時也激勵我實現(xiàn)高質量的完成交付。由于妻子的辛勞付出和兒子的專心學習，使我能夠心無旁騖地進行工作，反復琢磨詞句，并最終將經典作品再次以全新的姿態(tài)呈現(xiàn)給各位讀者朋友。

前 ???言

在20世紀90年代中期的大部分時間里，我都感到愧疚。我當時正在為一家公司工作，這家公司每年都會收購一家新公司。每次收購一家新公司，我都會被分派去負責打理他們的軟件開發(fā)團隊。收購的每個開發(fā)團隊都帶來了輝煌、美觀、冗長的需求文檔。我不可避免地感到愧疚，因為我自己的團隊從來沒有寫出過如此優(yōu)美的需求規(guī)格說明。但是，我的團隊在生產軟件方面一直比我們收購的團隊成功得多。

我清楚我們成功的方法。然而，我總有一種難以名狀的感覺，如果我們能寫出大而冗長的需求文檔，我們可能會更加成功。畢竟，那正是我當時正在閱讀的書籍和文章中所描述的做法。如果成功的軟件開發(fā)團隊都在編寫華麗的需求文檔，那么看起來我們也應該這樣做。但是，我們從來沒有時間做。我們的項目總是太重要，需要我們盡快啟動，以至于我們從一開始就沒有時間來寫文檔。

因為我們從來沒有時間寫美觀而冗長的需求文檔，所以我們決定采用一種工作方式來與用戶溝通。我們不是把需求寫下來，讓它們來回傳遞，并在時間不夠用的時候還在談判，而是和客戶交談。我們會在紙上繪制界面樣例，有時候會創(chuàng)建原型，通常我們會寫一些代碼，然后向預期用戶展示我們編寫的內容。至少每月一次，我們會邀請一組具有代表性的用戶，并向他們演示我們開發(fā)的功能。通過貼近用戶并向他們演示小的增量進展，我們找到了一種方法來幫助我們在沒有美觀需求文檔的情況下取得成功。

盡管如此，肯特·貝克（Kent Beck）仍然感到愧疚，認為我們沒有按照我們應該的方式去做事。

1999年，肯特·貝克的革命性小冊子《解析極限編程》出版發(fā)行。一夜之間，我所有的愧疚蕩然無存。終于有人提出了開發(fā)人員和客戶之間用討論取代“寫文檔-商談-再寫文檔”的模式?？咸仃U明了很多事情，并帶給我很多新的工作方法。但是，最重要的是，他證明了我從自己的實踐中領悟到的是正確的。

大量的前期需求收集和文檔可能在多方面導致項目失敗。最常見的一種情況是需求文檔本身成為軟件開發(fā)的目標。需求文檔只有在能夠幫助實現(xiàn)交付某些軟件的真正目標時才應該編寫。

大量的前期需求收集和文檔可能在多方面導致項目失敗的第二種情況是書面語言的不準確性。我記得很多年前聽到過一個小孩洗澡的故事。小孩的父親已經在浴缸中放滿了水，正準備幫助他的小孩進入水中。這個小孩大概兩三歲，先把腳趾頭伸入水中蘸了一下，然后迅速將腳趾移開，并告訴她的父親“讓它暖和一些”（make it warmer.）。父親把手伸入水中，驚訝地發(fā)現(xiàn)水不是太冷，已經比他女兒習慣的溫度更熱了。

父親思索了一下孩子的請求，意識到他們的溝通出現(xiàn)了問題，用相同的詞語來表示不同的意思。孩子“讓它暖和一些”的請求被任何成年人都解釋為“調高水溫”（increase the temperature）。然而，對于孩子來說，“讓它變暖”意味著“讓它接近我認為暖和的程度”。

文字，尤其是白紙黑字那樣的，通過它來表達軟件這樣復雜東西的需求，是比較簡單有限的載體。由于它們可能被誤解，所以我們需要用開發(fā)人員、客戶和用戶之間頻繁的對話來取代書面文字。用戶故事為我們提供了這種方法，讓我們寫下來足夠多我們不會遺忘的內容，并且我們可以估算和計劃，同時還鼓勵及時溝通。

讀完本書的第I部分時，你將準備開始改變總是嚴格寫下每一個需求最后細節(jié)的工作方式。讀完本書的時候，你會知道在具體環(huán)境中實施故事驅動過程所有的必要信息。本書分為四個部分和兩個附錄。

l?? 第I部分“開始”，描述開始編寫故事需要了解的一切。用戶故事的目標之一是讓人們說話而不是寫作。第I部分的目標是盡快讓你交談。第1章概述了什么是用戶故事以及如何使用故事。接下來的章節(jié)提供了編寫用戶故事，通過用戶角色建模收集故事，在無法訪問實際最終用戶時編寫故事以及測試用戶故事的更多細節(jié)。第I部分的結尾部分提供了一些指導方針，可以用來改進用戶故事。

l?? 第II部分“估算和計劃”，有了一系列用戶故事后，我們經常需要回答的第一件事是“需要花費多長時間來開發(fā)？”。第II部分介紹了如何使用故事點來估算故事，如何在3~6個月的時間范圍內計劃發(fā)布，如何更詳細地計劃隨后的迭代，最后如何度量進度并評估項目是否按照既定的意愿進行。

l?? 第III部分“經常討論的話題”，首先描述故事與用例，軟件需求說明和交互設計場景等需求方案的不同之處。隨后探討用戶故事的獨特優(yōu)點，如何判斷出現(xiàn)問題的時間，如何調整敏捷過程Scrum以使用故事。最后一章著眼于各種小問題，例如是否在紙質卡片或者軟件系統(tǒng)中編寫故事以及如何處理非功能性需求。

l?? 第IV部分“一個完整的項目案例”，一個擴展的例子，旨在幫助歸納用戶故事的所有內容。如果說開發(fā)人員可以通過故事更好地理解用戶的需求，那么本部分的完整示例是非常重要的，這個示例將展示用戶故事的各個方面及其結合方式。

l?? 第V部分“附錄”，用戶故事源于極限編程。閱讀本書之前不需要熟悉極限編程。附錄A提供了極限編程的簡要介紹。附錄B包含對各章結尾思考練習題的解答。

致 ???謝

本書受益于眾多審閱者的評論。我特別感謝Marco Abis，Dave Astels，Steve Bannerman，Steve Berczuk，Lyn Bain，Dan Brown，Laura Cohn，Ron Crocker，Ward Cunningham，Rachel Davies，Robert Ellsworth，Doris Ford，John Gilman，Sven Gorts，Deb Hartmann，Chris Leslie，Chin Keong Ling，Phlip，Keith Ray，Michele Sliger，Jeff Tatelman，Anko Tijman[①]，Trond Wing?rd，Jason Yip和一些匿名的審閱者。

我衷心感謝本書正式的審閱者：榮恩（Ron Jeffries）、湯姆（Tom Poppendieck）和比爾（Bill Wake）。榮恩使我保持誠實和敏捷。湯姆使我察覺到之前沒有考慮到的許多想法。比爾則使我保持正確的方向，并與我分享他的INVEST縮寫詞模型。我很驕傲能夠和三位共事，他們當中任何一位提出來的建議都對完善本書做出了不可估量的貢獻。

在過去的9年中，我所知道的大部分內容都與托德（Tod Golding）爭論過。我們之間的共識遠遠超過彼此之間的爭執(zhí)。不管怎樣，我從我們的爭論中學到東西。多年來他所教我的一切，我都感激不盡。我和他討論的內容極大充實了本書。

感謝阿歷克斯（Alex Viggio）和XP Denver的所有人，讓我有機會展示本書許多早期的想法。也感謝馬克和J. B.（Mark Mosholder和J. B. Rainsberger），他們向我講述了他們如何使用軟件而不是卡片。感謝肯尼（Kenny Rubin）[②]，他與阿黛爾（Adele Goldberg）合作完成了Succeeding With Objects一書，他在書中所表現(xiàn)出來的自豪感使我在停筆數(shù)年后再次開始寫作。

衷心感謝馬克和Fast401k創(chuàng)始人丹（Dan Gutrich），他們全心全意地擁抱用戶故事和Scrum。還要感謝Fast401k我的每一位同事，我們正在努力實現(xiàn)我們的目標——成為科羅拉多州最好的團隊之一。

千言萬語都無法表達我對家人的感激，因為有那么多的時間我無法陪伴他們。感謝我美麗的女兒和公主，薩凡娜和德蘭妮（Savannah和Delaney）。特別感謝我美麗的妻子勞拉（Laura），因為我的繁忙，她得操很多心。

我對Addison-Wesley團隊感激不盡。與保羅（Paul Petralia）的合作一直都非常愉快。米切爾（Michele Vincenti）一直推進事情。麗莎（Lisa Iarkowski）為我使用FrameMaker提供了寶貴的幫助。蓋爾（Gail Cocker）潤色了我的圖表。尼克（Nick Radhuber）最后把所有一切整合在一起。

最后同時也是最重要的感言要獻給肯特，感謝他的真知灼見和他的時間，感謝他把本書收入他的簽名系列中。

目 ???錄

第I部分? 開??? 始

第1章? 概述???????? 3

什么是用戶故事？???????? 4

細節(jié)在哪里？???????? 5

“需要在多長時間內完成？”???? 7

客戶團隊???????? 7

使用故事的過程是什么樣的？???? 8

計劃發(fā)布和迭代???? 9

什么是驗收測試？???????? 11

為什么要改變？???? 12

小結???????? 13

思考練習題???? 13

第2章? 編寫故事???????? 15

獨立的???? 15

可協(xié)商的???????? 16

對用戶或客戶有價值的???????? 18

可估算的???????? 19

小的???????? 20

拆分故事???????? 20

合并故事???????? 22

可測試的???????? 23

小結???????? 24

開發(fā)人員的責任???? 24

客戶的責任???? 24

思考練習題???? 24

第3章 ?用戶角色建模???????? 27

用戶角色???????? 27

角色建模步驟???????? 29

通過頭腦風暴，創(chuàng)建初始的用戶角色集合???????? 29

整理初始的角色集合???? 30

聚合角色???????? 31

細化角色???????? 32

兩個額外的技術???? 33

用戶畫像???????? 33

極端人物???????? 34

如果有現(xiàn)場用戶呢？???? 34

小結???????? 35

開發(fā)人員的責任???? 35

客戶的責任???? 35

思考練習題???? 36

第4章? 收集故事???????? 37

引出和捕捉需求是不適用的???????? 37

一點兒就夠用了，不是嗎？???????? 38

方法???????? 39

用戶訪談???????? 39

問卷調查???????? 41

觀察???????? 41

故事編寫工作坊???? 42

小結???????? 44

開發(fā)人員的責任???? 45

客戶的責任???? 45

思考練習題???? 45

第5章? 與用戶代理合作???? 47

用戶的經理???? 47

開發(fā)經理???????? 48

銷售人員???????? 49

領域專家???????? 50

營銷團隊???????? 50

前用戶???? 50

客戶???????? 51

培訓師和技術支持???????? 52

業(yè)務分析師或系統(tǒng)分析師???? 52

如何與用戶代理合作？???????? 52

當用戶存在但訪問受限時???? 52

當真的找不到用戶時???? 53

你能自己做嗎？???? 54

建立客戶團隊???????? 54

小結???????? 54

開發(fā)人員的責任???? 55

客戶的責任???? 55

思考練習題???? 55

第6章? 用戶故事驗收測試???????? 57

在編碼之前編寫測試???? 58

客戶定義測試???????? 59

測試是過程的一部分???? 59

多少測試才算多？???????? 59

集成測試框架???????? 60

測試的類型???? 61

小結???????? 62

開發(fā)人員的責任???? 62

客戶的責任???? 62

思考練習題???? 62

第7章? 好故事編寫指南???? 63

從目標故事開始???? 63

縱切蛋糕???????? 64

編寫封閉的故事???? 64

約束卡片???????? 65

根據(jù)實現(xiàn)時間來確定故事規(guī)模???? 66

不要過早涉及用戶界面???????? 66

需求不止故事???????? 67

故事中包括用戶角色???? 67

為一個用戶編寫故事???? 68

用主動語態(tài)???? 68

客戶編寫???????? 68

不要給故事卡編號???????? 68

不要忘記目的???????? 69

小結???????? 69

思考練習題???? 69

第II部分? 估算和計劃

第8章? 估算用戶故事???????? 73

故事點???? 73

團隊估算???????? 74

估算???????? 74

三角測量???????? 76

使用故事點???? 77

如果用結對編程呢？???? 78

“敲黑板”???? 79

小結???????? 79

開發(fā)人員的責任???? 79

客戶的責任???? 79

思考練習題???? 80

第9章? 發(fā)布計劃???????? 81

我們希望什么時候發(fā)布？???? 82

希望在發(fā)布中包含哪些特性？???? 82

故事優(yōu)先級排序???? 83

混合優(yōu)先級排序???? 84

風險故事???????? 84

優(yōu)先考慮基礎設施需求???????? 85

選擇迭代長度???????? 86

從故事點到預期工期???? 86

初始速率???????? 86

猜測速率???????? 87

創(chuàng)建發(fā)布計劃???????? 87

小結???????? 88

開發(fā)人員的責任???? 88

客戶的責任???? 89

思考練習題???? 89

第10章? 迭代計劃?????? 91

迭代計劃概述???????? 91

討論故事???????? 92

分解任務???????? 92

認領責任???????? 94

估算及確認???? 94

小結???????? 95

開發(fā)人員的責任???? 96

客戶的責任???? 96

思考練習題???? 96

第11章? 度量和監(jiān)測速率? 97

度量速率???????? 97

計劃速率和實際速率???? 99

發(fā)布燃盡圖???? 100

迭代燃盡圖???? 102

小結???????? 104

開發(fā)人員的責任???? 104

客戶的責任???? 105

思考練習題???? 105

第III部分? 經常討論的話題

第12章? 用戶故事不是什么?????? 109

用戶故事不是IEEE 830 109

用戶故事不是用例???????? 112

用戶故事不是場景???????? 115

小結???????? 117

思考練習題???? 117

第13章? 用戶故事的優(yōu)點? 119

口頭溝通???????? 119

用戶故事容易理解???????? 121

用戶故事的大小適合于計劃???????? 122

用戶故事適合迭代開發(fā)???????? 123

故事鼓勵推遲細節(jié)???????? 124

故事支持隨機應變的開發(fā)???? 124

用戶故事鼓勵參與式設計???? 125

故事增強隱性知識???????? 125

用戶故事的不足???? 126

小結???????? 126

開發(fā)人員的責任???? 127

客戶的責任???? 127

思考練習題???? 127

第14章? 用戶故事的不良“氣味”? 129

故事太小???????? 129

故事相互依賴???????? 130

鍍金???????? 130

細節(jié)過多???????? 131

過早包含用戶界面細節(jié)???????? 131

想得太遠???????? 132

故事拆分太頻繁???? 132

客戶很難對故事排列優(yōu)先級???????? 132

客戶不愿意寫故事并對故事進行優(yōu)先級排序???? 133

小結???????? 134

開發(fā)人員的責任???? 134

客戶的責任???? 134

思考練習題???? 134

第15章? 在Scrum項目中使用用戶故事?? 135

Scrum是迭代式和增量式的 135

Scrum基礎????? 136

Scrum團隊????? 137

產品待辦列表???????? 137

Sprint計劃會議?????? 138

Sprint評審會議?????? 140

每日Scrum站會???? 140

在Scrum項目中加入用戶故事???? 142

用戶故事和產品待辦列表???? 142

Sprint計劃會議中使用用戶故事? 142

Sprint評審會議中使用用戶故事? 143

用戶故事和每日Scrum站會????????? 143

案例學習???????? 143

小結???????? 144

思考練習題???? 145

第16章? 其他主題?????? 147

處理非功能性需求???????? 147

紙質還是軟件？???? 148

用戶故事和用戶界面???? 150

保留故事???????? 152

用戶故事描述bug 153

小結???????? 154

開發(fā)人員的責任???? 154

客戶的責任???? 154

思考練習題???? 155

第IV部分? 一個完整的項目案例

第17章? 用戶角色?????? 159

項目???????? 159

識別客戶???????? 159

識別一些初始角色???????? 160

聚類與細化???? 161

角色建模???????? 163

增加用戶畫像???????? 164

第18章? 故事?????? 165

Teresa的故事 165

Ron船長的故事????? 168

初級海員的故事???? 168

非海員禮品購買者的故事???? 169

報表查看者的故事???????? 169

一些管理員的故事???????? 170

結束???????? 171

第19章? 估算故事?????? 173

第一個故事???? 174

高級搜索???????? 176

評分和評價???? 177

賬號???????? 177

完成估算???????? 178

所有的估算???? 179

第20章? 計劃發(fā)布?????? 181

估算速率???????? 181

對故事進行優(yōu)先級排序???????? 182

完成的發(fā)布計劃???? 183

第21章? 驗收測試?????? 185

搜索的測試???? 185

購物車的測試???????? 186

購買書籍???????? 187

用戶賬號???????? 188

管理???????? 188

測試約束???????? 189

最后一個故事???????? 190

第V部分? 附??? 錄

附錄A? 極限編程概述 193

附錄B? 各章思考練習題參-????? 203

參考文獻???????? 217

敏捷開發(fā) 軟件開發(fā)

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

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