多終端時代敏捷實踐——蔣煒航（網易有道雲筆記）
兩年時間，一千五百萬使用者 66個版本。內部專案，起點低，3個人。兩年半，50人團隊。有道雲筆記：雲+端的產品。有個大規模的分布式檔案系統類似hadoop。有很多東西需要計算，索引，文字的模式識別等。還有其他很多問題，比如客戶端多的問題。在pc的開始第一版我們還用過mfc，很醜陋不好看；android也版本多，適配起來非常麻煩；另外各客戶端還不能是獨立的應用，得通過雲來讓使用者有相對一致的使用體驗。
各個階段的敏捷實踐：進入市場；迭代發布；開拓進取。
圍繞這幾個階段，分享敏捷是什麼。
進入市場。立項後6個月內，一切都需要被證明。開始資源有限，而且員工的信心會隨著時間丟失。資源有限，市場前景不清。開始時非常小眾，以有道的渠道去推，有沒有可能？
博士導師也是多次創業者，關注於檔案儲存系統。開發了乙個系統，以效能為賣點，但是市場不買單，所以很快就賣掉了。這個教訓學的很深。後來採用資料探勘的技術，統計的方法去處理**，去找**中的bug。有了上次的教訓，只花了6個月，加班加點把這個引擎搭出來，去買這個產品，但是發現很多大公司都已經有了找bug的系統，而且他們覺得，我們已經很多麻煩了，別再來添亂了。
作為乙個資源有限的公司，這條路看來行不太通。重新定位了一下，把思路轉變了一下，把乙個從找bug的工具轉化成管理bug的工具。相對成功，結果12年被vmware買去了，成立了乙個大資料team。
回到雲筆記，我們花了很快的時間做出了乙個基於mfc的版本。最基本的功能，同步、儲存和簡單的編輯。我們認為這是同品類最好的賣點，可能有其他的功能，但是使用者會花很多時間去適應。一開始都沒敢叫1.0版，以0.9版形式發布了。
市場反應還可以，2011.6發布0.9~2013.8發布3.4，乙個7個平台66個版本。
大規模重構進行了2次。
核心就是快速的迭代發布，為什麼要這麼做呢？
目標、啟動時機、團隊規模、擁抱變化、量化指標、測試&發布
網際網路行業中：
頻繁的按時發布（發新版本是有效的營銷方式，第三方首發，新聞稿、推薦資源預約都有檔期）第三方市場，是雙方共贏的。2business很複雜，2custorm這是非常方便和有效的。
大版本和大改動（2.0、3.0兩次很大的改版。底層儲存架構公升級，視覺風格改版，介面庫遷移，編輯器核心遷移）
要能夠通過使用者的反饋來調整版本計畫（這個迴圈我們希望越短越好，我們現在控制在2-3個月，我們會做到更快）
scrum不是萬能藥，要在實際成熟時推行。
團隊3人以上（1人，sprint週期和產品演示；2人，結對程式設計，持續整合，相互**審核）比如開始的時候，web端，服務端就乙個人。但是我們還是用了sprint週期的概念。pm還是會跟蹤專案。後來有二個人的時候，我們也不是立馬就scrum了，主要是找尋有沒有優秀的候選人去做scrum master，必須是認可scrum的精神。當然我們也不是要求每個人去認可，大部分就可以了。
這裡就不得不說到，可靠的scrum master是推行敏捷的基礎
優秀：認可敏捷，熟悉業務，團隊教練，理解優先順序
我們嘗試過用tech lead 和產品經理去做scrum master。後來不用產品經理去做了，他們有太多的事情。當然，也有兼任的，比如ios團隊。
限制規模，確保高效（沒有站立式會議，30分鐘會議，坐在一起，3-9人，每週比較重要的執行2次）30分鐘必須完成，mobile團隊慢慢變大了，得45分鐘完成，後來就切成ios和android。另外座位安排物理的比較接近，也會一起吃飯，成為飯糰。
平衡團隊的技術等級（優秀的人做什麼都優秀）
對於研發工程師來說，我們的感覺是，在engineering層面上，每個人是差不多的，除了從engineering到research的級別可能有點差距。
團隊間協作（工程之間協作為主）scrum精髓，高度自治！讓他們自己去解決。複雜的問題，有必要時強制引入scrum master會議（定義介面）類似乙個按需的機制。
擁抱變化
產品經理（原來：確定版本功能點和預期發布時間；現在：sprint前只決定功能點的優先順序；sprint後再決定發布計畫；提70%需求）看板思路：控制working progress，只讓產品經理定義優先順序。因為網際網路行業唯一不變的就是變化。
研發工程師（原來：追求大而全的技術、喜歡整體重構；現在：不鼓勵過度設計！而採用湧現式設計，每個sprint結束時有30%的時間來提新的需求或者方向——比如有人發現了乙個很好的ui庫）。我們不自覺喜歡研究比較深的問題，比如06年開始我們自己開發了乙個類似hadoop的系統。其實都有現成的開源，後來我們有意識地避免重複造輪子。
得到乙個相對穩定，相對敏捷、快速的版本發布。
量化評估
輔助指標
每個團隊的情況不一樣，比如服務端和ios端，自己控制。
測試和發布
開發團隊通過歷史資料**bug修改時間。
產品經理決定發布時間和週期。
開發流程是相對scrum穩定的週期，通過測試發現的問題返測，保證**的相對準確，可以知道該團隊能否很順利地進行下乙個scrum週期。
乙個迭代週期某項功能有問題，或者功能有變動，我們就在介面裡先關掉，先發布了。有功能無法實現，我們就放到下乙個迭代週期去執行。測試和版本發布都基於迭代發布的程度。有個問題，開始的時候，不停地去堆功能。但是有很多功能可能最後都沒被使用，這是很浪費資源的。
開拓進取的需求
列舉一些我們認為在專案裡是攻堅的部分：跨平台編輯器；各個平台的瀏覽器核心；內容格式的相容；複雜操作的邏輯等；手寫優化。一旦開始做這些事，就有很多很細節的邏輯，比如新增附件、拷貝黏貼等功能，是有難度的。另外手寫優化部分，在手機終端的處理器效能是有限的，十幾個演算法都看過了，沒有特別適合的，所以我們現在也繼續在做。舉得這兩個例子是在我們這裡認為攻堅專案。
更多更快的嘗試（天下武功，唯快不破）
挑戰：嘗試新功能，嘗試新互動
攻堅專案挑戰：主產品線的週期對這些問題來說太短（3-6個月）
風險性高，解決方案：
專人專項，保證連續性，保證週期；獨立發布，供主產品線使用。
（比如手寫，自己有自己的模組版本號，已經發布3個版本，好處是他們自己相對有自己的管控流程，有點類似agile）
挑戰：增加功能對使用者是一種干擾
增加功能會增加工程複雜度，常規的發布週期對這些嘗試來說太長（1-2個月）
解決方案：
主產品線：多平台非同步嘗試，使用外掛程式新增功能
（android平台有很多外掛程式可以呼叫）
嘗試線：用js在web前段做些快速的技術原型，使用open-api訪問開放介面，對資料進行做二次處理，一定範圍內的測試（100人）。開放乙個小的伺服器，比如內部的bbs，內部的員工試用，就可以得到很多反饋，很多思路。
幾個要點：
根據階段確定目標和方式
（各個階段的重點都不相同，根據每個階段的要求不同確定目標和方式）
採用scrum以人為先
（我們每個平台都可以等，招聘到熟悉到上任，要有合適的人。）
分而治之：平台、開發&測試、主產品&攻堅專案&快速嘗試
（太難有一招鮮吃遍天的方法了。我們可以考慮把問題變得小一點，慢慢的採用，一步一步地將agile分開落實）
q&a
問：通過什麼途徑蒐集使用者需求和反饋，怎麼確定真實和雜訊
問：需求人員如何與開發人員溝通
答：我們文件溝通比較少，我比較喜歡facebook的辦公室，open table特別容易交流，我們現在辦公室還是cube，我有時候會叫他們一起去吃飯，這要看個人性格了。這是一方面，另外文件也會有，因為測試需要這個寫測試用例。我們可能會找一兩個開發的同事熱身下，提前和需求人員溝通。
問：如果前邊的人離職了，會增加成本麼
答：因為我們自己就是重度使用者，離職的話會有影響，但是我沒怎麼感覺到。可能我們離職率比較低，呵呵。
問：團隊裡的績效考核，很多企業按數字說話，比如kpi，你們怎麼考核
答：網易有道會有數位化，一般數位化會抗在我身上，或者產品，但是在研發人員上會不是很合理吧。但是我們會有一種思想，這個數字是全體的，大家共同是乙個團隊的。因為是乙個敏捷，乙個比較透明的團隊，所以一般誰做的多，誰做的少都大家心裡都比較清楚。可能有些人比較熟悉某一塊，這一塊就一直他做，其他人看著。我們現在也鼓勵大家多探索自己不熟悉的部分。解決乙個一直困擾的問題，做乙個presentation，給大家講授，這個是放在個人績效裡頭。總結：讓老大抗指標，各開發人員自己評！
問：你們的產品有多個平台，如何處理同時發布的問題，是否會相互牽制？
答：很好的問題，我們也遇到這個問題。我們每個版本有buffer在裡邊的。我們不是每不是要求平行發布的。但是有的版本是需要這麼做的，如果趕不上，就等到下乙個scrum週期後發布，盡可能保證在平行就可以了，不是絕對的。
epoch mysql Go時代（Epoch）例項
程式中的乙個常見要求是獲取自unix紀元以來的秒數，毫秒或納秒數。這裡是如何在go程式設計中做。使用unix或unixnano的time.now，分別以秒或納秒為單位獲得自unix紀元起的耗用時間。注意，沒有unixmillis，所以要獲取從紀元開始的毫秒數，需要手動除以納秒。還可以將整數秒或納秒從...
hexo多終端管理
我們的思路其實就是把靜態檔案和hexo環境，分別存在username.github.io的master和hexo分支上。hexo d就是把public資料夾下的檔案同步到github，然後就能通過訪問部落格了。建立倉庫，建立兩個分支 master 與 hexo 設定hexo為預設分支 因為我們只需要...
tmux多終端工具
在linux伺服器上沒有辦法像在桌面系統一樣開多個終端，所以有時後進行一些操作不是太方便，所以可以使用tmux工具，建立多個終端。這裡僅僅是簡單的介紹一下如何建立多個終端和進行多個終端之間切換，tmux要建立視窗或者切換視窗，需要切換到命令模式，切換到 命令模式的按鍵為 ctrl b即可進入命令模式...