精益+敏捷，兩大管理思路讓研發效能「飛」起來｜直播回顧

8月10日，ONES 研發管理大師課第二期課程正式開課啦。本期邀請的大咖講師是 ONES 研發效能改進諮詢顧問董曉紅老師，分享主題為《精益敏捷組合管理提升研發效能》。通過精益和敏捷管理思路，探討如何讓有價值的需求順暢、高質量地流動起來，從而提升企業研發效能。

以下是曉紅老師分享的核心內容。

我先從四個視角解讀一下研發效能提升的必要性。

站在組織的視角上，組織發展規模化以及技術驅動商業差異化，已經難以應對市場的快速變化；站在組織內部的視角上，競爭日趨激烈，「穀倉效應」越發突出，區域性優化但是無法全域性優化，破局「大船難掉頭」的尷尬勢在必行；站在行業技術視角上，軟體研發的各個環節已經全面數字化。為研發效能的資料收集和度量做好了準備；最後，站在外部資源視角上，在經濟存量的大背景下，再加上今年新冠疫情的影響，業務發展不能僅靠燒錢、人海戰術。隨著產品利潤的下降，企業需要降本增效，提升效能。這是我理解的提升研發效能的四個必要性。

講到精益，它的生產系統有三個階段。

第一個階段是弗雷德裡克·溫斯洛·泰勒提出的科學管理方式階段，就是有流程制度的標準作業，大幅提升了作業的效率；第二階段是大規模生產方式，代表人物是亨利·福特，他創造了大眾階層也能買得起的 T 型汽車，在泰勒的科學管理方式的基礎上，提出了更加規範化、標準化的大規模生產方式，讓汽車走進千家萬戶；第三階段是豐田生產方式，代表人物是大野耐一。據說，當時大野耐一去美國福特的流水線參觀時，發現很多浪費現象，他覺得與日本的節約理念很不匹配，他想出來一種精益生產方式——小規模、小批量「拉動式」的生產系統。

此外，精益是怎麼在 IT 軟體應用中演進的呢？1996年，詹姆斯·沃麥克和丹尼爾·瓊斯釋出了《精益思想》，精益生產方式由經驗變成理論，使精益在其他領域進一步擴充套件；2003年，Mary 和 Tom 在《敏捷軟體開發工具——精益開發方法》把精益原則對映到軟體開發中；2004年，大衛·安德森在微軟公司可持續工程團隊進行精益化管理變革，通過5個季度把微軟績效排名最差的團隊變為績效最好團隊；2010年，大衛·安德森釋出《看板方法：科技企業漸進變革成功之道》，看板方法脫胎於豐田生產方式和高德拉特的約束理論(TOC)，是精益方法的進一步延伸；2014年，在國內，華為最先開始推行精益看板方法，招商銀行緊隨其後。

接下來，我們看看精益管理的五大原則，也是精益實施的五個步驟。

第一步，定義價值，我們要站在使用者的視角去定義價值。舉個例子，軟體開發中我們提一個需求，要站在使用者的角度去思考是不是他們想要的，而不是我們自己臆想出來的，這就是定義價值。

第二步，識別價值流。我們以終為始，定義端到端過程中的一切活動。以軟體開發為例，從需求的提出到評審、研發、上線整個過程就叫端到端的活動，這樣才能有全域性的視野。有了全域性視野，我們才能看到整個過程中有沒有多餘的步驟、有沒有阻塞、有沒有瓶頸等。

第三步，增加流動。有價值流了，我們要讓它像河流一樣通暢流動起來。這一步有個比較重要的點，就是要從聚焦資源到聚焦價值流動。意思就是，團隊要從一開始關注「人忙不忙」，逐步轉變到關心「價值是不是在流動」，因為人在忙不一定能帶來價值。這一點是很關鍵一點的，是要從思維上改變的。

第四步，需求拉動。降低庫存，我們有訂單後再生產，用下游拉動上游。

第五步，「完美」，也就是不滿足現狀，持續地去改進。在軟體行業，「完美」最重要的是「質量內建」，意思就是不要把有問題的環節傳到下一個環節。

這就是精益生產的五大原則，它最高的目標還是要降低成本、改善質量，縮短週期。

很多人其實對看板是有一種誤解的，只把它看成「視覺化的板子」。所以，理解什麼是「生產製造中的看板」十分重要，它可以幫助我們理解本質，消除誤解。看板一詞來自於日文，本義是訊號卡片，用於精益流程和及時的庫存補充計劃，幫助公司提高產量並減少總體庫存。

這節課，我們主要講解精益看板方法。大衛·安德森最早在軟體開發中借鑑和應用看板實踐，並總結為完整的「看板方法體系」，包含以下三個核心內容：

第一，將流程視覺化。把工作拆分成小塊，一張卡片寫一件任務，再把卡片放到牆上。這可以理解為，我們要做一個軟體，把需求寫到一張卡片上，然後再把這個卡片放到看板牆上；看板牆劃分為多列，每一列都有狀態，顯示每件任務在流程中處於什麼位置。

第二，根據能力限制在製品。明確限制流程中每個狀態上最多同時進行的任務數。每個團隊的能力、基礎設施是不一樣的，需要團隊根據自己的情況去探索。它有兩個目的，一方面，通過減少並行任務數量，加快價值流動，從而縮短週期時間；另一方面，它有暴露問題的張力，有助於暴露瓶頸和問題，激發團隊協作解決問題。

第三，度量生產週期。這有助於對流程進行調優，儘可能縮短生產週期，並使其可預測。這個步驟可以幫助團隊判斷過程中有沒有不必要的步驟、有沒有浪費、有沒有可能縮短生產週期等等。

明確好核心內容以後，我們來看看精益看板的五大實踐。

第一個實踐，視覺化工作流程。它有三個要點：可視的是使用者價值、可視的是使用者價值端到端的流動過程、問題和瓶頸也要視覺化顯示出來。

第二個實踐，控制在製品數量。每個環節內在製品數量小於設定的數量時，才可以從上一環節拉動，否則不允許拉入新工作。我們要聚焦已開始的工作，聚焦有問題的地方。

第三個實踐，顯示化定義規則。這裡指的是看板中從一列移入另一列的規則。另外，其他規則也要定義出來，比如：需求優先順序、緊急需求等定義也要顯示化出來，以便團隊達成共識，按照規則來執行。

第四個實踐，管理工作項流動。這裡有兩個要點，一是就緒佇列的填充，就緒佇列是看板價值流的源頭，只有管理好源頭，才能重視價值的順暢流動和質量。二是每日站會，站會也是管理價值流動過程的活動，重點會關注價值流動過程的問題和阻塞。

第五個實踐，建立反饋，持續改進。它需要關注流動是否順暢的反饋以及關注質量的反饋。

說完精益的起源，我們再來說說敏捷的起源。2001年，17位軟體開發者帶著他們輕量級框架「Scrum、XP、FDD、DSDM」，齊聚在美國的猶他州的雪鳥滑雪場。他們把框架裡面的共性特徵抽象出來，梳理形成了敏捷的十二原則，並寫下了敏捷軟體開發宣言。

同時，Scrum 的歷史可以追溯到1986年。《哈佛商業評論》的一篇文章《新型產品開發策略》描述了一種快速靈活的開發策略，以滿足快速變更的產品需求。該文章第一次將 Scrum 與產品開發進行了關聯。

我們再詳細講解一下 Scrum，它的目標是通過一種自組織跨職能的迭代小團隊去交付價值。支撐這個目標是敏捷的三大支柱——透明、檢視、適應。Scrum 框架還有很重要的「3355」原則——3個角色、3個工件、5個價值觀、5個事件：

• 3個角色：產品負責人、團隊成員、敏捷教練
• 3個工件：產品待辦列表、迭代待辦列表、產品增量
• 5個價值觀：承諾、勇氣、專注、開放、尊重
• 5個事件：迭代、迭代計劃會、每日站會、迭代演示會、迭代回顧會

接下來，我們看看 Scrum 與 Kanban 的對比。這個對比不是評價孰優孰劣，而是以此來加深對兩種方法的認識，並在實踐中相互借鑑。它們的相似性有這幾部分：

• 都是既精益又敏捷
• 都限制了 WIP
• 都以透明的方式驅動過程改進
• 都關注於盡早交付，頻繁交付可釋出的軟體
• 根基都是自組織團隊

同時，Scrum 與 Kanban 有6項差異點，我們從變更匯入、節奏、控制在製品、事件、角色、預設度量這6個維度進行了對比，詳情請看下面這張對比圖：

最後，和大家分享一個 ONES 給客戶做的精益敏捷組合管理的思路。如下圖，我們可以看到，能效、流程、方法工具是從「事」的角度出發，組織是從「人」的角度出發。研發效能的提升，無論是看板實踐還是敏捷 Scrum 實踐，更多解決的是如何讓有價值的需求順暢、高質量地流動。所以，我們要想提升效能，不能僅靠部分的管理實踐，還需要一些工程實踐，比如要持續整合、持續部署、持續監控、自動化測試等等，形成一個閉環作業。

從「事」的角度，我們需要梳理流程規範，要確保組織上下文形成一系列的共識，包括統一的術語、業務以及研發資料流的串聯、度量單位的一致性等等。有了流程規範以後，我們就通過工具去固化流程規範。在這過程中，可以兼顧一些度量埋點的設計，把我們想要的一些指標設計進去，這樣資料就自然而然地落到了系統中。最後，通過度量 UI 展現層，展示出一些資料供各個領域，持續改進、持續做決策。

從「事」的角度提升效能，是有一定成效的，但更重要的還是要從「人」的角度出發。我覺得，需要有一個變革的引領者，比如說是 Scrum Master 或者過程改進專家、效能專家等等。這些人需要有：

• 引導的技能，如：能夠引導團隊有效地開會，引導團隊實踐落地。
• 教練的技能，通過這種啟發式提問，讓團隊成員找到自己的目標、實現目標的驅動力、激發團隊整體的潛能。
• 當然，這個變革者他自身必須有自驅力，他能影響團隊，幫助團隊成員成功，幫助團隊成員光彩奪目；同時，這個人要養成成長型思維，允許團隊成員犯錯，這種文化也很重要。

以上是我今天分享的主要內容，希望能給大家啟發，感謝聆聽。

-Q & A-

Question 1：

網友：軟體敏捷開發模式下，市場需求會拆分成多個產品需求，開發繼續拆分產品需求到更小顆粒度去編碼。因此，開發團隊經常用產品需求來衡量交付，每年研發效率都在提升。但市場側卻認為從市場需求角度看，效率並沒有提升。如何讓雙方的效率提升達成一致的看法呢？

曉紅老師：研發側有自己的持續改進度量指標我覺得沒問題，通過統計資料看到研發側效率的提升，加強了團隊持續改進提升的信心。關於「市場側不認可」，需要了解市場部不認可的原因，如果市場部覺得在業務上並沒有感知到研發效率的提升，可以定義一些業務指標來牽引研發更好地支撐業務。一般來說，市場部的指標要根據市場部的戰略、目標來制定。

Question 2：

網友：在企業管理場景中如何推動敏捷在企業中落地呢？

曉紅老師：我覺得有以下幾點。第一點，無論你推動敏捷或者 DevOps 變革，我建議要有一個目標，相當於內驅力：我為什麼要做這個敏捷轉型，我要解決哪些痛點等等；第二點，就像剛才說的，最好有一個變革的引領者，領導者可以是 Scrum Master，他要輔導團隊怎麼去做敏捷，在企業中如何落地，讓大家理解這個背後的原則等等；第三點，一個好的工具是非常必要的，它可以幫助你加速整個敏捷的落地。

Question 3：

網友：我們公司踐行敏捷實踐也有一段時間了，但是團隊中有很多人不願意開敏捷回顧會議，怎麼辦？

曉紅老師：我覺得可能要分以下幾點。第一，和團隊成員去聊一下為什麼不願意參加回顧會，是不是覺得沒有價值？如果是沒有價值，那就需要檢視一下回顧會是不是基於目標開的，需要有明確的目標；第二點可能也要去跟團隊成員去聊一下，他們期待的敏捷回顧會是什麼樣的，他心中完美的敏捷回顧會是什麼樣？大家可以集思廣益。

Question 4：

網友：我們是製造業，正在敏捷轉型期，在敏捷實踐過程中，員工配合度不高怎麼辦？

曉紅老師：我覺得還是要看看他們不配合的原因，或者間接地去檢視他們是不是沒有理解敏捷的實質。其次，還是看看他有沒有什麼好的工具或者方法，可以更好地幫助大家達成敏捷轉型的目標。

Question 5：

網友：Scrum 核心要點「3355」是必須的，還是說可以根據企業的自身情況做調整呢？

曉紅老師：我想還是要根據企業不同的情景而定。比如說，公司剛進行敏型轉型的時候，還是需要儘量遵守「3355」；當達到一定的敏捷成熟度了，也許都可以不需要 Scrum Master 這個角色。我之前看到過好多客戶的團隊，合併兩個迭代進行回顧會，卻可以很好地解決問題。所以，不同的階段，企業可以根據自身情況採用不同的方法。

ONES 研發管理大師課第一季課程還在繼續，「大型軟體團隊高效協作的方法與實踐」「研發效能度量的行業趨勢及五項精進」等課程即將上線。