本文內容節選自第六屆全球軟件案例研究峯會，時任華爲敏捷精益專家陳軍老師分享的《華爲百人團隊精益看板演進變革之路》實錄，重點分享：精益看板的創建，團隊革新。（PPT+文稿）。網絡
陳軍老師是華爲精益敏捷專家；現負責精益看板在整個華爲的落地實施，輔導的各產品線團隊規模均上百人，團隊效率提高明顯。 原騰訊高級項目經理；PMP；CSM；EXIN LEAN IT中國首位認證講師；NLP教練；國家三級心理諮詢師。架構
編者按：2017年11月9-12日，第六屆全球軟件案例研究峯會在北京國家會議中心盛大開幕，現場解讀2017年「壹佰案例榜單」。時任華爲敏捷精益專家陳軍老師分享的《華爲百人團隊精益看板演進變革之路》實錄。工具
【內容簡介】在面對市場需求的激增和快速的變化時，研發團隊要如何靈活應對並快速響應，如何在有限的人力下提高研發效率。本文將介紹華爲百人團隊精益看板演進變革的歷程，從創建看板到運做看板，取得小勝利，再到團隊遇到困局，停滯不前甚至倒退，面對困局同團隊一塊兒再審視改進，從新走上了正確的道路。測試
1優化
華爲研發面臨的挑戰編碼
客戶分類：3d
傳統運營商客戶：運營商受到互聯網企業的衝擊，要求版本更新得更快。blog
企業客戶：以華爲的DCN數據網絡中心爲例，承載了大量的數據業務，企業對此格外重視，版本更新迭代較之以往提速許多。進程
終端客戶：我的客戶需求變化頻繁，甚至是天天都在改變。圖片
華爲內部：團隊龐大，產品、業務複雜。一個產品的解決方案有時會牽扯到上千人致使效率低下。
02
爲何要選擇精益看板
1.對研發衝擊小：精益看板不會改變組織架構、人員角色，但能夠將總體格式化、規範化。
2.適應性強：看板是「元流程」，它能夠和任何流程相匹配，無需擔憂要怎麼去融入看板。
3.可提高吞吐量：研發的吞吐量與車道流量十分類似，其相關定義以下圖：
在研發過程當中，不免會存在吞吐量很是小的環節，咱們能夠稱其爲研發中的瓶頸，瓶頸發生的地方稱之爲阻塞點。那麼如何解決呢？關鍵在於保證WIP必定狀況下縮短Leadtime，這能夠從縮短Worktime和waittime兩個方面着手。例如作自動化測試，能夠大大縮短編譯時間，提升總體「通道的流速」。
4.看板是一種持續改進的機制。
仔細觀察上圖，能夠看到開發已經沒有正在進行中的事項，但還有許多待辦事項，這是因爲測試環節處存在積壓事項。但此時咱們仍要進行深刻的分析其到底是不是瓶頸再作定奪。
在圖中，異常卡片所表明的事項是環節中的阻塞點。異常卡片這一設置是看板上的可視化元素，可讓團隊持續改進，把問題充分暴露出來。
03
百人團隊實施案例分享
下圖是在引入一個新方法時，絕大多數團隊會經歷的歷程。下面咱們以引入看板爲例：
出於產品的訴求，引入了看板機制，以後會取得必定的小勝利，但在使用過程當中也逐漸出現新的問題，只有解決新問題後團隊才能走上正確道路。
但大多數團隊會因爲沒有正視問題而迷失在困局內，這不是引入模式的問題，而是團隊使用方法出現了問題。
業務痛點
1.市場增長，需求增大：外部市場的增長，同時團隊面臨着組織的調整，團隊的人數減小了，這種狀況下更急需提高團隊的產能。
2.需求變化快，須要快速響應：在研發沒法知足市場時，須要進行一些變革，這也是引入精益看板的緣由。但也須要考量項目團隊是否與精益看板相匹配：第一業務訴求與精益看板是否相匹配；第二團隊積極性是否高昂。
看板的引入
在引入看板時，存在兩組實踐。
第一組實踐是創建看板，另外一組爲運做看板。並把八大實踐分爲兩組，創建可視化過程。
價值流映射
將研發過程可視化，映射到看板上。
按照華爲團隊需求結構可分爲三層：IR、SR、AR。
第一層IR是初始來自客戶的需求，隨後分解到第二層的系統需求，最後分配到團隊級的AR。咱們根據上述特色，創建了產品級看板和團隊級看板。需求從上往下分解，狀態從下向上卷積。
顯示化流轉規則
卡片的每一次向下流動都須要一個規則，這些規則是共同定製的質量條件，目的是爲了保證每一步的進程都是良好可運行的。
但規則不是死的，是隨着環境、研發的變化而變化，是能夠被從新商議更改的。惟一的條件是，規則制定後必須嚴格執行。
規則的制定來源於自働化。衆所周知，自働化是豐田的重要原則之一。豐田最先作自動織布機時，把傳統的手動織布機改成自動織布機，可是問題來了，當有線斷掉的時候織布機不會中止，這樣出來的產品時殘次品，後來通過改良在織布機出現故障時由人工 來檢查重啓，檢查經過後纔會繼續運做。這也是內建質量的過程。
限制在製品
這是看板中最難實施的一個步驟。由於爲保證投入的精力，每人同時只能幹兩件事情。
儘管在以往，一我的同時作多件事情被認爲也是無傷大雅的。但這是因爲需求流動沒法被直觀看到，最終極易致使需求流轉不動，一直停留在開發進程中。這時候咱們須要轉換本身的視角，更多關注流動效應。
由於研發的交付速度須要很快，因此研發人員的流動效率與資源效率理應很高。但實際上，效率是沒法都達到百分百的。因此咱們提倡提升流動效率，減小浪費，天然能夠提升資源效率。
看板正是爲咱們提供了這樣一個視角，把不可見的需求轉化到可視化的看板上，把需求的變更轉化爲卡片的流動。
看板運做
運做看板首先有一個需求的填充，這個過程在華爲被稱爲二次填充。從大的流程看，二次填充仍然屬於IPD，但能夠限制大的IPD，更好地管理風險。
第二個是經過看板站會管理流動效率。站會與以往不太同樣，再也不關注要作什麼，遇到什麼問題，而是關注卡片和價值的流動。
看板從右向左看，成員更多的關注如何讓右邊的卡片儘快向下流動。在這個過程當中儘快解決可能存在的阻塞、瓶頸，其最終目的也是爲了讓卡片向下流通。
拉動式開發
拉動式開發是團隊造成自組織很是重要的一點。這也意味着，若是你的團隊想要作到拉動式開發必須是自組織的。在創建拉動式開發時，必需要關注上下游的每一步質量究竟如何，只有下游能夠流動，上游才能被拉下來。
組織者必須具備全局觀，善於發現問題。
創建規則
這些規則會定製的十分詳細，包括團隊運做看板時的操做規則。例如，看板站會以前，團隊人員會把卡片拖動到正確位置，標記異常狀況。
示例
觀察下面看板圖片：
在運做過程當中，咱們發如今團隊級看板的AR一級，SDV測試內沒有任何卡片，反而都堆積在Ready For SDV。看起來SDV是一個瓶頸，但實際上這是由於自身流程——批量式轉乘形成的。
回顧改進：從下示意圖中，能夠看到批量式交互的累積流程是呈現階梯狀的，散點圖是集中於某一時間交付。
在回顧改進時，咱們制定了改進測試，每週進行小批量的SDV測試。
在有了這樣的小勝利後，團隊的趨勢從上圖變成了下圖。團隊從原來的的批量交付，修改大量缺陷。變成了當前的每週發現問題，每週進行修改。
困局與破局
在這個版本結束後，看板使用率就大大下降了。和其餘團隊溝通後，發現是由於團隊太忙根本沒有時間顧慮看板。
破局一：創建看板的分析請求分配產能
下圖是Muri、Mura、Muda浪費示意圖。
特別注意Muri、Mura直接致使Muda。Muri系統超載致使任務的切換，任務切換自己就產生不少的浪費。Mura系統的波動性會打亂團隊的節奏，例如忽然來一波需求致使系統過載進而產生浪費。
這個團隊Mura狀況比較嚴重，除了自己的特性包需求意外，還會有一些須要快速響應的小需求，致使團隊疲於應付。解決方法是把團隊人員分爲兩組，一組人作運營快速發佈版本，小需求出現後，以固定的節奏快速發佈。大的需求用火車版本。
美國海軍陸戰隊有句話「慢就是穩，穩就是快」（slow is smooth，smooth is fast）。這和豐田的「均衡化」原則的原理類似，需求進入管道時必定是穩定的，若是不穩定會致使優化大打折扣。
破局二：找回需求
AR只是任務，不能稱做需求。測試是檢測SR，因此咱們轉換視角關注到需求上面，採用FO，拉通端到端。
破局三：減少批量
下圖的瀑布中，總計44天，但編碼只佔用10天，後面20天是沒有任何編碼的。在這樣的情形下，作的需求會較少。
解決措施：按周填充，減小SDV批量，減少SIT批量，加速價值流動，質量保證前移，減小fix時間段，增長編碼實踐，提高吞吐量。
04
Q&A
Q：如何能真正作到減員增效？
A：看板。由於在業界裏面，比較好流動效率纔剛20%到40%，因此若是你的流動效率能達到40%，其實你有60%仍是浪費的。因此如何不斷的提高流動效率，讓卡片流動愈來愈快帶動吞吐量提升。只有不斷的把水分給擠掉，這就是減員增效。
Q：華爲是怎麼突破精益看板中的坑呢？
A：最大的坑是思惟的變化，對於某些看板上展現出的問題不覺得然。咱們團隊認爲要持續改進。持續改進其實已是改善的結果。
改善要有自我批判的精神，可以不知足現狀，可以有勇氣去改進，而後纔會用到相關的工具去作持續改進。在有了這種思惟後，纔會使用看板。因此首先要改善，其次纔是改進。
以上內容來自陳軍老師的分享。