國外在軟件研發(fā)變革、研發(fā)效能纤虽、組織賦能這方面進行系統(tǒng)的探究比我們領(lǐng)先許多，2018年出版的中文版《DevOps實踐指南》包含了眾多科技公司在較早(2020左右)時的一些敏捷&DevOps實踐案例绞惦，現(xiàn)在看來依然具有很大的參考價值逼纸，而里面的一些措施與手段，是現(xiàn)今國內(nèi)IT業(yè)還在摸索的济蝉。

    筆者目前擔任國內(nèi)大型商業(yè)銀行的DevOps教練杰刽，就實際工作而言菠发，阻礙頗多且繁雜，其中90%都是傳統(tǒng)軟件研發(fā)思維與敏捷的碰撞產(chǎn)生的摩擦贺嫂，因此本文將日常工作中遇到的一些“坑”結(jié)合書本中的理論進行對比討論滓鸠，相比于只識理論，結(jié)合實際場景特別是國內(nèi)IT研發(fā)現(xiàn)狀來看更能夠加深認知涝婉，希望對以下三種讀者有所裨益：

• 對正準備實施 DevOps或敏捷的企業(yè)哥力，提醒它們能夠做好充足準備，不打無準備的仗墩弯，認識到 BizDevOps的價值與本質(zhì)，不至于一腔熱血開始寞射，雞飛狗跳中結(jié)束.
• 對正在實施 DevOps或敏捷的企業(yè)幫助他們 think out of the box渔工，在風風火火的實施中，不要只停留在虛假的繁榮桥温，讓敏捷和DevOps對企業(yè)的發(fā)展產(chǎn)生本質(zhì)上的積極影響.
• 對已經(jīng)實施 DevOps 或敏捷到一定程度的企業(yè)幫助他們回過頭來查漏補缺引矩，看下有沒有遺漏掉業(yè)務側(cè)的缺失而引起的瓶頸，能否將業(yè)務側(cè)也納入到企業(yè)數(shù)字化戰(zhàn)略實施的全景中侵浸，建立起貫穿全流程的交付價值流旺韭，進一步釋放企業(yè)商業(yè)價值.

一、前言

二掏觉、流動原則

• 流動原則放在第一步是因為它是轉(zhuǎn)型的基礎(chǔ)区端，發(fā)現(xiàn)問題、優(yōu)化問題澳腹、解決問題织盼、提高效能，空口無憑酱塔，我們必須建立了統(tǒng)一的視野沥邻，所有stakeholder 都在 same page以后才有討論的基礎(chǔ)，否則就是雞同鴨講羊娃。如何能達到這一目標唐全？我想首先建立全局端到端的價值流圖是一個很好的方法，為什么價值流圖這么重要蕊玷，因為它是可視化的基礎(chǔ)邮利，我們都知道精益來源于豐田這個車企，豐田作為實體制造業(yè)集畅，價值流先天可視化近弟，隨處可見，因此“一個組織基于客戶的需求所執(zhí)行的一系列有序的交付活動”并不需要非惩χ牵刻意的梳理祷愉，而作為IT軟件研發(fā)而言窗宦，因為非實體，所以很多流程中的阻塞點非常難以發(fā)現(xiàn)二鳄，其次赴涵，IT軟件研發(fā)的流程因為操作頻繁且成本低(鼠標點一點就可以踢皮球)，再加上大型企業(yè)中订讼，各個管理平臺髓窜，造成數(shù)據(jù)孤島，所以我們將整個過程和狀態(tài)可視化出來欺殿，便可以一目了然的發(fā)現(xiàn)問題了寄纵，基于發(fā)現(xiàn)的問題，進行特別的優(yōu)化脖苏，才能藥到病除

-流動原則里面的有6個內(nèi)容：
-- 使工作可見：前面已經(jīng)說了
--限制在制品數(shù)：比如緊急需求插隊的情況程拭，雖然日常中很難避免，但并不是一件值得推崇的事棍潘。因為前序工作還沒有完成恃鞋，新的工作又開始，極有可能導致前序工作的問題亦歉，另外數(shù)量的增加恤浪，對于質(zhì)量的控制就會變得松懈。負責人員需要不斷在不同的任務間切換肴楷，犯錯的可能也會增加
--減小批量大兴伞：批量越大，交付時間越晚阶祭，那么發(fā)現(xiàn)問題的時間就越晚绷杜，修復成本就越高，結(jié)合實際便是每次都是開發(fā)完大量的功能以后濒募，才開始做測試鞭盟，質(zhì)量檢查等，小批量便是每次代碼改動以后觸發(fā)提交級構(gòu)建流水線完成基本的質(zhì)量檢查
--減少交接次數(shù)：融合團隊瑰剃，兩個披薩團隊可以在一定程度解決這個問題齿诉，比如環(huán)境的申請、測試的執(zhí)行都是團隊內(nèi)部完成晌姚，那么來回扯皮推諉的事情就會少很多
--消除價值流中的困境和浪費：比消除浪費更需要先實施的是如何找到浪費粤剧，那么可視化的價值流便可以有效幫助我們識別阻塞和浪費，當浪費可視化以后挥唠，再來系統(tǒng)性的消除便會容易很多抵恋。比如，當我們發(fā)現(xiàn)其實大量的時間都在尋找正確的人提供資源宝磨，完成工單流程的時候弧关，其實這就是浪費盅安，我們是否可以通過明確的在線可視化流程，標準化工程來完成消除這樣的浪費了世囊？

三别瞭、反饋原則

  --為什么需要建立及時的反饋機制，因為我們不想等到發(fā)生損失的時候才回過頭來檢查問題株憾，在軟件研發(fā)過程中蝙寨，我們需要在開發(fā)測試過程中發(fā)現(xiàn)bug，生產(chǎn)發(fā)現(xiàn)嗤瞎，那就是生產(chǎn)事故了墙歪。此外，流動原則中需要發(fā)現(xiàn)并定位阻塞和浪費猫胁，那么完善的度量反饋箱亿，可以以數(shù)據(jù)的形式告訴我們浪費與阻塞存在于哪個環(huán)節(jié)。理想狀況下弃秆，對于軟件研發(fā)生命周期中的每一個環(huán)節(jié)我們都應該建立足夠的信息反饋，來可視化數(shù)據(jù)展示可能存在的問題髓帽，當出現(xiàn)異常數(shù)據(jù)的時候及時報警菠赚，很簡單的一個例子，便是紅燈修復時長郑藏，過長的紅燈修復時長衡查，表明了我們擱置一個問題的時間，這是不合理的必盖。
  --群策群力的解決問題拌牲，在復雜系統(tǒng)中，可能沒有一個人了解系統(tǒng)的全貌歌粥，明顯的例子塌忽，如豐田制造里面的“安燈繩”，一旦生產(chǎn)線出現(xiàn)了問題失驶，拉下“安燈繩”土居，所有人停止工作來解決問題℃姨剑看起來這很浪費大家的時間擦耀，但從長遠來看這是有所幫助的，首先解決問題的速度會變快涩堤，那造成的等待會減少眷蜓，其次解決問題的過程也是組織級經(jīng)驗傳播與沉淀的過程，最后盡可能在早期扼殺掉問題胎围，這一點人員時間的支出吁系，收益會很高
--從源頭保證質(zhì)量德召，我們每個人需要在自己所處的控制域里保證質(zhì)量，避免自己交付的內(nèi)容存在問題垮抗，這就是敏捷中為什么強調(diào)DoD的原因氏捞，明確的準入準出的定義，保證了質(zhì)量的內(nèi)建冒版，如果此項工作沒有達到DoD的標準液茎，則不能進行流轉(zhuǎn)，那么實際中我們通過驗收標準來實施評判便是一個具體的實踐辞嗡，保證了價值流的順暢捆等。“做決策的地方一般遠離執(zhí)行工作的地方”這句話在實際工作中不斷得到驗證续室，是一種官僚與責任推卸的體現(xiàn)栋烤。
--為下游工作中心而優(yōu)化，對于下游的同理心挺狰，是責任心的一部分明郭，如果主動思考如何讓下游的對接人更好的開展工作，將提升全局的效率與組織級的凝聚力丰泊，這是devops中建立信任組織的重要內(nèi)容薯定。書中的例子是我們應該關(guān)注架構(gòu)、性能瞳购、部署方式等等的優(yōu)化话侄，便是對于內(nèi)部下游人員的同理心

四、持續(xù)學習與實驗原則
-- 建立學習型組織和安全文化意味著blame free学赛，總是指責是官僚的做法年堆，是滋生逃避與推諉的做法，我們需要解決問題盏浇，為后續(xù)的操作沉淀經(jīng)驗变丧，關(guān)注如何設計系統(tǒng)避免事故發(fā)生，指責會帶來恐懼缠捌，恐懼會帶來推諉锄贷。雖然實際工作中踐行這一條很難，我們一直強調(diào)要把責任抓實曼月，但我們應該借鑒這種思維來管理我們的組織
--將日常工作的改進制度化谊却，很典型的例子就是我們應該關(guān)注sonar掃描結(jié)果，比如技術(shù)債哑芹，也許一時半會并不會影響我們生產(chǎn)上的運行炎辨，但是持續(xù)下去只會造成問題的推積和低質(zhì)量代碼的繁衍(因為很多時候我們會參考別人寫的代碼)，但出現(xiàn)問題的時候聪姿，修復成本會變得很高碴萧，這也是為什么一直強調(diào)“重構(gòu)”的原因乙嘀，重構(gòu)帶來更好的系統(tǒng)架構(gòu)，為我們實施敏捷devops打下基礎(chǔ)破喻，很多人都忽視了虎谢，系統(tǒng)架構(gòu)本身對于敏捷和devops的重要影響，如高耦合性造成沒辦法小批量的持續(xù)交付曹质，老舊的框架沒辦法完成自動化測試與單元測試
--把局部發(fā)現(xiàn)轉(zhuǎn)化為全局優(yōu)化婴噩，書中舉了一個很好的例子，“美國海軍核動力推進計劃”羽德，很重要的一條是無論出現(xiàn)的問題細微或者大小几莽，都必須沉淀為手冊經(jīng)驗，這樣當發(fā)生任何問題的時候宅静，我們都可以快速依據(jù)過往的經(jīng)驗進行解決章蚣，且這樣的經(jīng)驗可以規(guī)模化的推廣在整個組織中(可以理解為一個wiki或者指南)
--在日常工作中注入彈性模式姨夹，這里的例子便是混沌工程纤垂，我們需要人為刻意的去制造問題來檢驗我們系統(tǒng)應對問題的能力，增強我們系統(tǒng)的抗脆弱性磷账。而不是被動的等待問題發(fā)生來救火
--領(lǐng)導層強化學習文化洒忧，領(lǐng)導會在更高的層面設計和執(zhí)行流程，其他人在這方面沒有足夠的洞察力和權(quán)力够颠，但是領(lǐng)導沒辦法親自去實施，所以領(lǐng)導應該創(chuàng)造條件給員工去發(fā)現(xiàn)問題榄鉴，引導他們在日常工作中主動的發(fā)現(xiàn)問題履磨，提出問題，然后一起思考解決方案庆尘，兩種角色是互補的剃诅，這樣才能建立一個真正的學習型組織，推動我們在日常工作中改進驶忌，從而建立一個安全有活力的組織

五矛辕、選擇合適的價值流作為切入點
--綠地項目和棕地項目的選擇，對于大型企業(yè)來說付魔，建議還是從綠地項目開始聊品，因為棕地項目會存在大量的技術(shù)債不說，老舊的充滿耦合的系統(tǒng)架構(gòu)几苍，根本沒辦法實施小批量的交付翻屈，與其它系統(tǒng)間的依賴導致了上線的相互等待，缺乏特性妻坝、功能開關(guān)導致上線的反復調(diào)整伸眶，所以從綠地項目開始更加合理
--記錄型系統(tǒng)和交互型系統(tǒng)惊窖，雖然理論上說我們應該兼顧兩者，任何一種系統(tǒng)都應該持續(xù)改進厘贼，提升交付質(zhì)量與效率界酒，通過devops的實施來增強自動化能力、質(zhì)量內(nèi)建能力嘴秸、持續(xù)交付能力毁欣，但實際中我們對于一些較為老舊的系統(tǒng)，還是應該從局部的一些小的工程實踐開始(甚至最后停留在這些小的工程實踐)赁遗，實施devops或者敏捷的一大基本訴求就是快速交付應變市場署辉，但是始終有一些系統(tǒng)不存在這樣的訴求，所以這些系統(tǒng)我們可以從流水線岩四、質(zhì)量掃描等小的工程實踐實施
--從最樂于創(chuàng)新的團隊開始哭尝，變革、轉(zhuǎn)型都是需要勇氣與魄力的剖煌，并且看起來是一個充滿風險的動作材鹦，但真的具備創(chuàng)新、創(chuàng)業(yè)意識的團隊才能最快的意識到其中的價值耕姊。比如銀行內(nèi)部的一些年輕的團隊桶唐。
--擴大DevOps的范圍，積極的宣傳項目組轉(zhuǎn)型以后的成效茉兰，用實打?qū)嵉臄?shù)據(jù)尤泽，或者具體的案例來展示更具有說服力，從而形成規(guī)模效應规脸。你或許可以取得小規(guī)模的成功坯约，但推動整個組織的轉(zhuǎn)型比想象中難多了，我們從小而精的團隊開始實施莫鸭，但是大規(guī)模開展以后闹丐，你會發(fā)現(xiàn)經(jīng)驗并不是總能復用，資源有限的情況下被因，先做什么需要站在企業(yè)的高度來思考這個問題

六卿拴、理解、可視化和運用價值流
--在一個項目決定實施敏捷或者devopss轉(zhuǎn)型以后梨与，第一步應該讓所有可能參與的人堕花，意識到價值在哪里，而流動會經(jīng)過哪些人做哪些事蛋欣，那么我們使用價值流映射這個方法論來實施整個過程,整個過程需要我們圍繞一個產(chǎn)品(產(chǎn)品思維而不是項目思維)交付的全流程開展航徙，所有相關(guān)人員必須投入熱情同時參與，因為沒有一個人能夠知道為客戶創(chuàng)造價值所要做的每一項工作。所有參與的人員到踏，應該是在自己所在崗位有權(quán)限作出改變的杠袱，不然只會浪費時間，繪制整個價值流圖不是為了確定每一個細節(jié)窝稿，而是識別價值增益點和阻礙點楣富。那么價值流圖畫出來以后，我們應該重點關(guān)注伴榔，哪些工作存在頻繁返工纹蝴、等待(明明不上線但是又要提測)、浪費(同一個工作反復做踪少，比如配置某個環(huán)境的參數(shù))塘安，我們明確價值流中的每個模塊的前置時間和處理時間以及%C/A(percentage of complete/accurate，this is the percentage of information-based work that is complete and accurate the first time and requires no rework by downstream process),一旦確定了想要改變的指標援奢，那么制定任務將變得清晰可見了

--------------------------------------------------------------持續(xù)更新中