說在前面：達人課是GitChat的一款輕閱讀產品，由特約講師獨家釋出。每一個課程你都可獲得6-12篇的深度文章，同時可在讀者圈與講師互動交流。GitChat達人課，讓技術分享更簡單。進入我的GitChat

溫馨提示：本篇文章較長，點選原文閱讀

作者介紹

GlenWang，敏捷教練，致力於打造卓越個人和組織。經歷過三個行業：通訊，電子製造，金融 IT。三個職業：開發人員，經理，精益和敏捷教練。譯著有《特斯拉：電氣時代的開創者》。敏捷之旅講師，認證 Scrum Master 課程 Co-Trainer。

虎頭錘，旅居墨爾本的程式猿，十年 Coding，區塊鏈比特幣ing，手繪進階ing。

課程介紹

在網際網路時代快速變化的今天，傳統管理方式已經失效並且逐漸被社會淘汰，我們需要全新的方法來適用於不同規模的團隊。敏捷教練和 Scrum Master 是一種專業的職業。其職責是幫助團隊和組織做到更好（本課程視 Scrum Master 和敏捷教練為同一職業的不同發展階段）。敏捷能力的培養並不是簡單瞭解後就可以速成的，但如同任何其他職業一樣，成為一名敏捷教練是有一套可以刻意練習出來的基本功。

本課程按“目標-儲備-技巧-實戰”四部曲，介紹敏捷教練和 Scrum Master 的基本功：

對精益敏捷框架和基礎知識的紮實理解
對團隊在敏捷應用過程中所處階段的理解
模式及 Scrum 中的各種子模式
敏捷教練的內在修養、教練方法和自我提升方法
持續改善與系統思考方法
敏捷教練需要了解的技術實踐
敏捷教練在團隊中一個典型的教練週期

概述

敏捷教練是一個職業。Scrum Master 和敏捷教練是同一職業的不同階段。當一個人能帶好一個 Scrum 團隊時，他是一個 Scrum Master。當他能帶各種不同型別的團隊，並持續追求更好，他就是一個敏捷教練。

Scrum Master 職責的範圍和邊界相對確定，敏捷教練職責的範圍和邊界相對不確定。但從學習的角度，他們所需要的基本功是一致的。本課程中對這兩個角色，在大多數時候不太區分。鑑於這兩個角色既有相似處又有區別，大家在使用時對這兩個名稱的理解上又有變異，所以課程的名稱中就把這兩個名稱並稱，以求相對準確地表達這個課程所要服務的角色。就算是您所採用的敏捷方法不是 Scrum，依然可以從本課程中受益。

如同任何其他職業，敏捷教練有它的技能，也需要並且能夠通過練習達到精通。我們可以通過四部曲的結構理解敏捷教練這個職業及其技能：

• 目的：任何一個職業，都有它存在的目的。這個目的包括職業產生的背景，工作的環境，以及所承擔的職責。
• 儲備：即敏捷教練所必備的基礎知識。
• 技巧：即如何運用基礎知識履行職責。
• 實戰：即在一個典型完整的工作週期中，如何利用儲備和技巧取得成功。

本章會介紹：

• 敏捷教練這個職業產生的背景
• 敏捷教練的工作環境
• 敏捷教練的職責
• 體系化的參考書目
  

敏捷教練職業產生背景

“追求更好”旅途的守護者

我們從敏捷的歷史來看一下，敏捷教練這個角色是如何誕生的、這個角色對組織意味著什麼。

敏捷方式可以追溯到1620年弗朗西斯·培根（Francis Bacon）科學方法的發源時期。更合理一點的起點可能是在20世紀30年代，那時候貝爾實驗室的物理學家和統計學家沃特·阿曼德·休哈特（Walter A. Shewhart）開始使用計劃-執行-學習-調整（PDSA）迴圈對產品和過程進行改善。

休哈特把這種反覆漸進的開發過程教給了他的學員戴明（W.Edwards Deming），後者在二次大戰後的日本大量使用了該方法。戴明將 PDSA 改造為 PDCA。豐田公司僱用了戴明來培訓公司中數百名經理，並在他的經驗之上創立了著名的豐田生產體系——這也是如今精益思想的最初由來。這種反覆漸進的方式對於20世紀50年代的 X-15 超音速飛機的製造也是貢獻巨大。

豐田模式的關鍵，以及使豐田有傑出表現的原因並不是任何個別要素，而是一個由各要素組成的 4P 體系：

• 長期理念（philosophy）：重視著眼於長期的思維，公司高層注重為顧客及社會創造與提升價值，這個目的主導了該公司的長期方法——建立學習型組織，投資於人員、產品與工廠，以及絕不鬆懈地堅持質量，以適應環境的變遷，成為高效的組織。

• 正確的流程（process）：正確的流程方能產生優異成果，流程是以低成本，高安全性與高昂的士氣達成最佳質量的關鍵。

• 藉助員工與合作伙伴（people and partner）的發展，為組織創造價值：豐田公司管理層的看法是，他們打造的是“人”，不是汽車。尊重員工的智慧和能力，並不斷激勵他們做得更好。

• 持續解決根本問題（problems）是組織型學習的驅動力：豐田模式的最高境界是組織型學習，豐田的持續學習制度重心在於辨識問題的根源，並預防問題的發生，持續改善。

此體系必須每天以貫徹一致的態度實行，而非只是一陣旋風。這個體系成功的祕訣是，經理即教練。培養深諳公司理念的領袖，使他們能教導其他員工。這是我們今天思考敏捷教練職責的最重要參照物。豐田的 4P 模式，也能幫助我們從根本上去思考什麼是敏捷。

大野耐一是將豐田生產方式體系化的重要人物。大野耐一退休後，與其弟子建立了 NPS（New Production System），為其他企業服務。精益教練誕生，教練與經理分離。這也預示著在今天敏捷教練和管理者通常是分離的職位。

Scrum 的另一根植於日本的基礎，是1986年野中鬱次郎和竹內弘高在哈佛商業評論上發表的名為《新的新產品開發遊戲》的文章。通過研究那些比競爭者更快釋出新產品的製造商們，比如富士-施樂的影印機，本田的摩托車引擎，佳能的照相機，定義了以團隊為基礎的新的產品設計和研發過程。這種過程不是通常在產品開發中的“接力賽”——一組專家完成產品部分功能並將專案傳遞到下一組專家手中。這種方式被野中鬱次郎和竹內弘高稱作為“橄欖球”方式，“團隊試圖作為一個整體完成所有任務，將球傳來傳去。”

在1993年，Jeff Sutherland 面臨一項似乎是不可能完成的挑戰：Easel 是一家軟體公司，需要在半年之內開發一款新產品來替代它的傳統產品。Jeff Sutherland 通曉很多方法，比如快速應用程式研發，面向物件設計，PDSA 迴圈，專案工作等等。他希望在公司總部建立一個類似於專案工作的文化氛圍，將組織分割和合並的好處結合起來。他開始學習任何和提高組織效率相關的知識。通過閱讀上百篇研究報告和頂尖的產品管理專家面談，他腦海中逐漸有了一些有煽動力的想法。

這中間有一個想法來自於貝爾實驗室的關於 Borland Quattro Pro 團隊的文章。該文章主張，每天短的團隊會議能顯著增加團隊效率。而 Jeff Sutherland 的核心概念則來自於竹內弘高和野中鬱次郎的“橄欖球”方式，雖然該方法更關注製造過程而不是軟體開發過程。通過借鑑哈佛商業評論文章中的關鍵想法和進行一些特別的試驗，Jeff Sutherland 建立了一種新的軟體開發方法，歸功於橄欖球帶來的靈感，Sutherland 將這種方法稱為“爭球”（Scrum）。Scrum 方式最後確保了他準時完成了似乎不可能的任務，也沒有超出預算，程式漏洞比之前版本還要少很多。Sutherland 隨後就長時間和 Ken Schwaber 對該方法進行長期研究，並在1995年兩人首次在公眾面前釋出 Scrum 的方法。

在2001年，17位自稱“有組織的無政府主義者”在美國猶他州的雪鳥滑雪場會面，分享他們的想法。Jeff Sutherland 和其它 Scrum 的先驅也在其中。參與者們分享了互相競爭的幾種方式：極限程式設計（XP）、水晶方法、自適應軟體開發（ASD）、特性驅動開發（FDD）、動態系統開發方法（DSDM）。所有這些方式都是“輕量版”的框架，因為這些方法使用更少、更簡單的規則來適應快速變化的環境。不少與會者都覺得“輕量”這個術語挺適用的。

雖然與會者不能在方法上達成一致，但是他們還是為這個運動取了個名字：敏捷。這個詞是一位參與者提出的，他當時正在讀《敏捷競爭者和虛擬組織：給客戶更多的策略》一書。書中列舉了100家公司的例子——包括 ABB， 聯邦快遞，波音，博士和哈雷戴維森，這些公司正在建立適應動盪市場的新方法。有了這個名字，參與者達成一致，釋出了“敏捷軟體開發宣言”，該宣言中突出了每個人都同意的4個關鍵價值。稍後在會議中，以及之後的幾個月中，他們發展了12個原則，被稱為“敏捷宣言背後的原則”。 從2001年開始，所有的開發框架，以及與之匹配的價值觀和原則就被稱作為敏捷技術。

同時，敏捷方法繼續演化。在20世紀80年代後期和90年代前期，MIT 的研究學者們開始研究日本的製造體系，特別是豐田生產體系。他們借用了名詞“精益”來描述改善效率的這套體系，包括消除浪費（muda)， 減少波動（mura）和降低負荷（muri）。雖然精益方法並沒有在雪鳥會議上被表述成敏捷方法，但是精益和看板軟體開發系統在後來被併入敏捷系統。在開始時候，一些純粹的敏捷主義者拒絕承認精益方法。 但是精益宣傳該方法能關注客戶協作，最終更多的敏捷踐行者開始接受精益，看板，還有混合方法（比如 Scrumban 和 Lean scrum），作為敏捷價值和原則合法的應用。

這些新方法論的創始人們是精通技術的管理者，和管理者中的思想者。敏捷宣言的17位創始人，是敏捷思想的傳道者，可以被認為是最早的敏捷教練。他們所創造的這些方法的本質，不是一些死板的規定，而是在追求“更好”的旅途中，作為承載“更好”的載體。這些方法論的落地，以及作為這些方法論內在精神的追求“更好”，不會自動發生。

一種可能的邏輯是，由管理者來承擔落實新方法論的責任。管理者可以轉型為教練，重拾作為精益鼻祖的豐田的精神。對於管理者無法承擔教練職責但又想追隨敏捷潮流的組織，則需要專職的敏捷教練。

敏捷教練工作的環境

守破離的概念來自日本，大致可以理解為遵守、突破和脫離。這個概念在敏捷界被廣泛運用，含義也會有所變遷。下面這個關於組織所處階段的守破離，來自於 Scrum 之父 Jeff Sutherland。

組織的守的狀態

• CEO 沒有敏捷思維。以命令和控制的文化為主。
• 依據傳統的管理層級結構產生專案組。
• 即使採用敏捷，也是跟風，流於形式，無法深入。
• 在這種狀態之下的效率提升通常只能做到20%~30%

組織的破的狀態

• CEO 改變管理者的角色。教練和支援的文化浮現。
• 管理者教導團隊自組織和自管理。管理者成為領導者。
• 領導者為團隊提供有挑戰的排好優先順序的目標。
• 消除組織債，建立可行的商業和組織計劃，提供團隊所需的資源。
• 識別和移除障礙，消除浪費和技術債，確保團隊速率最大化。
• 確保產品負責人對交付的價值負責。
• 確保 Scrum Master 對流程改善和團隊快樂負責。
• 確保團隊對質量提升和技術債修復負責。
• 團隊依據排好優先順序的產品列表自我形成。
• 領導者在組織內驅動不同技能的虛擬實踐社群，為組織提供能力建設。
• 領導者按需重構組織。
• 在生產力方面會取得200%~400%的提升。
• 示例公司：Spotify，SAP，Salesforce，Microsoft。

組織的離的狀態

• 層級仍然存在，但主要是為技能培養服務。
• 團隊自組織負責產品方向和組織重構。
• 領導者支援團隊所需的技能。
• 群遊使組織在壓力之下更強壯。
• 產生500%~1000%的生產力提升。
• 示例公司：Valve，Zappos，Morning Star，Gore，Grindr。
  這三種狀態，跟建國方略中的軍政、訓政和憲政暗合，可參照理解。

瓶頸通常在瓶子的上部，一個公司最大的瓶頸是 CEO。作為一個敏捷教練，針對所處的組織形態，可以採取運用敏捷基本功加上變通的方法來開展工作。

至於團隊，也會有三種形態。

無組織團隊

• 從團隊績效方面看，是相對不高和不穩定的，時好時壞。迭代計劃預測的靠譜度較差，速度也不高。
• 從團隊動態和互動看，呈現出一種各自為政的狀態，溝通不暢，合作困難。從會議看，目的不明確，流程不清晰，效率低，參與者沮喪。

自運轉團隊

• 從團隊績效看，呈現出相對穩定的狀態，迭代目標承諾靠譜度較好，迭代目標基本能完成。
• 從團隊動態和互動看，團隊成員目標一致，有良好的溝通合作，在各項活動中，團隊成員都能主動參與。會議的目的和流程清晰，沒有 Scrum Master 的情況下，會議也能按照打磨好的流程自動運轉起來。

自組織團隊

• 從團隊績效看，在穩定的基礎上，呈現出階段性的持續提升，生產率和質量不斷提高。
• 從團隊動態和互動看，團隊有更多高質量的互動，團隊除了關心共同的目標，還關心持續改善和從根本上解決問題。呈現出上文中所說的豐田 4P 的一些特徵。
  敏捷教練所要做的，就是把團隊從無組織狀態帶到自運轉狀態，再進一步帶到自組織狀態。這個使命的履行，本課程中敏捷教練和 ScrumMaster 的基本功可以幫到您。

敏捷教練的職責：流程與人兩手抓

在設計本課程之前，針對一部分敏捷從業人員和經歷者做了一個小調查，想了解他們對 Scrum Master 職責的理解。這個調查雖然樣本較小，不具備統計意義，但依然可以幫助我們瞭解跟我們處在同樣角色的人對這個問題怎麼看。調查結果如下：

• 精通管理規則，精通業務梳理，極強的溝通協作能力，技術熟練，懂業務管理。
• 敏捷教練確保 Scrum 被正確的運用和貫徹，同時保護團隊和引導新的想法落地。
• Scrum Master 是牧羊犬的作用，讓團隊在一個迭代中不受打擾，同時他應該對敏捷的流程、理念有深入的瞭解，具有較強的管理能力。
• 引導團隊進行效率的提升，通過各種工具的匯入，來實現專案目標。但是，究竟是否要像傳統團隊一樣，也要引導團隊進行專案交付，並解決依賴問題，這個要商榷。
• 保證團隊資源，保證各個角色及職責協作，解決團隊開發中的障礙，協調解決溝通問題，保證開發過程按計劃進行。
• 指導 Scrum 小組成員理解為什麼、知道如何參與 Scrum 實踐的每一個環節，把控好 Scrum 實踐的產出，為整個小組的 Scrum 迭代/計劃結果負責。
• 基於對 Scrum 角色的瞭解，以及對專案和資源的認識，幫助 stakeholder 決定最佳的按照 Agile 路線來實施專案的教練。
• 培訓和指導團隊踐行敏捷實踐；關注專案的度量資料，及時帶領團隊調整，加速或穩步前進；關注成員的狀態，激勵督促團隊前進；帶領和輔導團隊按照敏捷和精益的方式做事，打造優秀自組織團隊。
• 牧羊犬守護團隊，流程；教練，培訓，引導團隊，PO，相關人知識，技能；推動過程改進，促進變革；提升團隊，組織效能。
  在敏捷團隊中推進敏捷開發模式和流程，是團隊的組織者，保證團隊資源，協調內外部關係，解決出現的問題。
• 幫助團隊進行敏捷實踐落地，梳理流程，減少外部干擾，鼓舞士氣，提高團隊作戰能力。提高工作效率。
• 傳播敏捷思想，指導團隊，指導 PO，組織敏捷會議，排除團隊干擾。
• 指導團隊按 Scrum 方式運轉，傳播 Scrum 思想，指導敏捷實踐，提高效率。
• 保證團隊資源完全可被利用並且全部是高產出的。保證各個角色及職責的良好協作。解決團隊開發中的障礙。做為團隊和外部的介面，遮蔽外界對團隊成員的干擾。保證開發過程按計劃進行，組織 Daily Scrum，Sprint Review and Sprint Planning meetings。
• Scrum Master 是 Sprint 的負責人，Sprint 做得好不好的終責者。負責計劃，執行 Sprint，並使團隊團結及有自主創造能力。
• 搭建 team 架構，分配各個角色成員，開展 scrum 常規的事項，並讓敏捷的理念深入人心。幫助團隊更好的按照 Scrum 框架有效的執行，對團隊遇到的問題和障礙提供幫助，協助掃清研發過程中的障礙，打造高效能的團隊。
• 組織專案團隊，承諾專案開發，回顧專案過程，總結專案經驗教訓，組織每日站會，制定 Sprint 計劃。
• Facilitate everything and eventually retire，留下一個自組織團隊，悄然離去，深藏功與名。激勵團隊，coach，team lead，life tutor。
• Scrum Master 應該是作為團隊初步接觸敏捷時作為流程與套路教授和規範。在團隊逐步成熟後，Scrum Master 的職責可以旁落，而專職 Scrum Master 可以取消。

那麼敏捷教練的職責到底是什麼呢？

《敏捷教練》一書的作者之一，瑞秋·戴維斯（Rachel Davies）對敏捷教練的觀點：

概括地說，敏捷教練幫助團隊在工作中應用敏捷實踐，從而幫助團隊發展的更健壯。接受這些變化需要時間，所以沒法通過“點到即止”的方法立即讓它們生效。你需要與團隊長時間呆在一起，並幫他們，讓他們更加關注工作流程、關注如何更有效地協作。你對團隊的目標是在你離開後，讓他們能“自我指導”並且擅長應用敏捷。這樣不會限制敏捷教練向組織引進敏捷，以及建立新敏捷團隊。

< Coaching Agile Teams > 的作者 Lyssa Adkins 對敏捷教練的觀點：

敏捷教練確實非常重要，因為現在有許多人在運用一堆蹩腳的敏捷工作方式。即使運用了，它們只是更快地產出了平庸的結果，我知道，那並不是他們運用所謂“敏捷”工作方式的主要意圖。我認為教練是幫助團隊取得驚人成果所不可或缺的組成部分，因為所有的成果都是人互相互動所產生的。敏捷框架中沒有說明如何處理人與人互動的部分。為了使敏捷框架良好運作，它當然會提供可讓其正常執行的結構和容器。但是在敏捷框架之外，還有很多事情要做，還有很多東西需要帶給團隊，針對不同的規則，需要給團隊很多建議——如衝突管理、敏捷促進、教導及指引人、專業指導等等。

本文給出的敏捷教練的職責定義是：

• 貫徹一種工作方式，包括精益、敏捷和系統思考。
• 打造自組織團隊，特別是要面對人（包括自我與他人）這個最複雜的實體。
• 以此來消除浪費，增加價值，達到組織的目標。

要履行這些職責，需要理解敏捷，這是本課程基本功的儲備部分；要能夠在組織中用敏捷影響他人，這是基本功中技能的部分；要體會真實環境中的敏捷運用，這是本課程基本功中的實戰部分。

體系化的參考書目

敏捷是敏捷教練的程式碼

敏捷的歷史是一場不斷追求更好的歷史，在這個過程中，先行者們為我們留下了眾多可供參考和讓我們無須重新發明輪子的書籍。

本節以類庫、框架、架構，和編輯、編譯、連結、執行的視角解析敏捷和敏捷教練，以及如何運用先行者們留下的書籍。

敏捷是一種程式碼，2001年2月，17人在美國猶他州的雪鳥滑雪場，解碼和發明了這門語言，並貢獻了敏捷基礎類庫。

敏捷基礎類庫

• Kent Beck 等的 （《敏捷宣言》）。

敏捷框架類庫

• Jeff Sutherland & Ken Schwaber
• Kent Beck （《擁抱變化：解析極限程式設計》）
• Mike Cohn （《使用者故事與敏捷方法》）（《敏捷估算與規劃》）
• David Anderson （《看板方法》）
• Mary Poppendieck （《精益軟體開發》）
• Craig Larman 的 Large Scale Scrum
• Dean Leffingwell 的 SAFe

敏捷擴充套件類庫

• 野中鬱次郎和竹內巨集高《新的新產品開發遊戲》《場理論》
• Henrik Kniberg （《硝煙中的 Scrum 和 XP 》）
• Kenny Rubin （《Scrum 精髓》）
• Jeff Patton （《使用者故事地圖》）
• Mitch Lacey （《Scrum 實戰指南》）
• Ken Schwaber （《Scrum 敏捷專案管理》）
• Mike Cohn （《Scrum 敏捷軟體開發》）
• Eric Ries （《精益創業》）
• Ellen Gottesdiener
• Jezz Humble （《持續交付》）
• 《戴明14條》
• 艾永亮《騰訊之道》
• 何勉《精益產品開發原則、方法與實施》

精益類庫

• 大野耐一 《豐田生產方式》《現場管理》
• 新鄉重夫《從 IE 的角度看豐田生產方式》
• James Womack （《改變世界的機器》）（《精益思想》）
• Jeffery Liker （《豐田模式》）系列
• John Shook （A3 報告）（價值流圖）

引導與心理學類庫

• NLP 神經語言程式
• 世界咖啡
• 六頂思考帽
• 管理與變革類庫

Chip & Dan Heath （《瞬變》）
Jurgen Appelo

敏捷模式類庫

• Scrum 本身就是個模式
• 《使用者故事地圖》也是模式
• Linda Rising
• 本課程中的 Scrum 子模式，例如故事泳道、一人天任務、隨機一分鐘專案經理。

敏捷教練方法類庫

• Lyssa Adkins

修身類庫

• 《大學》《中庸》《論語》《孟子》
• 《王陽明全集》
• 《心經》《金剛經》
• 《聖經》
• 阿德勒《超越自卑》
• 《人生五大問題》
• 斯蒂芬柯維《七個習慣》
• 《紅與黑》
• 《基督山伯爵》
• 《悲慘世界》
• 《百年孤獨》
• 《活著》
• 《常識》

而在設計敏捷工作方法的架構時，可以基於上面提到的敏捷框架中的一個或多個。可以使用的思維線索有：

• 軟體開發的階段：概念，機會，策略，需求，方案，計劃，實施，驗證，部署，維護，退役。
• PDCA
• 5W2H

在做敏捷工作方法的實施時，第一步是需求：

• 與關鍵人員交流，瞭解問題與目標
• 這一步要放下敏捷的程式碼，傾聽了解問題與目標本身。

第二步是制定解決方案：

• 根據現狀，參考敏捷方法，制定關鍵舉措。
• 使用類庫和框架，制定架構。

敏捷工作方法的編碼就是用上面的各種類庫和框架，生成適合組織和團隊的可執行的敏捷方法，包括架構和詳細實現。執行的環境是團隊中每個人的大腦。

編輯，是把方案細化的過程：

• 把敏捷方法動作化，做好劇本。無劇本，不操作。
• 為每一次談話做好充分準備。

編譯，是與團隊中所有人交流的過程，使所有人理解敏捷方法：

• 可以是討論，針對某個具體變化的方案與執行。
• 可以是培訓，介紹整體或某個環節的工作方法。
• 可以是一對一交流，讓方法切實而不只是形式上發生。

連結，是處理與現狀和與已有工作方法的衝突：

• 分析問題，解決問題。
• 調整“程式碼”

執行，是新方法的執行：

• 落實每一個動作，並檢查調整。

編輯、編譯、連結、執行會反覆多次進行，跟程式設計師寫程式碼沒有區別。

敏捷教練和 ScrumMaster 的基本功，來自於眾多大師的智慧和作者的實踐，為我們提供了擴充套件的大腦。該體系已為您整理好，是按下繼續前進按鈕的時候了

第02課：儲備-Scrum 精要

介紹 Scrum 的書雖然還沒有達到汗牛充棟的程度，但已經是著作等身了——所有著作加起來能夠等同於一個人的身高了。本文並不是對 Scrum 理論的簡單重複，而是立意能做到兩點：

• 涵蓋 Scrum 中所有重要的概念。
• 所介紹的方法達到說明書的程度，拿過去就能用。

敏捷產生的歷史背景

首先簡要談一下敏捷產生的歷史背景，以及由 Scrum 及其眾多兄弟方法共同抽象出的敏捷宣言。

敏捷產生的歷史背景，在於世界變化越來越快。人們不斷產生更多更新的需求，技術因此不斷進步，兩者交相輝映，使得變化越來越快。

以通訊行業為例，從 1G 到 5G 呈現出一種升級越來越快的狀態。

1986年，作為 1G 標誌的使用模擬訊號的世界上第一套移動通訊系統在美國芝加哥誕生。

1995年，諾基亞崛起，進入數字調製的 2G 時代。

2009年左右，CDMA 大行其道，進入資料傳輸速率更高的 3G 時代。

2013年左右，伴隨移動網際網路，行動通訊進入網速更高的 4G 時代。

最近一兩年，隨著 AR、VR、車聯網、物聯網的誕生，5G 的商用化指日可待。

在這種變化越來越快的環境之下，傳統的軟體開發方法不再奏效。敏捷先驅們開始探索一些新的方法，對豐田生產方式、組織模式等進行了大量學習，發明了 Scrum、XP 等各種方法論。2001年，新方法論的創始人們聚首一堂，總結了各家方法論的共同點，提出了敏捷軟體開發宣言。

敏捷宣言有4個價值觀和12個原則，它們也是 Scrum 的基礎。對4個價值觀要能夠背誦下來，對12個原則也要熟悉，以便達到遇到實踐情況時能容易對照的目的。我們為您精製了手繪版的敏捷宣言價值觀和原則，可以列印張貼備查。

敏捷軟體開發宣言

enter image description here

我們一直在實踐中探尋更好的軟體開發方法，身體力行的同時也幫助他人。由此我們建立了如下價值觀：

• 個體和互動 > 流程和工具
• 工作的軟體 > 詳盡的文件
• 客戶合作 > 合同談判
• 響應變化 > 遵循計劃

也就是說，儘管右項有其價值，我們更重視左項的價值。

敏捷宣言遵循的原則

• 我們最重要的目標，是通過持續不斷地及早交付有價值的軟體使客戶滿意。
• 欣然面對需求變化，即使在開發後期也一樣。為了客戶的競爭優勢，敏捷過程掌控變化。
• 經常地交付可工作的軟體，相隔幾星期或一兩個月，傾向於採取較短的週期。
• 業務人員和開發人員必須相互合作，專案中的每一天都不例外。
• 激發個體的鬥志，以他們為核心搭建專案。提供所需的環境和支援，輔以信任，從而達成目標。
• 不論團隊內外，傳遞資訊效果最好效率也最高的方式是面對面的交談。
• 可工作的軟體是進度的首要度量標準。
• 敏捷過程倡導可持續開發。責任人、開發人員和使用者要能夠共同維持其步調穩定延續。
• 堅持不懈地追求技術卓越和良好設計，敏捷能力由此增強。
• 以簡潔為本，它是極力減少不必要工作量的藝術。
• 最好的架構、需求和設計出自自組織團隊。
• 團隊定期地反思如何能提高成效，並依此調整自身的舉止表現。

Scrum 方法論

我們力求把方法論介紹到可操作的程度。

從方便理解和記憶的角度，Scrum 方法論可以被概括為3355

3個角色

• PO（產品負責人）
• SM（Scrum Master）
• 團隊成員。

3個物件

• Product Backlog（產品列表）
• Sprint Backlog（迭代列表）
• Product Increment（產品增量）

5個會議

• Product Backlog Grooming （產品列表精化）
• Sprint Planning（迭代計劃會）
• Daily Stand（每日站會）
• Spring Review （迭代評審會）
• Sprint Retrospective（迭代回顧會）

5個價值觀

勇氣，承諾，專注，開放，尊重。

Scrum 由上述四種要素及背後的規則粘合起來。

3個角色各有擔當又通力合作。 3個簡單的物件統攝產品層面與迭代層面的交付物。 5個會議貫通產品層面與迭代層面的計劃與執行活動。 5個價值觀作為方法論的一部分，體現了 Scrum 以價值觀為方法論的特色。

3個角色的職責

Scrum Master 的職責最難講得清楚。有一個思路是參照卡諾模型。日本教授把產品需求分為三類：

• 必備型需求：這類需求沒有滿足，客戶不會購買這個產品。
• 多多益善型需求：這類需求的實現程度與客戶付錢的願望呈線性關係。
• 喜出望外型需求：這類需求是區別於競爭產品的分水嶺，客戶願意付出溢價。

按照這個思路，我們可以把 Scrum Master 的職責分為三類：

• 必備型職責：協助管理 Scrum 的3個物件和5個會議。
  
  • 多多益善型職責：與各方溝通和協調問題解決。
  • 喜出望外型職責：系統思考，發現流程和團隊工作中的改善點，並推動改善。

產品負責人職責

管好產品列表。理解了什麼是好的產品列表，也就理解了產品負責人的職責。後面會講產品列表。

團隊職責

與傳統團隊職責不太一樣的主要有兩點：

• 跨職能：個人不一定是全能的，但團隊要是全能的，具備把產品列表變成產品增量的全部技能。團隊成員之間，不受角色和頭銜的制約，只要具備能力，每個人都可以認領所有任務。
• 自組織：團隊自行決定自己的工作方式，只要團隊有共識。原則上是全員參與估算和計劃，全員進行專案進度的監控和調整。

在現實的團隊中，有專職人員，也可能有浮動人員，不管是專職人員還是浮動人員，幾個共同的基礎是：自動化與及時化，每個人都做好本職工作，彼此之間良好配合；每個人都理解團隊的產品目標和迭代目標；每個人都瞭解團隊的工作方式和節拍。

浮動人員的類別

一類浮動人員，例如架構師和設計師，有全域性影響，但又不是全職參與。有兩種變通的參與方式，一是跟專職人員一樣，參加 Scrum 會議，二是在團隊中指定他的影子，與他密切協作保證他能及時貢獻到團隊的目標。

二類浮動人員，如固定在兩個團隊之間共享的測試人員。

1. 減少共享的人數，儘量把測試人員固定在其中一個團隊；
2. 由有能力多工的資深人員在兩個團隊之間浮動領任務，以緩解對其他人員的共享需要；
3. 在極端情況下，才讓（1）中的人員也在兩個團隊之間浮動。

三類浮動人員，如在一段時間之內有部分時間花在該 Scrum 團隊的人員。與一類浮動人員相比，這類人員的全域性影響相對小，更多是因為技能或資源問題而導致的安排。其變通的參與方式與一類浮動人員類似。

四類浮動人員，如尚不能獨立工作的新員工。變通的方法是由其導師協助領取任務。

團隊之要

• 在 Scrum Master 的引導和輔導下理解 Scrum 框架，特別是從事情角度的嚴密的 PDCA 迴圈，和從人的角度的緊密合作。
• 以嚴密的紀律性使 Scrum 能良好運轉，達成業務上的目標，並收穫高效快樂的團隊。
• 在紀律的支撐之下，技術上精益求精，更好地發揮創造性，包括在技術領域，並適當參與產品探索領域。

Team 在 Scrum 中的活動

• 梳理
• 計劃
• 執行
• 每日檢查和適應
• 迭代檢查和適應（評審與回顧）

Team 特徵

• 自組織：自組織不能來自命令與控制，而是簡單規則支援下的群遊。
• 跨職能團隊：多樣性，跨職能，不同背景，不同的思考角度，造就更好的產出，更快更好的解決方案、更棒的創新。
• 一專多能
• 火槍手精神（互助）
• 寬頻寬溝通（溝通頻寬遞減：面對面 > 電話 > 即時訊息 > 郵件）
• 透明
• 團隊大小5~9人
• 專注與承諾
• 可持續步伐
• 長期穩定的團隊

3個物件

產品列表（Product Backlog）是產品列表項（Product Backlog Item，簡稱PBI）的列表。PBI 包括特性、故障、技術工作和知識學習。

好的產品列表要滿足 DEEP 原則：

• Detailed Appropriately 細節得當。越是馬上要做的 PBI，越是要有足夠的細節。很久以後才做的，可以粗略一點。
• Emergent 湧現式的。PBI 可以根據實際情況隨時插入。
• Estimated 有估算的。同樣是近期要做的 PBI，估算要較精細，可以採用費波納契序列的故事點估算，即1，2，3，5，8 …對於遠期要做的 PBI，估算可以粗略，可以採用粗略的T恤尺寸估算，即 XS，S，M，L，XL 等。
• Prioritized 排好優先順序的。近期要釋出版本中的 PBI 的優先順序要明確排列，中期的可粗略排列，遠期的可不必排列。

迭代列表由從產品列表中選出當前迭代要完成的 PBI，及由 PBI 分解產生的任務構成。對於任務的估算，可以採用天或小時估算，也可以不估算。採用哪種方式，以團隊能夠做出靠譜的迭代承諾，以及在迭代工作的每一天方便監測趨勢為標準。

產品增量是一個迭代結束時，輸出的使用者可用的新功能。產品增量要達到潛在可交付狀態，即如果使用者需要，可以快速部署給使用者使用。

5個價值觀

5個價值觀的落實與否，是 Scrum 團隊形成的重要標誌。

對於5個價值觀的運用，可以由團隊一起討論，每個價值觀分別意味著什麼，並進而把價值觀轉化為可執行的團隊規範。利用迭代回顧會議，審視團隊規範的執行情況。

5個會議

對於5個會議，主要講述每個會議的目的、流程和輔助物。

產品列表精化會

目的：準備好。準備好的意思是，經過精化，PBI 達到可估算可計劃和可執行的狀態。開發人員可以對之進行開發工作了。

流程：

主要是圍繞 DEEP 標準

• 細節得當。產品負責人講解每個 PBI，達到團隊成員理解需求的程度。
• 湧現式。在精化的過程中，根據產品負責人與團隊的互動，可能會產生新的 PBI。
• 估算。在產品負責人講完每個 PBI 時，團隊可以用估算紙牌進行估算。通過紙牌對話，也可以保證每位團隊成員都理解了需求。
• 優先順序。優先順序主要由產品負責人排列，但團隊的估算和實現的難易程度，也會影響產品負責人重新考慮優先順序的排列。

輔助物件：

為了保證產品列表精化達到準備好的標準，可以制定一個叫做準備好的定義（Definition of Ready，簡稱DoR）的檢查列表。DoR 列表示例如下：

• 業務價值清晰。
• 團隊瞭解需求細節，能夠做出是否能完成的決定。
• 依賴被清楚地識別和管理，沒有妨礙完成 PBI 的依賴。
• 團隊具備完成 PBI 的技能。
• PBI 被估算，並且足夠小，能夠裝到一個迭代裡。
• 驗收標準清晰和可測試。
• 效能指標清晰和可測試。
• 團隊知道在完成後如何演示。

迭代計劃會

目的：在計劃會結束時，給出靠譜的迭代承諾。

流程：

• 產品負責人建議迭代目標和要完成的 PBI。
• 團隊把 PBI 分解成任務。
• 團隊決定是在計劃會上就把所有任務分配到個人，還是在迭代過程中動態分配。分配的方式是團隊成員認領。要不要分配的標準是，團隊是否能- 對迭代計劃進行承諾。
• 評估計劃的工作量與團隊容量是否平衡。
• 從迭代計劃中提煉出迭代目標，把 PBI 粘合在一起，把團隊團結在一起。
• 團隊對迭代目標和計劃進行承諾。

輔助物件：

為了對完成有統一的標準，需要完成的定義（Definition of Done，簡稱DoD）檢查列表。DoD 檢查列表示例如下：

• 設計有評審。
• 程式碼完成，包括：程式碼有重構，程式碼符合標準，有註釋，有簽入，有評審。
• 使用者文件更新。
• 測試完成，包括：單元測試，整合測試，迴歸測試，平臺測試，語言測試等。
• 零已知故障。
• 驗收測試完成。
• 部署到生產環境。

可以用 A1 紙和便利貼輔助計劃會議：

Scrum 的兩個要點是：人的有效參與，做事的有效軌道。這個計劃會的設計，是以有效的軌道輔助人的主動參與。

貼出一張 A1 大白紙。

左邊第一列是故事，由 PO 用同一種顏色的便利貼書寫和表達。字要大，用白板筆寫，保證不用站得很近也能看清楚。故障，新特性或任何要交付的事情統稱故事。

故事右邊，用另一種顏色的便利貼列出任務。任務是為完成故事所要做的事，由團隊書寫。可以寫上任務的執行人與估算。

整個會議，一次圍繞一個焦點，即當前討論的故事。以故事為單位流動起來。

PO 的注意事項：清晰講述。隨著會議的焦點流動，把故事講得讓團隊明白。

SM 的注意事項：適度引導。控制焦點與流動，一個故事充分討論完並分解成任務，再進行下一個。保持緊湊的節奏和整體時間盒。

團隊注意事項：主動參與。一是對故事不清楚的主動提問，而是主動參與任務分解、估算、認領。

全部故事討論完和分解成任務後，統計每人工作量，看工作量與容量是否平衡，個人之間工作是否能置換以達到每個人的工作相對均衡。

最後是團隊決定是否能對迭代計劃和目標承諾。

每日站會

目的：圍繞目標同步進度，掌握對於完成目標的趨勢。

流程：

• 準時開始。每天固定時間和地點。
• 每人回答三個問題：為了幫助團隊達到迭代目標，昨天完成了什麼，今天打算完成什麼，遇到了什麼障礙。
• 總結趨勢和風險。
• 15分鐘之內結束。

站會中細顆粒度的協作：

• 利用站會，促進細顆粒度協作。
• 故事和任務拉動按優先順序進行。
• 需要協作的任務，其所有者勇於發起協作請求。
• 被請求者以協作的任務先於本人可獨立承擔的任務進行。
• 在回顧會議中明確討論該模式，並貫徹。
• 模式可以由任何一人發現。

關於站會中的發散討論：

• 站會中發散討論的度以全部團隊成員覺得爽為標準。
• 15分鐘時間盒不必嚴格遵守。
• Scrum Master 需要對站會之後團隊成員的日程有了解，以便判斷站會延長一點是否產生影響。
• Scrum Master 可以觀察對於發散討論是否全部或大部分團隊成員沉浸其中，如果是，暫不打斷。
• 如果出現較多分神現象，打斷討論，並提議會後安排討論。
• 或者根據站會的剩餘時間，詢問團隊，這種發散的討論是否會影響團隊成員的後續日程。
• 按以上原則，打斷可以由任何一人提出。
• 在回顧會議明確探討這種情景中的模式。

迭代評審會

目的：瞭解過去一個迭代完成了什麼，並對下一步做出預測。

流程：

• 產品負責人邀請客戶和干係人蔘與。
• 團隊總結過去一個迭代的成就和克服的挑戰。
• 團隊演示完成的產品，獲得反饋。
• 產品負責人分享來自使用者和市場的資訊，預測調整發布計劃，預測下一
  迭代的內容。

迭代回顧會

目的：團隊建設，發掘和計劃改善。

流程：

• 基調：真誠和有效。排除顧慮，真誠表達。提出有效的問題，落實有效的方案。
• 白板上寫兩個欄目：感謝，改善。
• 每人（包括 PO 和 Scrum Master）用 Post It 寫出要感謝的人，每張 Post It 寫一個，數量不限。寫完貼在白板。
• 每人（包括 PO 和 Scrum Master）用 Post It 寫一個最痛的改善點，只寫一個就好。寫完貼出來。
• Scrum Master 無需太多發言，只需起一個指標的作用。先從感謝的紙條開始，一張一張拿出來問是誰寫的，寫的人面向要感謝的人表達感謝，不能太空洞，要談一下感謝的內容。
• 然後轉向改善欄目，Scrum Master 同樣不要多說話，一張一張拿起紙條，讓寫的人講，其他人可以參與討論，這個環節焦點放在問題澄清，而不是解決方案，Scrum Master 對這一點要有一定把控。
• 每張紙條講完後，所有人當場舉手或豎大拇指，表達的是認為這個問題是否要儘快即在下一迭代解決。
• 全部問題澄清後，全體針對要解決的問題，討論方案。Scrum Master 關注一下討論的流動情況，既不要太亂，也不要冷場。極端情況下，可以點名讓大家逐一發言，但儘量不用這一招。
• 產生的方案，形成改善 Backlog。Scrum Master 要跟蹤起來，可以在日常或站會中跟蹤落實情況。

Scrum Master 要觀察團隊互動中的互動情況，如果有分歧點，就是改善點。比如說在 Demo 中，PO 對驗收標準的理解與團隊不一致。這就是需要改善的地方。改善的討論和進行，可以在日常與相關人員討論，也可以放到回顧會議。

除了團隊的回顧會議，還可以有一對一的回顧會議：

• 一對一 Retrospective 是對團隊 Retrospective 的鼓勵和馴化。是為了幫助打磨團隊 Retrospective。
• 一對一 Retrospective 是對團隊 Retrospective 的補充。即使團隊 Retrospective 已經搞得很好了，也還需要一對一 Retrospective。
• 一對一 Retrospective 可以由 Scrum Master 發起，也可以由任何人向任何人發起。
• 一對一 Retrospective 的目的，是加強人與人之間的連線，傳遞改善的信念，和計劃和執行改善。
• 一對一 Retrospective 的邊界，是圍繞改善的基調，就與團隊專案工作相關的事進行討論。
• 一對一 Retrospective 的框架，可以包含探詢交流物件對工作方式的反饋、探詢痛點和關注的問題，和以 Scrum 實踐和角色要求為基準、以觀察到的行為為依據向交流物件提供的反饋。還可以包含不同團隊之間的經驗傳遞、橋樑和延展。
• 如果希望痛點和問題的探詢更封閉一點，可以分解為幾個角度：就團隊專案工作的上下文而言，您的目標和期望的理想狀態是什麼？與現狀的差距是什麼？流程上有什麼問題，或有什麼妨礙理想狀態的達到？團隊合作方面呢？團隊工作績效和質量呢？任何其他方面？
• 這個框架的運用要靈活。人的主動參與重於規則。如果人能主動參與改善事項的發掘、計劃和行動，框架就可以放下。
• Scrum Master 日常有力的觀察是 Retrospective 的重要輸入。
• 各個角色的普適標準：專業、尊重、堅持。
• 改變的第一原則：一切改變基於自願。改善的用意是改善系統，不是改變個人。

最後用十論 Scrum 就是知行合一對 Scrum 作個小結：

1. 人人知行合一：人人計劃，人人行動。
2. 時時知行合一：時時計劃，時時行動。
3. 團隊知行合一：團隊決定，團隊行動。
4. 敏捷知行合一：快速決定，快速行動。
5. 需求知行合一：接近客戶，掌握需求。
6. 支柱知行合一：檢驗是知，適應是行。
7. 完成知行合一：定義完成，共識目標。
8. 透明知行合一：高度透明，流暢過程。
9. 紀律知行合一：自我紀律，助長能力。
10. 美德知行合一：積極主動，集思廣益。

本章首先介紹了敏捷宣言，然後按3355框架介紹了 Scrum 中最核心的東西。下一章介紹伴隨 Scrum 的一個重要物件——使用者故事。

下一篇

課程內容

作者撰寫中…

作者撰寫中…

作者撰寫中…

作者撰寫中…

作者撰寫中…

作者撰寫中…