10答疑篇反對996并不奮斗

加微信 發(fā)送“贈送”領取贈送精加微信 發(fā)送“贈送”領取贈送精品課發(fā)數(shù)字“2”獲取眾籌列下載2019-09-13葛俊研發(fā)效率破局之13:53大小你好，我是葛俊這篇答疑文章，已經(jīng)是我們“研發(fā)效率破局之道”專欄的10篇文章了。很多同學在這文章下面留下了精彩的留言，闡述了自己對研發(fā)效能的認識、遇到的問題以及解決方案比如，@囧囧冰淇淋，基本每節(jié)課都會整理詳細的學習筆記，并結合自己的經(jīng)驗進行思考、提煉和總結；又比如，@Geek_93f953、@Geek_1988，@Robrt小七、學留下了非常精彩的留言，這里我就不一一提及了這些留言活躍了專欄氣氛，幫助其他同學進一步思考，也激勵著我要把專欄寫得更好。所以，在這里我首先要對你表示感謝，感謝你對我的信任，也感謝你的積極參與。這9篇文章涉及的問題，我基本這9篇文章涉及的問題，我基本都在評論區(qū)直接回復過了。在今天這篇文章中，我會挑 個大家普遍關注的問題再詳細展開一下，也算是研發(fā)效能綜述和研發(fā)流程這兩個模塊的次總結與復習，打好基礎以應對接下來的工程方法、個人效能、管理和文化模塊的內(nèi)容現(xiàn)在，我們就正式開始今天的4個問題吧996在專欄第1篇文章“效能模型：如何系統(tǒng)地理解研發(fā)效能”中，我談到了996的話題。留言來看，關于我對996的態(tài)度，有些同學還存在些誤解。所以，我們再來討論下這個題第1個誤解是，硅谷的互聯(lián)網(wǎng)公司加班不太多，工作生活間的平衡做得很事實是，硅谷的互聯(lián)網(wǎng)公司，加班也比較常見。這一點，在創(chuàng)業(yè)初期的公司尤其明顯比如，我在2010年加入Facebook的時候，F(xiàn)acebook已經(jīng)比較成熟了，有接近800開發(fā)人員。但由于業(yè)務的高速發(fā)展和同事間的競爭，我們的加班都很嚴重。我每個周末去公室加班的時候，都能看到大概百分之三四十的同事在加班所以，工作和生活的平衡，完全要靠自己來調(diào)節(jié)。而我看到的是，很多開發(fā)人員實際上調(diào)節(jié)的都不是特別好，基本上只有工作沒有生活。另外，這樣的加班是自愿的，沒有加班工資。只有在一些特殊時期，比如和競爭對手拼速度的時候，公司會要求大家Lockdown（類似于國內(nèi)的封閉開發(fā)），才會有加班工資。第2個誤解是，反對996是在反對奮正如上面所說，硅谷的互聯(lián)網(wǎng)公司也有很多人在加班，我個人也是大量的主動、自愿加班。因為，我熱愛軟件開發(fā)這個行業(yè)，愿意花費大量的時間、精力為之奮斗。996，并不是反對奮斗，而是反對用工作時長，尤其是強制上下班時間，在第2篇文章“效能度量：效果不好甚至有副作用，怎么回事？”中，我提到研發(fā)效能度量困難的一個原因就是，度量數(shù)據(jù)的收集難易程度不同，人們傾向拿容易收集的數(shù)據(jù)去關效率。因此，管理者使用時長這種很直觀、很容易度量的指標去衡量研發(fā)效能，結果就是事倍功半。效率。因此，管理者使用時長這種很直觀、很容易度量的指標去衡量研發(fā)效能，結果就是事倍功半。排，方便大家提高工作效率比如 默認每周三是沒有會議的工作日，也就是盡量不安排會議，大家可以選在家工作。另外 的上下班時間很靈活，這對于需要接送孩子的員工來說，就方便了總而言之，反 996，是反對不科學地使用工作時長來提高研發(fā)效能有同學在第7篇文章“分支管理：Facebook的策略，適合我的團隊嗎？”后留言反饋，要和你澄清一下，我前邊描述的各種概念和原則，比如持續(xù)開發(fā)、持續(xù)集成、持續(xù)交付，前端（包括Web前端、移動前端等）和后端來說都是一致的以FacebookiOS應用開發(fā)為例。他們采用的也是單主干的開發(fā)分支模式，也要求代碼提交的原子性，以及master分支上線性的代碼提交歷史。在持續(xù)集成方面，他們也是使用 作為流程和質(zhì)量控制中心，進行各種各樣的代碼入庫前檢查。在持續(xù)交付方面，他們也是采用了和后端類似的方式，每隔一定時間進行一次全量的構建和驗證當然，前、后端的開發(fā)也有些區(qū)別，比如iOS的AppStore的發(fā)布周期是兩周一次，所以他們采用了兩周一次全量部署的方式，取消了日部署和熱修復部署。不過，后來Facebook采用在原生App中實時加載JavaScript的方式，在一定程度上繞過了AppStore的發(fā)布周期限制，于是之后也引入訪問即可進行驗證。而移動端開發(fā)的情況要復雜一些，F(xiàn)acebook的方式是提供App安裝服務，讓大家可以在自己的手機上安裝不同版本的App，包括master分支版本、周部署測試版本以及部署測試版本以及線上版本等，并提供自動更新的功能。通過這些自動化，使得移動開的流程更順暢在測試移動端App需求，F(xiàn)acebook進行了大量的自動化，能夠讓測試在各種不同的環(huán)境中自動運行。同時，F(xiàn)acebook還研發(fā)了一個服務化的手機池，讓開發(fā)人員自助式地把自己的App到某一個特定的硬件和操作系統(tǒng)上，并使用遠程控制進行檢驗后端先上線，同時使用功能開關讓這個API對用戶不可見；然后前端上線，最后打開功能開關完成整個功能總的來說，研發(fā)流程這個模塊中提到的各種原則，在前端和后端都同樣適用。在理解這些則之后，你可以針對具體的情況，去設計適合的流程和方法有同學留言反饋，環(huán)境問題是他們研發(fā)過程中的最大痛點。具體來說，聯(lián)調(diào)環(huán)境、測試環(huán)境的獲取，常常需要排隊。這里，我再提供些具體的解決方法吧。從我的經(jīng)驗來看，使用云的架構，尤其是在Docker和Kubernetes的支持下，把這些環(huán)比如，雖然Kubernetes沒有提供“環(huán)境”這一概念，但我們可以在它上面添加一層裝，通過InfrastructureasCode（IaC）的方式，來自動化環(huán)境的獲取和釋放。這是一比較通用的辦法。具體來說，實現(xiàn)環(huán)境服務化的思路是參數(shù)，處理諸如數(shù)據(jù)庫、MQ等服務在環(huán)境上的差異。任何規(guī)模的任何環(huán)境中。還有，如果QA可以將測試數(shù)據(jù)和測試用例也服務化，編排到管道中，就可以實現(xiàn)安全高效的一站式發(fā)布在下一篇文章中，我會與你更系統(tǒng)地討論如何給團隊配置、提供高效的研發(fā)環(huán)境。希望這樣的內(nèi)容安排，可以最大程度地幫助你解決環(huán)境問題。在第3篇文章“效能度量：如何選對指標與方法，真正提升效能？”中，我對常用的度指標給出了分類方法，以及選用的基本原則。有同學反饋，希望我能給出一些更具體的實和使用建議所以，在今天這篇文章中，我會基于不同的改進目標，分別從提供用戶價值、流程高效和量這3個角度，再給出幾個具體建議從提供用戶價值的角度來看，可以選擇以下幾個指標凈推薦值系統(tǒng)/App機時間和嚴重線上事故數(shù)；核心服務SLA可用性指標，也就是我們常說的服務能達到幾個9。這個指標尤其適用于否達成了對客戶的承諾從流程高效的角度來看，可以選擇以下幾個指標工作，詳見第3篇文章對累積流程圖的描述。一個非常有效的提高研發(fā)流程順暢度的辦法是，限制WIP。也就是說，每個環(huán)節(jié)不能同時有超過一定數(shù)量的任務。如果你想了解的反饋。發(fā)布的交易成本指的是，每次部署需要的流程工作，比如拉分支、代碼合并、行測試用例等?？紤]行測試用例等。考慮到發(fā)布的交易成本，對很多互聯(lián)網(wǎng)產(chǎn)品來說 周通常是比較適的發(fā)布頻率構建時長，指的是個人構建以及CI/CD建時長等指標。它們對持續(xù)開發(fā)和CI/CD利從質(zhì)量的角度來看，可以選擇以下幾個指標工單返工率：反映的是開發(fā)團隊的代碼質(zhì)量和自測程度，以及QA的壓力和能力持續(xù)交付通過率：執(zhí)行構建署試布全流程的成功率，反映的是開發(fā)自好了，以上就是今天的主要內(nèi)容了。如果有哪些你希望深入了解的話題還未涉及到，希望你可以留言給我。最后，我想再和你強調(diào)一下，第4篇文章“流程優(yōu)化：怎樣才能讓敏捷、精益真正為我所用？”中，提到的Why-How-What黃金圈法則和“實用主義”原則。是學習一些可供我們參考的最佳實踐。這樣，我們才能靈活運用這些原則、最佳實踐，真提升團隊的研發(fā)效能所以，在整個專欄的寫作中，我也會著重系統(tǒng)化地講解研發(fā)效能的基本原則。讓我備受鼓的是，很多同學在留言中表示會支持這個思路。這里，我衷心希望你可以通過實用主義的式，去尋找合適自己的最佳實踐感謝你的收聽，歡迎你在評論區(qū)給我留言分享你的觀點，也歡迎你把這篇文章分享給更多的朋友一起閱讀。我們下期再見！?版權歸極客邦科技所有，未經(jīng)許可不得傳播?版權歸極客邦科技所有，未經(jīng)許可不得傳播售賣。頁面已增加防盜追蹤，如有侵權極客邦將依法追究其法律責任上一09|信息流通：讓團