圖解精益敏捷的邏輯與實證:設計您自己的工作方式

NO IMAGE

640?wx_fmt=gif&wxfrom=5&wx_lazy=1

本文來自作者 glenwang 在 GitChat 上分享 「圖解精益敏捷的邏輯與實證:設計您自己的工作方式」,「閱讀原文」檢視交流實錄。

「文末高能」

編輯 | 哈比

摘要回放

精益敏捷的書籍已如汗牛充棟,但又沒有給人一個明確的產生畫面感的紮實理解。本文對精益敏捷的基本定義如下:

  • 一種工作方式;

  • 跟人和組織相關;

  • 其目的是達成組織的目標;

  • 以敏捷四價值觀和精益五原則為核心基礎。

本文基於作者十餘年管理和教練經驗,總結軟體開發管理中各個敏捷實踐的邏輯:

  • 發生作用的原因;

  • 行得通的條件;

  • 達到的效果。

業務有架構、技術有架構、工作方式也有架構。文章脈絡大致參照 PMBOK 的組織方式:五大過程組(專案啟動、規劃、執行、監控、收尾)和十大知識領域(整合、範圍、進度、成本、質量、資源、溝通、風險、採購、干係人),並按照精益和敏捷思想有所修正。

分享的目的是幫助您思考精益敏捷的邏輯以及設計您自己的工作方式(Way of Working)。

// 手繪圖 by @ 虎頭錘

精益敏捷的八大邏輯

兩個根本元素

產品、技術與工作方式

當談到產品時,人們心目中會浮現出一副景象:生活中的衣食住行,或娛樂運動旅遊教育所需的各種東西,即人們購買、使用和消費,並能滿足人們某種需要的任何東西。

當談到技術時:人們頭腦中也會浮現出一副景象:為了生產出產品,具有專業技能的人在生產產品的過程中所進行的專業活動。

有了對產品的需求,和有了技術,是否就能進行卓有成效的生產活動,和生產出既能滿足市場需要,也能幫助企業盈利的產品呢?答案是否定的。

福特汽車是如何崛起的?豐田汽車又是如何後來居上的?這涉及到工作方式和管理問題。

流的歷史

工作方式的概念包含的內容很多。下圖通過工作方式當中的一個小概念 “流”,介紹一下流的歷史,對工作方式做個初步體會。

640?wx_fmt=jpeg

  • 1104 年建立的威尼斯兵工廠,是為威尼斯海軍建造軍艦的地方。威尼斯人早年經過長時間的努力,建立了標準化的設計以及可替換的零件,以致在艦船廠中狹窄的水道里,一年能製造出數以百計的戰艦。工人們先建造船身,然後再 “漂” 流到下一站,去裝配不同的部件。1574 年,法國國王亨利三世被邀請去參觀該工廠開發出的先進 連續流 製造技術,從開始組裝船身到完成,只需要不到一小時的時間。

  • 1798 年美國正籠罩在可能要與法國開戰的陰影之下,惠特尼接受美國政府的委託,在 1800 年前為美軍供應 10000 至 15000 支步槍。他按照槍支零件的尺寸設計出一套專門器械和流程,讓一般工人通過使用它們分工生產不同的零件。用這種工藝流程生產出來的零件尺寸及公差均一,任何零件皆能適用於任意一把同型號的步槍,只要將它們組裝起來便可成為一支完整的步槍。這就是 可互換零件 。而在當時流行的工藝是每把槍由頭到尾皆由一位工匠打造,同型號的每一把槍的零件都無法互換。

  • 豐田集團的創始人 Sakichi Toyoda 豐田佐吉(一生研發出 84 項專利,被日本人譽為 “發明王”),於 20 世紀早期,通過在自動織布機上安裝能夠在任何紡線斷掉的時候自動停機的裝置,發明了 Jidoka( 自動化 )這個概念。這不僅改善了質量,並且使得工人能夠解放出來,去多做一些增值的工作,而不只是為了避免守在機器旁。最終這個概念應用到了每臺機器,每條生產線,和豐田公司的每個操作之中。

  • 20 世紀初,汽車仍然是富人們才能消費得起的奢侈品,亨利·福特在 1903 年創辦福特汽車公司後,勵志要打造一輛普通大眾都買得起的平民車。當時美國銷售的汽車普遍售價在 4700 美元左右,相當於一名普通人六年的總收入,而福特 T 型車售價僅為 850 美元。為了讓福特 T 型車更加深入人心,亨利·福特決定改進生產方式以求大幅降低了福特 T 型車的成本,使其售價進一步降低。亨利·福特偶然間在一份肉類加工廠報告中獲得靈感,為了滿足消費者對 T 型車強烈的需求,他決定採用 流水線 的方式生產汽車。1913 年 12 月 1 日,亨利·福特開發出世界上第一條汽車組裝生產線並投入生產。每個工人固定在一個工位組裝車輛的某一個零件,原先一輛汽車裝配時間需要 700 多個小時,T 型車採用流水線作業僅需 12.5 小時。

  • 在 20 世紀 40 年代,戴明反覆強調質量控制的重要性,不斷進行質量管理的培訓,試圖把統計學運用於工業生產。據說,在這一階段美國政府和企業聽過戴明培訓課程的人數達三萬人。當時,戴明已經是世界公認的抽樣專家,不過,他的呼籲,在美國反應寥寥,沒有多少人對他的建議和課程真正有興趣。1950 年 7 月 10 日至 18 日,戴明受 JUSE 邀請在日本四大城市授課。他立足於一個基本信念,即高質量可以降低成本。戴明預言:“只要運用 統計過程控制 ,建立內在質量管理機制,五年後日本的產品就可以超過美國。” 果然,日本的產品質量總體水平在四年後(大約 1955 年)就超過了美國,到 20 世紀 70-80 年代,不僅在產品質量上,而且在經濟總量上,日本工業最終對美國工業造成了巨大的挑戰。

精益敏捷是當今工作方式的典型代表,上述工作方式中都包含著精益敏捷的要素。

兩個根本元素:邏輯和權力

而在精益敏捷工作方式的所有要素當中,有兩個根本元素:邏輯和權力。

  • 邏輯元素 :這是工作方式當中科學的一面。一種方法行得通或行不通,有其原因、條件和結果,這是邏輯和科學。精益敏捷工作方式是可設計的,而只有經過與實際情況相符的設計,才能行得通。

  • 權力元素 :這是工作方式當中與人有關的一面。在這裡,權力一詞基本等同於人。在一個組織當中,每個人有他的訴求、動機、地位、法定權力、思想、意志、知識、情感等或物質或精神的屬性,這些都是權力。在人的世界裡,單純用邏輯和科學方法是行不通的,因為人和權力是邏輯關係中最重要的要素。權力又大致有兩種:凝結在一個個個體身上的,和蘊藏在組織結構中的。這兩部分權力都要有很好的處理。

下述精益敏捷八大邏輯當中,第五和第六邏輯重點涵蓋權力元素,其他重點放在邏輯元素,但也涉及權力元素。

邏輯一:3C 環境

640?wx_fmt=jpeg

精益敏捷是如何發展起來的?我們又為什麼要實施精益敏捷?答案是我們生活在一個 3C 的環境當中:

  • 客戶(Customer):客戶的要求越來越高。客戶期望能以更低的價格,買到能滿足需要的產品,而且期望產品的交付週期越短越好。以手機為例,十年前市場上的手機品牌很少,升級換代很慢。而現在,手機的品種和升級換代的速度已經讓人眼花繚亂,更不要說各種 App 了。就社會和市場上的總產品來說,過去幾十年產生的產品數量或許超出了過去幾千年產生的產品數量。經濟進步、技術進步和消費者的覺醒是背後的推動力量。

  • 競爭對手(Competitor):行業壁壘越來越低,市場上的競爭對手越來越多。如果一家公司不能滿足客戶的期望,客戶還有更多選擇。公司發展不進則退,市場上總有人能以更低的價格做到同樣的事。對於手機產品,汽車產品,甚至火箭產品,我們發現越來越多的 “外行” 進入這些行業,而且還玩得風生水起。比如說馬斯克和貝索斯兩位就分別把火箭的發射成本降到了美國宇航局的十分之一以下。

  • 複雜性(Complexity):複雜性體現在兩方面,一方面是關於需求,另一方面是關於技術。這兩方面的進化和不確定性都在加劇。大家都知道晶片整合度的摩爾定律,晶片的整合度每 18 個月提升一倍。十年前電子產品還可以靠人工焊接,現在的晶片管腳已經是人拿著放大鏡都看不清,只能機器焊接。這是可見的物理複雜度的一個例子,更多是不可見的複雜度和不確定性。應對複雜性和不確定性的能力,是一家公司的重要核心競爭力。參閱:複雜性與敏捷 – Stacey 矩陣,Cynefin 框架,管理 3.0,敏捷宣言

在這樣一種 3C 的環境之下,精益敏捷的工作方式應運而生,成為企業的如虎之翼和強身健體的利器。

2018 年,全球市值最大的 5 家公司分別是:亞馬遜(Amazon)、蘋果(Apple)、Facebook、谷歌和微軟(Microsoft)。他們都採用了某種形式的精益敏捷,都在 3C 問題上有很好的處理。

並不是說精益敏捷是這些公司成功的唯一原因,但對其成功有重要作用。而要想運用精益敏捷取得成功,需要對精益敏捷的邏輯有清醒的認識,進而設計自己的工作方式,並確保落地。

世界潮流,滾滾向前。環境在變化,不以我們的主觀意志為轉移。只有順應潮流,並相應地調整自己的行為,一個企業才有可能基業長青。

邏輯二:三個核心

640?wx_fmt=jpeg

一家企業要能在 3C 環境中生存發展,需要處理好三個核心問題:

  • 把握使用者需求 :一種業務,只有真正把握住使用者需求,才有可能為供需雙方實現價值。根據相關統計,整個軟體行業的產品和功能有將近一半完全沒人用,這是因不能把握使用者需求而產生的最大的浪費。

  • 提升效率 :利潤 = 價格-成本。提升效率,即是降低成本,提升利潤。管理者的主要職責就是提升效率。而一家企業要在提升效率上有所作為,需要全體員工都能從提升效率中受益。

  • 應對複雜性 :在複雜性日益增長的時代,傳統的慢時代的計劃與控制的方法不再生效。應對複雜性,既需要從物的角度的科學邏輯方法,也需要從人的角度激勵個體的參與和提升組織的合作。

而對這三個核心問題的處理方法分別是:

  • 用 以使用者為中心 來把握需求:貼近使用者,瞭解他們真實的需求。

  • 用 消除浪費 來提升效率:消除浪費即是提升價值。大野耐一說:一個典型的過程中,包含著 95% 的浪費。改善是無止境的。

  • 用 探索式方法 來應對複雜性:採用多層次的 PDCA 迴圈,不斷檢視和適應。以團隊合作全員參與推動 PDCA 迴圈。

案例:北電網路破產的原因,在這三個核心問題上都有所體現。

北電的錯,看起來像是三大原因:一是技術路線選擇的失誤,二是對市場預估過於激進,三是內部缺乏有效的管理。

這正是所有技術公司都有可能面臨的風險,技術路線的錯誤,對市場預估的失誤,都有可能將一個技術公司拖入深淵。

其實北電的失誤不僅表現在對技術市場的 “鈍”,它對客戶的需求也有些 “鈍”。有人就認為,北電的失誤是一味追求技術的先進性,而不考慮客戶的需求。

以光纖為例,在網際網路泡沫破滅之後,北電急急地投入到新一代大容量的研發當中,認為市場復甦之後,運營商就會大規模升級網路。

但當時全球剛剛經過一輪光網路的升級,10G 網路鋪完成之後,網路上的業務還沒有應用起來。在業務沒有發展起來的情況下,運營商當然是不會感覺到網路的容量不夠,所以也不會急著擴容。

相反,運營商著急的是如何把網路用起來。所以,北電的 “前瞻性技術” 並不被運營商所接納。

北電並沒有理解客戶真正需要什麼。這些年,電信運營商也處於轉型期,一方面是網路的升級,另一方面,更為運營商所看重的是在現有承載能力上去挖掘業務潛力,而不是無度地投資。

近幾年,全球電信業的低迷是有目共睹,這個低迷主要是因為運營商不再瘋狂地投資在基礎建設方面。對於整個行業的低迷,一些供應商很早就預見到並積極根據客戶的需求轉型,將企業網、融合通訊、電信專業服務等新業務作為拓展領域,所以不會像北電那樣陷入如此的困境。

運營商是電信裝置廠商的衣食父母,北電對運營商轉型的心理抓得不準。所以,北電的幾次轉型並沒有緊緊地貼著自己的客戶去轉型,而更多地將命運交給未來可能存在市場的超前技術。客戶不會跟著北電走,北電就被無情地拋棄。

遠離了客戶的北電,越走越遠。

至此,我們已經介紹了作為精益敏捷產生背景的 3C 環境 ,進而推匯出精益敏捷所要處理的 三大核心問題 ,及對應的  三大核心解決思路 。

下述內容是對三大核心解決思路的展開,主要是以 Scrum 作為落腳點。

如果不採用 Scrum,也要有相應的方法保證三大核心解決方案的落地。明白了其中的邏輯之後,可以自己設計自己的工作方式。社群中有很多關於 Scrum 的爭論。

我的建議是,用什麼或不用什麼,要從目的和邏輯出發。只有明白了背後的邏輯,才能主動做出適合自己的選擇。

邏輯三:三個核心在 PO 的體現

640?wx_fmt=jpeg

我們先看一個問題:職責與職位。一種職責可以由多個職位承擔,一個職位也可以承擔多種職責。從單個職位出發來看,最優的職位設定是沒有意義的。

只有放在整個組織的系統中,以組織目標的完成程度來評價,才能看出整體職位設定的優劣。

職位與角色略有區別,敏捷當中更常用的的角色,更少強調地位,更多強調合作。要理解 PO(產品負責人)這個角色,可以從它的歷史來源來看。

產品經理的起源

自 1927 年,美國 P&G(寶潔)公司出現第一名產品經理(Product Manager)以來,產品管理(Product Management)制度逐漸在越來越多的行業得到應用和推廣,並且取得了廣泛的成功。

當時公司推出一種佳美牌(camay)香皂,但銷售業績較差。公司剛啟用的一名叫麥古利的年輕人在一次會議上提出:如果公司的銷售經理把精力同時集中於 camay 香皂和 lvory(寶潔的一種老牌香皂)的話,那麼 camay 的潛力就永遠得不到充分發掘。

同時,他提出了 “brand man”(品牌人) 的概念 , 一個品牌人應該有一個銷售小組的幫助,每一個寶潔品牌應當當做一個單獨的事業在經營,與其它品牌同時競爭。

麥古利贏得了寶潔高層的支援。同時他的成功表現使公司認識到產品管理的巨大作用。之後,寶潔便以 “產品管理體系” 重組公司體系。

這種管理形式為寶潔贏得了巨大的成功;同時,亦成為全球產品管理的典範。

產品經理的產生,標誌著從生產者市場向消費者市場的轉移。眾所周知的喬布斯是產品經理心目中的大神,一眾追隨者以某布斯的稱號為榮。

PO 與產品經理儘管不完全相同,但產品管理依然是 PO 的核心職責,只是在管理方法上與敏捷方法配套。

XP(極限程式設計)中客戶的概念

1993 年開始的 C3(Chrysler Comprehensive Compensation System)專案中,誕生了著名的 XP 方法論。

XP 重新定義了客戶的概念。在 XP 中,我們希望客戶、管理者和開發人員緊密地工作在一起,以便於彼此知曉對方所面臨的問題,並共同去解決這些問題。誰是客戶?XP 團隊中的客戶是指定義產品的特性並排列這些特性優先順序的人或者團體。

有時,客戶是和開發人員同屬一家公司的一組業務分析師、質量保證專家和 / 或者市場專家。有時,客戶是使用者團體委派的使用者代表。有時,客戶是真正支付開發費用的人。但是在 XP 專案中,無論誰是客戶,他們都是能夠和團隊一起工作的團隊成員。

最好的情況是客戶和開發人員在同一個房間中工作,次一點的情況是客戶和開發人員之間的工作距離在 100m 以內。距離越大,客戶就越難成為真正的團隊成員。如果客戶工作在另外一幢建築或另外一個城市,那麼他將會很難融合到團隊中來。

如果確實無法和客戶工作在一起,該怎麼辦呢?我的建議是去尋找能夠在一起工作、願意並能夠代替真正客戶的人。

Scrum 中 PO 的概念脫胎於 XP 中客戶的概念。

產品經理、專案經理和架構師的三角形

這個三角形更多是基於我在外企通訊行業的經驗。

產品經理隸屬市場部門,當採集到需求後,會以特性需求規範的形式呈現。

特性需求規範會交給專案經理,專案經理召集人員理解需求,轉化成特性技術規範,給出估算和規劃。根據需求的複雜程度,決定是需要架構師參與,還是只需要一般開發人員參與。

整體上,產品經理、專案經理和架構師呈現出一個支撐專案的三角形,分別從產品管理、專案管理和技術管理的角度發力。

PO 的採用

接著上面的背景,在採用 Scrum 之後,我們是由架構師充當 PO。一方面他封裝住了來自產品經理的需求,並轉換為使用者故事,而不再採用特性技術規範的形式。

另一方面,通過 Scrum 工作方式的採用,專案管理的職責被弱化,分攤到 PO 和團隊身上,PO 也需要跟團隊更密切協作保證需求被正確有效理解和實施。PO 本身的架構師背景也是一個優勢,使他除了問題領域,也能理解解決方案領域。

我們採用 Scrum 和設定 PO 之後,除了作為核心訴求的交付週期的極大縮短之外,在質量和效率方面都有顯著提升。

通過上面的溯源,總結一下 PO 角色設定的幾個理由:

  • 對於團隊來說,他代表的是需求方。不管需求方有多少來源,PO 要能封裝住需求方的需求。

  • PO 又與團隊一道密切工作,保證需求的正確傳遞。

  • PO 是整個管道中非常關鍵的一環,需要有足夠能力和得到足夠授權。

  • Scrum 和 PO 角色的設定也是對整體管理的簡化。

PO 角色的設定也許不是唯一可行的模式,但要想獲得 Scrum 和 PO 角色設定的成功,高層管理和整個組織要對 Scrum 和 PO 套路有清晰完整的認識,合理的權力分配和嚴肅認真的執行。

以下介紹精益敏捷三大核心做法在 PO 的體現。介紹不求完備,主要是理清各個實踐的邏輯因果,以幫助讀者思考、拓展和實施適合自己的實踐。

以使用者為中心在 PO 的體現

價值發現和驗證 

通過各種活動發現客戶關注的價值,並獲得驗證。具體的活動包含客戶訪談、客戶論壇、給客戶做演示、讓客戶試用產品等。

對於偏後端的產品,需要建立起內部使用者的概念,把功能的使用方作為內部使用者。功能的提供方和使用方需要協同一致建立起有效的價值發現和驗證機制。

價值驅動 

主要是指需求的優先順序排序。這涉及到兩個問題:切割和排序。首先是把需求切割到合適的顆粒度,然後是對需求進行排序,按照二八原理,把最有價值的需求排在前面。這樣,也為使用者終止開發或變更需求提供了靈活度。參閱:Scrum 合同模式:付費止損,免費變更

消除浪費在 PO 的體現

減少中間環節

在傳統的組織當中,開發團隊的兩端都離使用者很遠。在需求側,等到需要到達團隊手裡,已經經過了很多環節。

造成的問題,一是需求可能會失真,二是耽誤了時間,三是不能直接獲得反饋,這些都是浪費。在運維側,通常是由專職的運維團隊負責,開發團隊在這方面也遠離使用者。

後者的解決方案是 DevOps,參閱:DevOps 的前世來生,從《目標》、《鳳凰專案》到《持續交付》

一個組織要在整體上變成精益敏捷型組織,是很困難的,背後涉及到高層管理的認知和責權利的轉移。在不理想的情況下,PO 要想盡辦法接近使用者,縮短團隊與使用者之間的距離,排除因之造成的浪費。

成功的變革離不開權力。我們也看到過管理者的變換對團隊造成的影響,比如說有的管理者是產品導向,只要有利於產品,可以打破既定部門分工的規則,而有的管理者則是規則和流程導向,缺乏打破常規的勇氣。

清晰表達

PO 的需求表達的是否清晰,團隊是最好的裁判,因為需求是給團隊用的。歸一化合乎邏輯的格式,是需求表達的有力工具,比如說使用者故事和驗收標準。

PO 的需求表達訓練是值得投資的。有一個團隊,最初的時候 PO 沒有事先呈現需求,到了計劃會上才與團隊一道 brainstorm 需求,這當中蘊含著巨大的浪費和低效。後來經過對需求表達的學習和訓練,整個團隊的效率因此受益很多。

準備好

清晰表達是準備好的一個內容。準備好指的是在每一個活動之前,這個活動所需要的條件要準備好。

Scrum 中所用的術語是 DoR(Definition of Ready),在一個迭代開始前,相關物件和人員要達到準備好的狀態。準備好是一個檢查列表,示例如下:

  • 需求要有清晰的商業價值。

  • 需求要有明確的驗收標準。

  • 人員具備完成產品列表所需的技能。

  • 依賴和風險被識別和管理好。

根據 Scrum 之父 Jeff Sutherland 的研究,準備好能使團隊的效率倍增。參閱:從 Vision 到 Value,Backlog 精化帶你飛

顆粒度

不合理的顆粒度是一種浪費。顆粒度太大的需求,難以被理解,難以被估算,並因其模糊本性帶來更多的溝通成本。而顆粒度太小的話,會增加管理成本。

使用者故事是一種合適的顆粒度。使用者故事的一些重要特徵:

  • 一目瞭然格式一致的表達。使用者故事有兩個部分:描述部分和驗收標準。描述部分的常用格式是:As <使用者>, I want <功能>, so that <目的>。驗收標準可以有多條,常用的格式是:Given <前提條件>,When <動作>,Then<結果>。

  • 鼓勵推遲細節,只需有足夠的資訊以使專案前行。我們不需要一次性把專案的所有需求搞清楚,我們只需要在迭代之前把一個迭代要做的事搞清楚即可。而以使用者故事作為基本單元,可以支援這種開發模式。

  • 使用者故事以合適的顆粒度,方便理解,方便排優先順序,保證重要的事先做。隨著時間的推移,不重要的事也許就不需要了。

  • 使用者故事鼓勵通過交談了解細節。強調對話而不是書面溝通。

  • 使用者故事的驗收標準保證成果可以被稽核驗證。

  • 以使用者故事為載體,促進結構化溝通,使談話有落地點。

  • 從業務角度描述,可以同時被業務人員和開發人員理解。

  • 使用者故事的大小適合估算和做計劃。顆粒度適合迭代開發。

  • 支援隨機應變的開發,檢視和適應。

  • 鼓勵各方參與交流,傳播隱性知識。

參閱:敏捷讀書之使用者故事:《使用者故事與敏捷方法》解讀

探索式在 PO 的體現

快速反饋

《Scrum 指南》說,每個迭代都要構建一個 “完成”、可用的和潛在可釋出的產品增量。Sprint 評審會議在 Sprint 快結束時舉行 ,用以檢視所交付的產品增量並按需調整產品待辦列表。

在 Sprint 評審會議中,Scrum 團隊和利益攸關者協同討論在這次 Sprint 中所完成的工作。根據完成情況和 Sprint 期間產品待辦列表的變化,所有參會人員協同討論接下來可能要做的事情來優化價值。

這是一個非正式會議,並不是一個進度彙報會議,演示增量的目的是為了獲取反饋並促進合作。

能否在迭代結束時交付可用的產品,是 Scrum 成功與否的試金石。而從各自為政到合作的建立則是對管理方式鴻溝的跨越。

《精益創業》對反饋有更系統化結構化的描述:

  • Leap(信念飛躍):每一個商業計劃都是從一系列假設開始的。把假設說得像真的一樣,是創業者典型的超能力。正是因為整個企業的成功寄託在這一點上,所以它們被稱為信念飛躍。

  • Test(測試):一個最小化可行產品 MVP 有助創業者儘早開啟學習認知的歷程。它並不一定是想象中的最小型產品;它是用最快的方式,以最少精力完成開發-測量-認知的反饋迴圈。

  • Measure(度量):一家新創企業的工作是:(1)嚴格測量企業目前的狀況,正視評估中揭示的現實真相。(2)設計實驗,從而瞭解如何讓真實資料向商業計劃中的理想目標靠得再近些。

  • Pivot(轉型):每個創業者在開發一款成功產品的過程中,遲早會面臨一項重大挑戰:即決定何時轉型,何時堅持。

參閱:GitChat 的精益創業之旅

分層計劃

敏捷的計劃有五層:

  • 組合級 (Discussion):在這一層,主要是跟產品決策委員會一起討論哪些產品上還是不上。

  • 產品級 (Envision,Funding,Roadmap):在這一層,主要是確定產品的願景、預算和路線圖。

  • 釋出級 (Story Writing,Release Plan,PB Grooming):在這一層,包括故事寫作、釋出計劃和產品列表梳理。

  • 迭代級 (Sprint Plan,Review):這一層包括迭代的計劃和評審。

  • 每日級 (Steer Direction,Answer Question):這一層包括方向的把握和回答團隊的問題,這些是通過與團隊在站會上和日常的互動交流實現的。

通過把計劃分層,從更長期的角度是擁抱變化,從更短期的角度是紮實執行。通過行動排解近憂,通過變通容納遠慮。

參考:PO 工作指導:掌舵 3355 的迭代之河

PO 的角色建立及按照三個核心思路有效發揮,需要管理者的認知與支援、PO 本人的學習,和周邊組織和人員的配合。

邏輯四:三個核心在團隊的體現

640?wx_fmt=jpeg

PO 是上游,團隊是下游。PO 主要負責需求,是問題領域。團隊主要負責解決方案領域。上下游的合理有效交接很重要。

在 PO 身上落實的三個核心思路,同樣要落實到團隊身上,但有有幾個不一樣的地方:需求交接問題,技術能力問題,多人合作管理問題。具體說明如下。

以使用者為中心在團隊的體現

清楚瞭解需求

與 PO 的清楚表達需求相對應,團隊要做的是清楚瞭解需求。這可以發生在幾個環節:

  • 產品列表梳理會:產品列表梳理會是 PO 幫助團隊理解需求的主要時機。團隊可以用 DoR 要求 PO,在會議前的準備度達到準備好的標準。團隊也要花一些時間準備,大致瞭解一下背景和上下文,跟需求混個臉熟,省得到時候一頭霧水。現場可以用估算紙牌做估算。採用估算紙牌最重要的目的不是估算本身,而是揭示大家的不同理解和假設。

  • 技術梳理會:如果是因為沒有解決方案而妨礙了對需求的理解,可以增加一個技術梳理會,探討解決方案,達到可估算的標準即可。

  • 迭代計劃會:是理解需求的第二道閘,提供了又一次澄清需求的機會。

  • 日常工作和每日站會:如果還有不清楚的需求,團隊有提問的責任,PO 有解答的責任。

  • 迭代評審會:正常來說,到了迭代評審會不應該再有對需求的分歧。有的話,可以利用迭代回顧會找下原因,對症下藥解決。

需求主要是 PO 的責任,但團隊要主動參與理解,並且有質疑和追根到底的精神。

對於團隊成員不主動參與理解需求的情況,通常是動機和合作的問題。功夫在詩外。需要從後面的權力結構和人的激勵入手。

消除浪費在團隊的體現

自管理

被管理,是一種浪費。對於管理者,投入是一種浪費。對於被管理者來說,被打斷和被控制是一種浪費。最好的管理是自管理。

Scrum 的儀式用得好,就已經是自管理了。人人都是專案經理。

參閱:A1 大白紙計劃法

B=MAT,行為 = 動機 x 能力 x 觸發。自管理的能力不難學習,Scrum 事件和流程就是觸發,剩下的就是動機問題了。

跨職能

跨職能的含義是,一個團隊要具備完成產品列表的全部技能,並且團隊的技能分配足夠均衡和充分備份,以至於能適配產品列表中對不同技能的需求量,和人員可以自由請假。

跨職能需要組織的政策支援和個人的認知改變。跨職能會加強一個人的能力而不是削弱一個人的能力。

參閱: Scrum 的跨職能團隊建設遊戲

視覺化

隱藏,是一種浪費。視覺化的六個原則是:

  • 視覺化價值流動,有效管理創新全過程;

  • 視覺化擁堵,分析發現問題,加速流動;

  • 視覺化任務資源匹配,實現戰術沙盤;

  • 視覺化決策規則,養育自組織團隊;

  • 視覺化風險,管控創新風險;

  • 視覺化投入組合情況,平衡長短期利益。

參閱:視覺化管理六原則

流動

在前文流的歷史中,已經對流動有所介紹。流動是精益思想五原則當中的重要原則。

在製造業的生產過程中,物有四種狀態:

  • 加工;

  • 檢查;

  • 停滯;

  • 搬運。

停滯是不流動,檢查和搬運是可以優化的流動,只有加工是有價值的流動。

創造流動有三個步驟:

  • 化身為物:把自己想象成被處理的工作,被處理的工作也是沒有耐性的。

  • 建立流動:排除障礙,讓工作流動起來。

  • 保持流動:把流動持續保持住。

故事泳道是一個在站會中輔助流動的工具。參閱:故事 X 人矩陣

關於流動效率,參閱:研發組織該如何設計績效體系

紀律

技能 x 紀律 = 能力。敏捷對紀律有很高的要求。

幾年前,我對 Scrum 有個總結:十論 Scrum 就是知行合一。

  1. 人人知行合一:人人計劃,人人行動。

  2. 時時知行合一:時時計劃,時時行動。

  3. 團隊知行合一:團隊決定,團隊行動。

  4. 敏捷知行合一:快速決定,快速行動。

  5. 需求知行合一:接近客戶,掌握需求。

  6. 支柱知行合一:檢驗是知,適應是行。

  7. 完成知行合一:定義完成,共識目標。

  8. 透明知行合一:高度透明,流暢過程。

  9. 紀律知行合一:自我紀律,助長能力。

  10. 美德知行合一:積極主動,集思廣益。

紀律的建立,主要靠目標感,組織目標、團隊目標和個人目標的對齊,和同儕壓力。

參閱:我與 Scrum 的心路歷程

2014 年,柳傳志在微博之夜上表示,聯想要開二三十人的會,如果這個會是準時開的,誰遲到的話罰站一分鐘;會議正開的時候停下來默哀式的讓你站一分鐘,這實際是個非常難過的事兒。

這件事情從 1990 年開始一直執行到今天,只要有一定做。包括我自己遲到也被罰過三次。國內商業誠信不好的關鍵是選擇性執法,法律面前人人平等,沒有人敢觸犯法律。

柳傳志的做法是否適合敏捷團隊?答案是,只要大家都同意,就可以執行。

團隊規模

根據各種研究,小團隊是最有效地。其中最有名的說法是貝索斯的兩個披薩餅團隊。如果兩個披薩不足以餵飽一個專案團隊,那麼這個團隊可能就顯得太大了。

《Scrum 指南》中說:開發團隊最佳規模是足夠小以保持敏捷性,同時足夠大可以在 Sprint 內完成重要的工作。少於 3 個人的開發團隊,成員之間沒有足夠的互動,因而生產力的增長不會很大。過小的團隊在 Sprint 中可能會遭遇到技能上的約束,進而導致開發團隊無法交付潛在可釋出的產品增量。超過 9 人的團隊則需要過多的協調溝通工作。對經驗過程而言,大型開發團隊會產生太多的複雜性而變得無用。產品負責人和 Scrum Master 角色不包含在開發團隊人數中,除非他們同時也參與執行 Sprint 待辦列表中的工作。

我曾經處理過一個 15 人以上的團隊,開始時,大家都認為不可能分成兩個團隊,因為工作都耦合在一起。後來經過梳理,把工作分類,分成了兩個團隊,也運作得完全沒有問題,效率比之前有很大提升。

完成標準

大野耐一對價值的定義是:

  • 客戶願意為之付錢。

  • 是一個過程。

  • 一次做對。

對於軟體開發來說,一次做對的說法不能機械應用,否則還要 Debug 幹啥?有完成的標準,大致對應大野耐一所說的一次做對。沒有完成的標準,就是浪費。

對於一個迭代來說,完成的標準包括兩個方面:關於結果的和關於過程的。跟準備好的標準一樣,完成的標準也是一個檢查列表,示例如下:

  • 釋出到生產環境。

  • 零已知故障。

  • 使用者文件的要求。

  • 程式碼評審的要求。

  • 單元測試的要求。

  • 持續整合的要求。

前三者是關於結果的,是外部質量。後三者是關於過程的,是內建質量。

通過擴大完成標準的範圍和提升完成標準的要求,也能幫助一個團隊的自我提升。

探索式在團隊的體現

小批量

迭代列表本身就是個小批量。

在迭代內部,我們還可以進一步運用小批量的概念。如果一個迭代有 10 個使用者故事,到迭代結束時,每個都完成了 90%,這種狀態不如有 5 個 100% 完成,有 5 個還沒開始做。

這也是一種小批量思維。只要沒有完成,80% 也好,90% 也好,都是不可靠的。

如果你的團隊在完成上總是有困難,可以嘗試更小的批量,大家通力合作,一次完成一個更小的批量,這既能提升效率,也促進合作,為更高的效率奠定基礎。

快速反饋

除了在迭代層面的迭代評審的反饋,快速反饋還可以在迭代內部運用。

測試和程式碼評審都是反饋。結對程式設計、結對工作,和更緊密的協作都是加速反饋。

參閱:細顆粒度的協作

分層規劃

規劃的分層跟在 PO 的那一部分的陳述是一致的。

PO 和團隊在規劃問題上的分工合作是:

  • PO 負責方向,包括產品願景、路線圖、使用者故事優先順序等。

  • 團隊負責估算。估算的原則是:讓幹活的人做估算。

  • 團隊通過估算,幫助 PO 理解成本並相應地調整優先順序。

  • 團隊幫助 PO 理解業務故事背後可能涉及到的技術架構工作。

  • 關於風險:PO 管理與客戶有關的風險,團隊管理與技術有關的風險,ScrumMaster 管理與組織和溝通有關的風險。

技術卓越

敏捷宣言的原則之一是:堅持不懈地追求技術卓越和良好設計,敏捷能力由此增強。

技術永遠是開發人員的核心能力。在需要快速響應的環境之下,技術提升是 Scrum 團隊建設的重要內容。

參閱:眾籌式知識分享在團隊和組織的運用

邏輯五:權力結構

640?wx_fmt=jpeg

敏捷的實施好比是在大海中潛水,在靠近水面的部分沒什麼大的障礙。前述三大核心思路在 PO 和團隊的體現,更多是一些在靠近水面部分潛水的招式。

隨著潛水深度的增加,就會遇到礁石。權力結構是一個礁石。

企業中的權力是如何產生的?薛兆豐有一個解釋:

我不知道你有沒有看過這樣的場面,就是在舊社會很落後的時候,有一種職業叫縴夫。他們就是在岸上拉船的人,那是一種苦工。

一群衣衫襤褸的工人,在岸上賣力地把船從一個地方拖到另外一個地方,而這時候,這群辛苦工作的縴夫背後還有一位舉著鞭子的監工,為什麼會有這樣的職業?

如果可以選擇,你願意當縴夫還是當監工呢?很多人會說那我寧願當監工,被人抽還不如抽別人。但問題是為什麼就沒見到大家都變成了監工呢?

你要再想想這船是縴夫拉的,收入是他們掙的,憑什麼他們掙來的收入還要分一塊給這個監工,他們可不可以合計一下,說下次我們找到工作就不要這個監工了。

事實上,監工這個職位一直存在,我們需要對它進行解釋。這個解釋就是,縴夫們自己知道,他們自己會偷懶,他們會虛張聲勢地賣力,他們知道如果是這樣的話,他們的總收入會下降。出錢請了一個人來鞭打他們自己,他們的收入反而會增加。

我們姑且把上文中的縴夫稱為工資奴隸。然而,工資奴隸制無法滿足現代經濟的需要。在一個被全球化、放松管制、知識工作和新技術所顛覆的市場中,企業現在需要主動、創新、承諾、聰明、激情——而這恰恰與僱傭奴隸制截然相反。參閱:為什麼敏捷正在吞噬世界

因此,這種新型的工作者需要一種新的管理方式。一些人將這種方式稱為敏捷組織運作。也有用別的標籤的。但是不管它叫什麼,它都不只是個新流程。這是一種完全不同的運作方式。

這在經濟上更有成效。它對人類的精神有著巨大的潛在益處。它可以創造工作場所,使人類能夠貢獻他們的全部才能,為其他人類創造有價值和有意義的東西。

對於精益敏捷來說,合理的權力結構是怎樣的呢?

共同目標

在 Scrum 團隊中,PO、ScrumMaster、團隊三個角色各有分工,但大家的目標是一致的,都是為了通過每迭代輸出潛在可交付的產品增量來實現產品願景和價值。

最近在一篇文章中看到一個團隊的描述,我認為這是一個真正的敏捷團隊,儘管不一定用敏捷的標籤。參閱:掙來的普吉之行

在小的創業公司,創始人的認知就可以決定一個團隊的形態。對於大公司來說,建立真正的敏捷團隊會有很多困難,但最高管理者的認知是阿基米德點。

共同責任

敏捷影響力第一人 Mike Cohn 說:在一個團隊的迭代中,我不能說,我的任務完成了,而張三還有些任務沒完成。

一個敏捷團隊一榮俱榮一損俱損。如果一個團隊的 ScrumMaster 獲得了好的績效,而團隊成員普遍獲得了不好的績效,那麼這個組織的管理是有問題的。

羅輯思維有個節操幣制度:

每個員工每個月可以獲得 10 張節操幣,每張相當於人民幣 25 元。他們可以用這張節操幣在我們周邊的咖啡廳和飯館隨便消費,還可以獲得打折和 VIP 待遇,公司月底統一與這些飯館結賬。

但是,節操幣不能自己使用,必須公開贈送給小夥伴,而且要在公司公示你為什麼要把節操幣送給他,說明具體原因。節操幣成為了我們的硬通貨,每月公司會公示當月節操王。

每年收到節操幣最多的節操王,會獲得年底多發三個月薪的獎勵。所以,每個人都能看到一個公開的數字,這個節操幣的交易情況,反映了每個人與他人協作的水平。

很少收到節操幣的人,一定是協作水平和態度比較低的,而且是由全體員工每天的自然協作做出的評價,是一張張真實的選票。這種落後的人,會很快自覺改善,或者離開公司,他們會感受到強烈的壓力。

參閱:羅振宇跨年演講中的精益敏捷要素

共建體系

上面的節操幣制度已經是共建體系的一個例子。

在敏捷團隊中,大小制度都可以由團隊共建。最常見的一些有:

  • 團隊規範與工作協定。

  • 完成的定義。

  • 準備好的定義。

服務而不是權力

如果能做到上面三點,權力就不需要了。

這裡有一個有決心改變權力結構的案例。參閱:J.P. 摩根運用 LeSS 框架實施大規模敏捷。

而對於大多陣列織來說,徹底的改變是不容易發生的。管理者要有觀念的扭轉,從掌權者變為服務者:

  • 在團隊管理方面:將團隊的自組織能力和經理們的有效領導相結合。

  • 在投資管理方面:讓團隊從以計劃為導向的思維方式轉化到以價值為導向的思維方式。

  • 在環境管理方面:在由各種流程和外部資源組成的組織環境中,高效地審視組織內各流程的設計以消除各種對組織資源的浪費。

權力是組織的障礙,主動變革才是出路。

邏輯六:人的激勵

640?wx_fmt=jpeg

權力結構之外,不被激勵是另一個暗礁。

對一個人績效影響最大的是他的動機。參閱:B=MAT 在 Scrum 中的運用

以下對動機的描述並無完備,只是列出常見的一些。

工資

工資這個東西,從公司的角度是成本,從員工的角度是生活的期盼,從兩者關係的角度是交易。

要在這個問題上有所提升,員工需要創造更大的價值,公司需要在整個價值流中消除浪費,大家從創造的價值中分享收益。

獎金

從公司的角度,獎金是業績完成超出預期的部分,從員工角度,獎金是對生活的改善。工資對應一個人的職責和能力,而獎金對應一個人對團隊合作的貢獻。

福利

福利包含可以物化的部分和不可物化的部分,比如彈性工作制和假期。

公平

要有廣為接受的遊戲規則。

關係

要有相對平等的關係。

邏輯七:ScrumMaster

640?wx_fmt=jpeg

ScrumMaster 是工作方式的化身。參閱:系統的化身—敏捷教練的人設

ScrumMaster 所要做的如下:

邏輯與招式

ScrumMaster 需要精通精益敏捷的邏輯和招式。

獲得授權

ScrumMaster 需要獲得組織的授權,成為 Scrum 的化身。

建立流程

進而建立 Scrum 工作方式。

解決問題

還需要解決背後的各種障礙和問題。

邏輯八:與 PMBOK 對照

640?wx_fmt=jpeg

最後,我們從 PMBOK 五大過程組和十大知識領域的角度來檢視一下敏捷。

五大過程組:

  1. 啟動過程組 :作用是設定專案目標。在 Scrum 當中,目標不是一次設定,而是分層和逐步調整,預測性和適應性並重。PO 負責產品願景,團隊負責迭代目標。

  2. 規劃過程組 :作用是制定工作路線。在 Scrum 中,有長期的產品路線圖,中期的釋出計劃,短期的迭代計劃,和每日計劃。

  3. 執行過程組 :作用是讓團隊按計劃執行。Scrum 的做法主要有兩點不同,第一是通過上述的五層計劃,增加了適應性。第二是全員參與計劃和執行,計劃的人就是執行的人。

  4. 監控過程組 :作用是測量專案績效,並且儘量做到防患於未然。Scrum 當中的進度監控主要通過迭代燃盡圖和釋出燃上圖,質量監控主要通過 DoR 和 DoD 來內建質量。

  5. 收尾過程組 :作用是了結專案。在 Scrum 中,收尾劃分到每個迭代,通過迭代評審和迭代回顧進行,一方面可以快速獲得反饋,另一方面可以持續改進。

從五大過程組的角度來看,敏捷是把傳統的大專案變成一個個小專案,大環套小環,把航母變成一艘艘快艇。每個小環依然有完整的五個過程,只是做法有所不同。

從每個小環中的學習,可以幫助增強大環。

參閱:1986 年第一篇關於 Scrum 的論文及內建(Built-in)思想

十大知識領域:

  1. 整合管理 :其作用是把所有方面貫穿起來。在敏捷當中,產品導向重於專案導向,產品列表是貫穿各種事物的線索。

  2. 範圍管理 :其作用是做且只做該做的事。在敏捷當中,範圍被視為一個可變的要素。參閱:Scrum 合同模式:付費止損,免費變更

  3. 時間管理 :其作用是讓一切按既定的進度進行。在敏捷當中,關注點放在流動和趨勢,而不是嚴格的時間表。

  4. 成本管理 :其作用是算準錢和花好錢。在敏捷當中,基於迭代增量式的開發,對成本的測量會更容易。

  5. 質量管理 :其作用是滿足需求。在敏捷當中,通過採用完成的定義來內建質量。

  6. 人力資源管理 :其作用是讓團隊成員高效率地和你一起幹。在敏捷當中,通過 Scrum 團隊建設,更大化地協同團隊的生產力。

  7. 溝通管理 :其作用是在合適的時間讓合適的人通過合適的方式把合適的資訊傳達給合適的人。在敏捷當中,通過 Scrum 框架來引導溝通。

  8. 風險管理 :其作用是防患於未然。Scrum 的五層規劃和團隊自管理有利於風險管理。

  9. 採購管理 :其作用是當好甲方。敏捷的迭代增量式可以幫助做出更具適應性的採購決定。

  10. 干係人管理 :其作用是和專案干係人搞好關係並令其滿意。在敏捷當中,通過透明化提升信任。

從十大知識領域來看,敏捷採用的是一種更柔性更透明更授權的方式。

總結

本文的重點是精益敏捷的八大邏輯 

邏輯一 是精益敏捷產生的 3C 環境。 

邏輯二 是因之產生的三大核心問題和三大核心思路。

邏輯三 和 邏輯四 是三大核心思路在 PO 和團隊身上的體現。

邏輯五 和 邏輯六 是兩個暗礁:權力結構和人的激勵。

邏輯七 是作為精益敏捷化身的 ScrumMaster 的作用。

邏輯八 是敏捷與 PMBOK 的簡單對照。

八大邏輯涵蓋了兩個根本元素:邏輯元素或科學方法,權力元素包括個體和組織結構。

八大邏輯祝你成功地設計和應用精益敏捷。

擴充套件閱讀