序
之前在 Gitchat 上了解過吳穹博士的分享，也早就知道吳穹博士是個喜歡在研發微信群里發紅包的土豪。部門給了這個機會，參加了吳博的培訓，珍惜這次機會，收貨滿滿。寫一些總結，也列了一些分歧，給自己做個備忘，給組里同事做個分享。
金句分享
使用創業者的心態參與工作才能體現人生的價值。
目前科技的轉型更需要創業心態，快速試錯。隨著業務的發展去學習，在學習的時候稍微夸張點，如果解決問題需要的技能點是100，那么就按照1000去努力。
在XX環境下，很多新系統生出來就是一個老頭子了
共勉，想想挺可怕，但事實還沒有那么糟糕。進公司做 DX 系統 3 年了，梳理的時候發現系統之間技術實現、業務模式基本沒太大變化；而這 3 年，恰恰是互聯網興起變革大爆炸的 3 年。還有新業務線新系統在誕生......
關于心流 (flow) 和 稀缺
正真留心的事情才會產生心流，有同感。而《稀缺》因為改變吳博的人生觀而被他極力推薦，我又做了一些 延伸閱讀。感覺道理和創客心態是互補的。稀缺并不可怕，可怕的是稀缺心態！過分極端可能會導致稀缺心態，需要把眼光放遠一點，看看我們是如何越忙越沒有時間的，如何越窮越沒有錢的，如何越創新越沒有跳出牢籠的。
方法論
- 影響地圖
- 精益數據分析
- Quick Start
- 不確定性管思維處理方式
不確定性引向低成本，圖中需求特性才是突破點，這和“會砍需求的 PM 才是好的 PM“ 的道理是相通的。
Quick Start 的啟動方式確實是好用，有幸跟著亮哥和同事們做過一個快速啟動，效率很高。
不確定的問題先給個可能是錯誤的解決方式，才能推動事情進行下去。這個學習以后已經有了很好的日常應用和實踐。比如雙姐推動系統功能細化時，就是采用先主動整理一遍初稿再約大家討論的方式，來應對連續幾次討論會大家無法都按時參加的窘境。
TO DO & TO SHARE
1.顆粒化大需求，用 As I So 定義最小故事實例化，需求會討論形式優化
細化需求這個我們組一直就在做，會有專人在分析評估需求時，重新拆分闡述需求，形成為開發服務的在線wiki文檔。我們組的開發是幸福的，他們看到的不是業務的一句話需求，而是細化后的有圖文、甚至包含Gist代碼示例的需求，所以開發起來可以進入心流之境。我們需要改進的就是細化需求的粒度，和闡述最小故事的描述方式。作為...我可以...以便于... (As I So) 這樣的句式可以幫助實例化需求。
另外吳博提到需求會討論的形式要做一些改變。恰巧，我們組在前一周就剛剛自發變革了需求討論會的方式。開發可以主動分組參與討論需求，而不是以往會議聆聽者的形式，這樣效率高，而且避免了需求理解的二一性。組里自發的變革和吳博倡導的方案不謀而合，這是一件很值得與組里同事分享的點，也激勵和肯定我們小團隊在研發中的思考和進步。
2.開發測試不分家，Mock、Fake保證最小驗證
調整測試、開發分迭代的不同步現狀，增加 Check Point 快速檢視進度。Mock關聯系統接口，Fake后臺數據都是我們目前開發過程中沒有做到的。預計三月底開始調整和組內推行。
3.功能、埋點監控、自測是開發任務的一部分
在開發過程中，開發主動做埋點監控的意識還比較薄弱，需要分享和落實。
4.學習灰度發布的實施方案
生產問題無法完全杜絕，而出生產問題其實并不可怕，只要問題解決修復的快，那影響是可以忽略不計的?；叶拳h境可以更快的驗證生產，同時可以及時的切換、回滾。
分歧和反思
其實談不上分歧，吳博只是基于目前我們的現狀給了一個妥協的解決方案，而更偏理想主意的我才有了不一樣的看法。
分歧一、自動化測試
實現自動化測試要求是很高的，需要開發人員具有測試的意識，測試人員具有開發的能力。實際實施起來很困難，但困難并不代表我們不去做。不做其實是降低標準，妥協的一個做法。我希望一個團隊的成員每個都是強悍的，做開發做測試都是OK的。這里推薦一篇和我們團隊分享過的文章程序員怎樣鑒定強悍的小團隊，別人一個小團隊牛到沒有專門的測試人員。所以，理想是美好的，而如何真正做好自動化測試才是問題解決之道。
分歧二、電子看板和實體看板
我認為電子看板好，我們組作為神兵的小白鼠客戶，最早接入電子看板。對比以前的實體看板，電子看板方便很多，使用以后，至少我是不會再去花很多精力維護實體看板。但電子看板的問題在于，如何可視化體現項目的進展、阻礙、積壓，這個我們還需要去摸索，也是我們的TO DO項，實現起來也并不難。
總結
非常感謝吳穹博士這2天培訓分享的精華，我大大小小記了27個要點，主要的都列在上面了，還有一些需要做發散和延伸性閱讀學習。也爭取盡快在工作實踐中靈活應用。
