如何用敏捷搞垮一個(gè)團(tuán)隊(duì)

以下文章來源于茹炳晟聊軟件研發(fā) ，作者司文

微信公眾號的江湖里有個(gè)說法，叫「三千字?jǐn)囝^臺」，也就是一篇文章不太會寫超出了3000字，因?yàn)榇蟛糠秩藢σ黄恼碌拈喿x極限就是3000字（甚至更少），超了字之后大家讀不完，今后也不太會去讀了，最后導(dǎo)致看的人越來越少。
我自己也比較糾結(jié)，后來意識到一個(gè)問題，我寫文章主要對內(nèi)容負(fù)責(zé)，大家看不看根本就不是我所關(guān)心的問題，我的核心目標(biāo)是把內(nèi)容寫好，所以也就釋懷了，我只關(guān)注內(nèi)容是否能夠表述清楚、邏輯是否合理。
提前告知大家，今天的篇幅略長，主要是敏捷這個(gè)話題，涉及的面太廣了。

我眼中的敏捷

掐指一算，自己從2000年左右第一次接觸敏捷，至今已有10多年了。
還記得那時(shí)第一次參加了一場為期2天的敏捷的培訓(xùn)，老師是個(gè)老外，中文講得不錯(cuò)、很健談，課上有概念、有游戲、也有很多學(xué)員之間的互動，整個(gè)體驗(yàn)還是不錯(cuò)的。
在2天的培訓(xùn)最后結(jié)束時(shí)，老師讓每位學(xué)員談一下自己對敏捷的感受。
我當(dāng)時(shí)也是年輕（年少無知），我直接大聲說出了自己的感受：「敏捷更適合存在于烏托邦的團(tuán)隊(duì)或公司里，不適合大規(guī)模推廣」（現(xiàn)在看來肯定是啪啪打臉，因?yàn)楫?dāng)時(shí)我的認(rèn)知水平，只能到此程度）。
那時(shí)，我覺得敏捷中很多價(jià)值觀、宣言、規(guī)則流程設(shè)立的太理想化了，曾經(jīng)在瀑布式模式開發(fā)過的小伙伴應(yīng)該清楚，現(xiàn)實(shí)世界是很復(fù)雜的、人性也是非常復(fù)雜的，各種奇奇怪怪的事情、人和人之間的矛盾、組織與流程之間的不協(xié)調(diào)、領(lǐng)導(dǎo)風(fēng)格的多種多樣，想找一個(gè)全部都認(rèn)同敏捷文化、且不折不扣去執(zhí)行的團(tuán)隊(duì)真的太難了?。ìF(xiàn)在行業(yè)中也依舊很難，但不代表沒有）
培訓(xùn)結(jié)束回到公司，領(lǐng)導(dǎo)問我培訓(xùn)參加過后，感覺如何。我不遺余力的給老板和團(tuán)隊(duì)講，敏捷有多好，敏捷有多么高大上。原因不為別的，是因?yàn)樗麄儾欢艚荩疫@么說更顯得自己2天的培訓(xùn)時(shí)間沒有白白花掉、酒店的自助餐沒有白吃。
說實(shí)話，當(dāng)時(shí)的我其實(shí)只是想告訴自己的領(lǐng)導(dǎo)，選擇讓我去參加培訓(xùn)是一個(gè)多么明智的決定，而并非我對敏捷的理解有多么深刻。
10多年過去了，隨著時(shí)間的流逝，對人閱歷、對事情的判斷、對敏捷的認(rèn)識，和當(dāng)初有了不一樣的理解和感悟。
現(xiàn)在，我的看待態(tài)度是：
敏捷只是一個(gè)開發(fā)模式的工具而已，既不是長生不老藥，也不是解決一切問題的辦法，不用盲從，也不用鄙夷，如果你覺得合適，你就拿來用就好了。

之前薛兆豐老師有一個(gè)說法，如何讓一只鸚鵡成為經(jīng)濟(jì)學(xué)家呢？
答案是：只需要讓鸚鵡學(xué)會「需求」和「供給」兩個(gè)關(guān)鍵詞，這只鸚鵡也能成為經(jīng)濟(jì)學(xué)家。
這個(gè)調(diào)楷一方面說明了「需求」和「供給」是經(jīng)濟(jì)學(xué)最核心的概念和邏輯；另一方面又說明了，看似簡單的「需求」和「供給」概念，想要搞清楚并不是很容易。

同樣，對于敏捷，如果讓我給出最核心的兩個(gè)詞讓鸚鵡成為敏捷教練，我會選擇「產(chǎn)品」和「團(tuán)隊(duì)」這兩個(gè)詞。
產(chǎn)品這個(gè)關(guān)鍵詞，可以衍生出敏捷中很多概念：產(chǎn)品思維、產(chǎn)品需求、產(chǎn)品迭代、產(chǎn)品價(jià)值等。面對產(chǎn)品需求不明確、能為用戶創(chuàng)造哪些價(jià)值不知道、用戶體驗(yàn)又要超過同行的產(chǎn)品，這已經(jīng)超出了普通程序員在學(xué)校里面學(xué)習(xí)的計(jì)算機(jī)知識了。
團(tuán)隊(duì)這個(gè)關(guān)鍵字，可以衍生出敏捷中很多概念：人性、角色、團(tuán)隊(duì)能力、團(tuán)隊(duì)溝通、團(tuán)隊(duì)承諾等。面對不同背景、學(xué)歷、來自五湖四海、脾氣秉性差異極大的同事們，能不能把這個(gè)團(tuán)隊(duì)服務(wù)好，已經(jīng)遠(yuǎn)遠(yuǎn)超出了Scrum Master的知識領(lǐng)域了。
朋友們可能會感到奇怪，我為什么沒有提到敏捷的各種流程、各種會議、各種價(jià)值觀、各種宣言？
我的認(rèn)知是，敏捷僅僅是個(gè)抽象工具而已，承載敏捷的核心無非就是：「產(chǎn)品」和「團(tuán)隊(duì)」，各種流程需要團(tuán)隊(duì)去執(zhí)行、各種角色需要團(tuán)隊(duì)去勝任、各種能力需要團(tuán)隊(duì)所具備、各種溝通需要團(tuán)隊(duì)參與、各種宣言則需要團(tuán)隊(duì)去承諾。
而團(tuán)隊(duì)的工作，就是把不確定的產(chǎn)品需求逐漸交付落地，幫用戶弄清楚產(chǎn)品價(jià)值，交付最小可用產(chǎn)品（扔個(gè)石子探探路，摸索前進(jìn)），在此基礎(chǔ)上小步快跑、快速迭代（步子太大容易掉坑里，慢慢摸著石頭過河）。所以，敏捷模式最適合的就是那種「還不確定、還不完善、還沒想清楚的產(chǎn)品需求」，團(tuán)隊(duì)逐漸調(diào)整磨合、不斷交付產(chǎn)品價(jià)值。

普通程序員眼中的敏捷

曾經(jīng)有一位朋友跟我這樣討論過敏捷，他覺得現(xiàn)在互聯(lián)網(wǎng)這些公司之所以推行996工作模式，敏捷開發(fā)模式在背后起到了推波助瀾的作用。他還舉了很多例子，我取其中最有代表性的給大家分享一些。
例子1：上線節(jié)奏太快
很實(shí)際，很多公司老板之所以用敏捷，就是為了產(chǎn)品早點(diǎn)上線，最終事情做不完，大家只能加班完成了。
以前瀑布式開發(fā)模式，項(xiàng)目的開發(fā)周期可能是半年到一年左右，至少也有一個(gè)季度。從需求調(diào)研、立項(xiàng)、技術(shù)的選型、架構(gòu)的設(shè)計(jì)、基礎(chǔ)環(huán)境搭建這些都需要時(shí)間，包括項(xiàng)目的開發(fā)、測試、項(xiàng)目延期等等。
而敏捷開發(fā)模式推崇一般2周一個(gè)迭代，在什么都不明確、什么都不知道的情況下，我們直接開始干，先做一個(gè)最小可交付的版本。
例子2：完不成任務(wù)，在同事面前丟面子
很真實(shí)，完不成當(dāng)天的工作，程序員只能加班完成了。
敏捷的站會是要當(dāng)著同事們的面，說清楚昨天認(rèn)領(lǐng)的工作為什么沒有完成，這讓我這位朋友感覺很丟人。
他說，以前在瀑布式開發(fā)模式的時(shí)候，3天內(nèi)搞定1個(gè)模塊的功能，妥妥的沒問題，自己合理安排時(shí)間，哪怕下樓抽煙摸魚也好、電腦里看看小說也好，時(shí)間可以自由安排，規(guī)定時(shí)間內(nèi)自己搞定就好了。現(xiàn)在敏捷模式，任務(wù)要大家一起估點(diǎn)，估多了時(shí)間點(diǎn)可不行，大家都看著呢；每天要匯報(bào)昨天工作的進(jìn)度，每天任務(wù)安排的緊緊的。
他說，程序員也應(yīng)該是一個(gè)知識管理、創(chuàng)造性類型的工作崗位，不應(yīng)該是搬磚、執(zhí)行類的崗位，我今天狀態(tài)不好，就是不想寫代碼了，效率自然就低了；我明天狀態(tài)奇佳，一小時(shí)頂五個(gè)小時(shí)的效率，效率自然就高了。（我則笑他，你一個(gè)碼農(nóng)，搬磚就好好搬，還跟我講狀態(tài)了……）
最后，他給我的結(jié)論是，敏捷是對人性的不尊重。
聽了以后我瞬間無語，試圖跟他討論一番。但轉(zhuǎn)念一想，這也很正常。大家同樣是讀一本《百年孤獨(dú)》經(jīng)典名作，一百個(gè)讀者就有一百個(gè)哈姆雷特，何況是敏捷呢？

搞垮團(tuán)隊(duì)的10種場景

趁五一假期不能出門游玩的這幾天，我整理了「用敏捷搞垮一個(gè)團(tuán)隊(duì)」的十個(gè)場景，希望讓大家重新認(rèn)知理解敏捷，是怎樣瞬間搞垮一個(gè)團(tuán)隊(duì)的：
如果你的團(tuán)隊(duì)目前符合1種情況，說明你們團(tuán)隊(duì)現(xiàn)在用敏捷用的挺不容易的。
如果你的團(tuán)隊(duì)目前符合2種情況，說明你們團(tuán)隊(duì)現(xiàn)在過的并不如意。
如果你的團(tuán)隊(duì)目前符合3種情況，說明你們團(tuán)隊(duì)已經(jīng)開始反感敏捷模式了。
如果你的團(tuán)隊(duì)目前符合3種以上的情況，我勸你早點(diǎn)跑路找下家。

1、老板和團(tuán)隊(duì)都不了解敏捷

相信我，這點(diǎn)非常致命。
很多老板對敏捷的理解還停留在：「敏捷就是快」的概念上。之前10個(gè)人干的活，現(xiàn)在用了敏捷，5個(gè)人就干完了。
記得有一位公司負(fù)責(zé)人跟我談到敏捷，他的觀點(diǎn)是：小學(xué)生都知道，敏捷就是快啊，效率提升、成本降低，老板們終于不用強(qiáng)制要求程序員加班了，只要大家敏捷起來就好了嘛。
先談老板
很多老板只看到了敏捷的好處，卻沒有看到敏捷開發(fā)模式的適用場景和缺點(diǎn)，在不是很懂的情況下貿(mào)然引入敏捷，將會給團(tuán)隊(duì)帶來毀滅性的打擊。
再談團(tuán)隊(duì)
網(wǎng)絡(luò)上有很多妖魔化敏捷開發(fā)的段子，很多朋友對敏捷也是一知半解，在團(tuán)隊(duì)成員半懂似懂的情況下推行敏捷，得不到整個(gè)團(tuán)隊(duì)對敏捷的支持和認(rèn)同，基本上是很難成功的。
所以，在老板和團(tuán)隊(duì)都不了解敏捷的情況下去推行，你大膽放心的搞敏捷，你肯定能夠成功的，因?yàn)槟汶x搞垮整個(gè)團(tuán)隊(duì)不遠(yuǎn)了。

2、只有軟件技術(shù)團(tuán)隊(duì)敏捷，其他人不敏捷

也是很無奈的一點(diǎn)，軟件研發(fā)部門的管理范疇僅限于研發(fā)，當(dāng)你們的技術(shù)領(lǐng)導(dǎo)想推行敏捷時(shí)，公司內(nèi)其他部門既不支持、也不懂敏捷、更談不上認(rèn)可敏捷，那這樣的敏捷也只能在軟件研發(fā)范圍自嗨而已。
尤其是業(yè)務(wù)方，他們只關(guān)心產(chǎn)品什么時(shí)候上線，不關(guān)心程序員今天開什么站會、寫了幾行代碼、提了幾個(gè)bug。
這一點(diǎn)近些年有所好轉(zhuǎn)，因?yàn)橛械臉I(yè)務(wù)部門也開始敏捷了。（說明產(chǎn)品方也開始卷了）
所以，僅軟件研發(fā)部門敏捷，其他配合部門不敏捷，也是白忙活，假敏捷。

3、團(tuán)隊(duì)技術(shù)能力較弱

在團(tuán)隊(duì)能力相對較弱的情況下貿(mào)然引入敏捷，對團(tuán)隊(duì)來說也是滅頂之災(zāi)。
有人說，我們都是受過九年義務(wù)教育的人，能力上的差別有那么大嗎？還滅頂之災(zāi)，不要忽悠我。





雖然你們是受過九年義務(wù)教育的人，而我也只是比你們牛一點(diǎn)點(diǎn)，我讀了10年（復(fù)讀一年）。
這里說的能力不單單指技術(shù)能力，通俗的講，是團(tuán)隊(duì)的每一位成員有沒有獨(dú)當(dāng)一面的能力。

團(tuán)隊(duì)能力 = 每位成員的（技術(shù)能力 + 溝通能力 +需求理解能力+補(bǔ)位能力及意識等）

請參考上文朋友公司內(nèi)使用敏捷后所吐槽的2個(gè)感受：上線太快、工作完不成。
問題的本質(zhì)其實(shí)是因?yàn)閭€(gè)人能力較弱、無法適應(yīng)敏捷的交付節(jié)奏而導(dǎo)致的。換句話說，你要玩敏捷，得團(tuán)隊(duì)里面得都是高手才行。
俗話說，一位優(yōu)秀的程序員的工作效率抵十位平庸的程序員（金庸小說里面一個(gè)喬峰頂幾十個(gè)雜魚）。
國內(nèi)很多軟件團(tuán)隊(duì)是不具備這個(gè)要求的，貿(mào)然引入敏捷，只能是照貓畫虎、東施效顰，搞垮一個(gè)團(tuán)隊(duì)輕輕松松。

4、公司制度文化對犯錯(cuò)0容忍

上文說了，敏捷模式的優(yōu)勢在于，當(dāng)你產(chǎn)品需求還不確定時(shí)，可以摸著石頭過河，先交付最小可用產(chǎn)品，先讓產(chǎn)品上線，然后我們快速迭代、小步快跑、慢慢優(yōu)化。
在這個(gè)過程中必然會有損耗、必然會犯錯(cuò)，因?yàn)閳F(tuán)隊(duì)接到的是一份不確定的產(chǎn)品需求（有時(shí)候甚至是一句話的需求）。在這種情況下，如果公司或團(tuán)隊(duì)文化是對犯錯(cuò)0容忍的文化，本身就與敏捷提倡的文化相違背。尤其涉及到上線失敗等問題，更是很多企業(yè)不可容忍的高壓線，畢竟站在公司的角度會有損失、會有人來承擔(dān)責(zé)任、會有人受到懲罰，最后也只能是敏捷來背鍋。
大家都是成年人，職場如戰(zhàn)場，如果做不好就要重罰。如果犯錯(cuò)不用受罰，做錯(cuò)了事不用道歉，LV每年出這么多包包干嘛用的？

5、錯(cuò)把「噱頭概念」當(dāng)成「提效法寶」

老板們喜歡新鮮方法，TDD、BDD，這些新鮮玩意國外的團(tuán)隊(duì)玩的很很溜，我們也必須試一試。
我只能說，如果要這么做，用不痛不癢的邊緣項(xiàng)目練手還差不多，隨便你怎么玩。如果是公司的核心業(yè)務(wù)，那也就離作死不遠(yuǎn)了。
TDD和BDD目前行業(yè)內(nèi)還尚沒有真實(shí)、靠譜的優(yōu)秀實(shí)踐項(xiàng)目，至少，從我的角度，目前能看到的就是這樣一個(gè)現(xiàn)狀。
BDD很多敏捷教練到處宣講的也只是實(shí)驗(yàn)室內(nèi)的案例，個(gè)人認(rèn)為就是一個(gè)被炒作的噱頭而已，做不起來的。
參加過BDD的培訓(xùn)你就會發(fā)現(xiàn)，敏捷教練給你傳授的無非就是用cucumber寫個(gè)given-when-then的框架，寫幾個(gè)訂飛機(jī)票的demo、寫個(gè)購物車下單的流程，這些都講得通，但實(shí)際項(xiàng)目遠(yuǎn)比你這些復(fù)雜，遠(yuǎn)不是用cucumber整個(gè)BDD就弄明白的。就好比你是程序猿，寫個(gè)hello world沒問題，但這個(gè)玩意不足以應(yīng)付真正的工作??！
再說TDD這玩意，號稱是測試驅(qū)動開發(fā)。
TDD如果讓測試工程師牽頭來搞，測試工程師一年到頭能寫多少行代碼、能設(shè)計(jì)多少個(gè)類圖、畫了多少個(gè)系統(tǒng)的架構(gòu)設(shè)計(jì)，你叫測試工程師從業(yè)務(wù)場景的維度驅(qū)動開發(fā)工程師去做開發(fā)，這不是搞笑么？讓測試工程師教開發(fā)工程師理解需求、寫代碼，讓團(tuán)隊(duì)在開發(fā)和測試之間來回的返工，我們最好期待最后可以達(dá)到改1個(gè)Bug，需要優(yōu)化整個(gè)架構(gòu)的目標(biāo)。

TDD如果讓開發(fā)人員自己來搞，說白了，開發(fā)有能力把TDD整溜了，那么他不用TDD一樣可以把代碼寫得很好，所以TDD這玩意不能雪中送炭，只能錦上添花。

6、不重視提效工具

我們應(yīng)該重視能夠提高大家工作效率的工具和方法，而不是野蠻地用「加班」的方式來解決工作效率問題。
前面吐槽了TDD和BDD，但并不代表整個(gè)行業(yè)沒有好用的提效工具，恰恰相反有很多，這里堪比「好萊塢電影市場」一樣琳瑯滿目，你能找到各種各樣的提效小工具、小平臺，網(wǎng)上大多數(shù)都已經(jīng)有開源的了，即使沒有，你根據(jù)自己的痛點(diǎn)也能夠在公司內(nèi)研發(fā)出來。
根據(jù)茹炳晟老師的研發(fā)效能雙流模型的分享，我列舉一些大家不常見的提高工作效率工具插件，希望對大家有所幫助：
IDE精準(zhǔn)代碼提示：AiXcoder
自動加載代碼變更：JRebel、Nodemon
代碼質(zhì)量檢查：Sonar、Lizard
單元測試用例自動生成：EvoSuite
混沌工程：ChaosToolkit、ChaosBlade
精準(zhǔn)測試：Jacoco

除了上述，我在公司里也和同事們經(jīng)常利用業(yè)余時(shí)間開發(fā)一些「提效」的工具，我寫的書《敏捷測試高效實(shí)踐 測試架構(gòu)師成長記》里面就介紹了一款：能自動生成接口自動化測試腳本的工具。感興趣的可以直接拖至文末掃二維碼購買。
再多說一句，前段時(shí)間某位大廠的開發(fā)領(lǐng)導(dǎo)跟我討論技術(shù)時(shí)，聊到了自動化測試這塊，這位技術(shù)團(tuán)隊(duì)的大神認(rèn)為自動化測試是割韭菜的概念，統(tǒng)統(tǒng)要砍掉。（我是真心服了）
那位大神在上線前，對著測試工程師說：「是時(shí)候展現(xiàn)測試工匠精神的時(shí)候了，我們從0造輪子，大家趕快用鼠標(biāo)“點(diǎn)點(diǎn)點(diǎn)”，把所有功能都回歸一遍」。
我覺得這位所謂的「技術(shù)大神」內(nèi)心是對技術(shù)是沒有敬畏的，此時(shí)心疼他團(tuán)隊(duì)的測試工程師三秒鐘。

7、試圖用敏捷解決技術(shù)問題

敏捷只是個(gè)抽象的工具、不是解決技術(shù)問題的手段。很多公司老板會說：「你們不是敏捷了嘛，怎么這個(gè)xxx問題都搞不定？」

開發(fā)過程中遇到的各種技術(shù)問題，最終還是得靠技術(shù)能力去解決。
大家可以參考場景三，這里不過多贅述了。
所以，想要搞垮團(tuán)隊(duì)呢，大家遇到問題千萬不要著急，要冷靜，因?yàn)榻裉旖鉀Q不了的問題，明天也解決不了。

8、不重視「人」，重「流程」

很多國內(nèi)大公司都有這個(gè)通病，為了不讓某位人才成為公司進(jìn)步和發(fā)展的瓶頸，通常會把他的工作進(jìn)行拆分、分解，由流程代替人才的稀缺性。
而敏捷團(tuán)隊(duì)恰恰相反，敏捷團(tuán)隊(duì)的規(guī)模很小，敏捷的基礎(chǔ)就是團(tuán)隊(duì)，敏捷是由人來參與的，重視團(tuán)隊(duì)中「人」比重視敏捷中的「流程」更有意義。
如果你是某個(gè)團(tuán)隊(duì)的負(fù)責(zé)人，可以自己問自己2個(gè)方面的問題：
1、有沒有真正的尊重團(tuán)隊(duì)中的每一位成員，有沒有充分讓他們發(fā)揮自己的才能？有沒有幫助他們成長、給予更多進(jìn)步的機(jī)會？
2、團(tuán)隊(duì)中的創(chuàng)新情況如何，可以落地嗎？有沒有造輪子？能不能真正解決團(tuán)隊(duì)中的痛點(diǎn)？

作為團(tuán)隊(duì)的負(fù)責(zé)人，如果沒有在團(tuán)隊(duì)身上花時(shí)間，能導(dǎo)致的結(jié)果只有：團(tuán)隊(duì)的核心人員不斷流失，團(tuán)隊(duì)的普通成員沒有工作想法，你說干什么他們就干什么。
最終，使團(tuán)隊(duì)中的所有人統(tǒng)統(tǒng)躺平：歲月靜好，現(xiàn)實(shí)安穩(wěn)，KPI和OKR（還有Google剛剛宣布的GRAD）隨緣吧，一切都是最好的安排。
從敏捷中的價(jià)值觀就可以看出來，敏捷開發(fā)模式是很在于「人」這個(gè)主體的，畢竟所有的敏捷活動都是由「人」來參與完成的，提高人才密度才是實(shí)現(xiàn)團(tuán)隊(duì)敏捷的正確姿勢。

9、沒有請真正的敏捷教練

什么？還需要敏捷教練？請一位敏捷教練的費(fèi)用這么貴，我們自己學(xué)習(xí)學(xué)習(xí)，直接自己當(dāng)教練就好了嘛。既省錢，還能學(xué)到東西， 一舉兩得。
況且我的友商早就敏捷了，我們連抄作業(yè)都不會抄嗎？
你還別說，我們程序猿都是絕頂聰明的人，我也不例外，雖然我只是絕頂而已。
找一名真正的敏捷教練，能帶給團(tuán)隊(duì)一種精神上、思想上的洗禮，這是和自學(xué)成材的敏捷教練最大的區(qū)別。
很多要點(diǎn)、坑、優(yōu)秀的實(shí)踐、業(yè)內(nèi)最近流行的工具等，這些知識都能從他們那里獲取，這是自學(xué)成才的敏捷教練所不具備的。

10、既然敏捷了，還要什么文檔

敏捷價(jià)值觀里提倡的是：可以工作的軟件要高于詳盡的文檔。并沒有說就不要文檔??！
不重視文檔這件事，在項(xiàng)目前期還好，產(chǎn)品的業(yè)務(wù)邏輯大家腦子都記得很清楚。但隨著時(shí)間推移，隨著團(tuán)隊(duì)成員的離職、入職、借調(diào)和請假，隨著討論的更加深入……。
文檔較少，導(dǎo)致大家信息理解不一致，每個(gè)人對同一份需求都產(chǎn)生了自己的理解，有很多需求和設(shè)計(jì)都是自相矛盾的。導(dǎo)致溝通成本增大，犯錯(cuò)誤的概率不斷增大，最終也會搞垮一個(gè)團(tuán)隊(duì)。
最后，來個(gè)小小的總結(jié)，打1個(gè)不太恰當(dāng)?shù)谋扔靼桑?br>敏捷，就像“天上人間”里面的漂亮小姐姐，很多人都想占她的便宜，但沒有一個(gè)真心想娶她回家。

作者：司文


歡迎關(guān)注微信公眾號 ：Python測試社區(qū)