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

語言: CN / TW / HK

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