正式進(jìn)入新團(tuán)隊(duì)至今已有一個(gè)多月的時(shí)間，習(xí)慣性回顧這段時(shí)間的工作交付，收獲頗豐：
1. 一個(gè)從對(duì)scrum陌生，到具備scrum基礎(chǔ)的團(tuán)隊(duì)：
- 用戶(hù)故事是 開(kāi)發(fā)團(tuán)隊(duì)寫(xiě)
- 驗(yàn)收標(biāo)準(zhǔn)是 開(kāi)發(fā)團(tuán)隊(duì)寫(xiě)
- 計(jì)劃也是開(kāi)發(fā)團(tuán)隊(duì)出
- 自動(dòng)化單元測(cè)試是 開(kāi)發(fā)團(tuán)隊(duì)做
- CI/CD pipeline 是 開(kāi)發(fā)團(tuán)隊(duì)做
- TDD 持續(xù)重構(gòu) 也在堅(jiān)持踐行
開(kāi)發(fā)團(tuán)隊(duì)里面沒(méi)有人跳出來(lái)說(shuō)，這樣不行，那樣不做，反而是，"我"如何能做到更好，如何提升能力
但是，聲明一點(diǎn)，這個(gè)團(tuán)隊(duì)還不能稱(chēng)之正式進(jìn)入 Scrum 的世界，還在門(mén)口。
P.O. 是個(gè)虛擬出來(lái)的人，所以不用challenge產(chǎn)品規(guī)劃如何如何，能否賺錢(qián)如何如何，這是這個(gè)階段團(tuán)隊(duì)解決不了的事情。
2. 養(yǎng)成團(tuán)隊(duì)正向的認(rèn)知和三觀
1). 遵循工程師文化
- A. 永遠(yuǎn)嘗試通過(guò)技術(shù)的手段解決管理的問(wèn)題；
- B. 誰(shuí)牛(技術(shù)，思想，方法等)聽(tīng)誰(shuí)的；
- C. 自己的狗糧自己吃；(EAT OWN SHIT).
2). 保持對(duì)技術(shù)的追求和好奇心
不要去否認(rèn)任何自己不清楚的東西，對(duì)于新的、不明白的，反應(yīng)應(yīng)當(dāng)是 “cool，這是怎么做到的？我該如何才能也可以做到？需要學(xué)習(xí)什么?
而不是 臥槽, 這不可能，做不到
我們現(xiàn)在做不到的事情，不代表全世界沒(méi)人能做到。往往是因?yàn)槲覀兊恼J(rèn)知、知識(shí)、能力沒(méi)有cover到，
3. 一個(gè)還不夠完善的可持續(xù)擴(kuò)展、可持續(xù)重構(gòu)演進(jìn)的高性?xún)r(jià)比框架
進(jìn)入團(tuán)隊(duì)時(shí)，項(xiàng)目已經(jīng)進(jìn)行了幾個(gè)月了，依然是熟悉的配方，Spring Boot + 一堆拼湊的模塊與服務(wù)，為了微服務(wù)而微服務(wù)，形成一個(gè)強(qiáng)耦合、僵化易脆、且效率低下的框架，幾乎接近于代碼堆砌。
這種情況并不少見(jiàn)，這個(gè)是大多數(shù)java系給我的不好體驗(yàn)。歡迎來(lái)打臉，show出你好的架構(gòu)和代碼給我學(xué)習(xí)。
一開(kāi)始，我沒(méi)想改變框架，因?yàn)閾Q語(yǔ)言換框架，團(tuán)隊(duì)未必接受。尊重團(tuán)隊(duì)的選擇，很重要。
(我曾經(jīng)在Z公司，告訴大家說(shuō)我們想用 Ruby 代替 PHP 開(kāi)發(fā)核心架構(gòu)，結(jié)果就有幾個(gè)PHP明確告訴我，換語(yǔ)言他們就不干了，差點(diǎn)收不了場(chǎng)。但是最終，我們只需兩個(gè)ruby開(kāi)發(fā)人員，一個(gè)我一個(gè)初學(xué)者，就完成了 CoreAPI 與 OpenAPI的工作，上線后跑出來(lái)的數(shù)據(jù)說(shuō)明一切）
我只是在一開(kāi)始，嘗試他們正在做的東西，用 Elixir + TDD的方式實(shí)現(xiàn)給大家看，并且把每一個(gè)分解的盡可能細(xì)，先寫(xiě)自動(dòng)化測(cè)試用例，再寫(xiě)實(shí)現(xiàn)代碼，再根據(jù)需要重構(gòu)代碼。每一步都把痕跡(commit)留下，清晰的展示給團(tuán)隊(duì)。
團(tuán)隊(duì)也一直在看，一個(gè)星期后，他們提出，能否用Elixir來(lái)重寫(xiě)整個(gè)應(yīng)用？
在跟所有人分析這樣做的代價(jià)與成本和未來(lái)收益后，一致同意轉(zhuǎn)Elixir。
而我，則7x16的用了將近一個(gè)月的時(shí)間，通過(guò)TDD的方式把整個(gè)架構(gòu)搭建起來(lái)，并且把系統(tǒng)容器化，全自動(dòng)的持續(xù)集成與持續(xù)部署。
在這個(gè)基礎(chǔ)上，我可以放心的讓這個(gè)非常junior團(tuán)隊(duì)，學(xué)習(xí)TDD方式實(shí)現(xiàn)功能。
因?yàn)?，只要通得過(guò)自動(dòng)化測(cè)試的，質(zhì)量爛不下去；
只要通得過(guò)自動(dòng)化代碼檢查的，代碼爛不下去。
為何選用Elixir，而不是JAVA PHP
許多人會(huì)challenge: 為何不用 JAVA PHP 這類(lèi)大路貨，而選擇 Elixir 如此小眾的語(yǔ)言 (Ruby已經(jīng)夠小眾了，Elixir比之更小眾)？
我的回答是，成本與性?xún)r(jià)比最大化。
成本 當(dāng)前，一個(gè)能用TDD方式進(jìn)行開(kāi)發(fā)的JAVA程序員月薪是多少？
太多copy-paste黨，又貴水平又弱。
在相同成本情況下，我能讓Elixir的程序員產(chǎn)生兩到三倍以上與JAVA程序員的有效交付（同等質(zhì)量）。想了解更多的，歡迎交流。
性?xún)r(jià)比最大化
性?xún)r(jià)比 = (產(chǎn)出 / 成本)
性?xún)r(jià)比最大化，通?？梢杂靡韵氯N方式獲得:
- 成本最小化，通過(guò)不斷的壓縮成本，把分母變小。
- 產(chǎn)出最大化之加班，通過(guò)延長(zhǎng)工作時(shí)間(不斷加班再加班)來(lái)獲得更多的產(chǎn)出。
- 產(chǎn)出最大化之提升單位時(shí)間產(chǎn)出，通過(guò)提升團(tuán)隊(duì)的能力，令到團(tuán)隊(duì)在同等單位時(shí)間有更多的產(chǎn)出。
前面兩者，簡(jiǎn)單直接粗暴見(jiàn)效快，最最重要的是有這很高的可操作性，因此也成了眾多公司的銀彈、不二法寶。
最后者，操作難度非常大，時(shí)間周期長(zhǎng)，還需要有合適的指導(dǎo)教練(老司機(jī))，這也是為何敢選擇這條路的公司比較少。
我一直認(rèn)同一句話，如果一個(gè)團(tuán)隊(duì)的產(chǎn)出垃圾，
成本最小化，產(chǎn)出就更垃圾；
通過(guò)加班最大化產(chǎn)出，就是在用更快的速度產(chǎn)生更多的垃圾。
最后玩死項(xiàng)目坑死公司。
任何交付的改進(jìn)，其根源都來(lái)自于團(tuán)隊(duì)能力的提升。
管理、過(guò)程、質(zhì)量保證這些都只是輔助左右。
下面的圖，很貼切那些裸奔型團(tuán)隊(duì)：
展望
每一個(gè)事物猶如硬幣的兩面，有優(yōu)點(diǎn)也有弊端。
我們?cè)谙硎芤豁?xiàng)新技術(shù)(Elixir)和Scrum敏捷帶來(lái)的巨大好處、收益最大化的同時(shí)，
也需要面臨風(fēng)險(xiǎn)最大化的問(wèn)題，國(guó)內(nèi)市場(chǎng)上Elixir程序員極其稀缺，同樣市場(chǎng)崗位供給少，愿意轉(zhuǎn)用Elixir的程序員也就少。
因此，享受紅利的同時(shí)，也就需要肩負(fù)起相應(yīng)的責(zé)任：
布道Scrum。
布道Elixir，提供更多的崗位，力所能及的回饋社區(qū)，共創(chuàng)生態(tài)。
事情一多，才發(fā)現(xiàn)這篇總結(jié)寫(xiě)了一個(gè)多月放在那里都沒(méi)發(fā)出來(lái)，拖延癥嚴(yán)重。
標(biāo)題也不想改了，后續(xù)還有打臉的事情發(fā)生，有空再分享吧。
