如何評價《敏捷革命》（Scrum）一書？

01-09

中文譯本，（美）傑夫 · 薩瑟蘭：《敏捷革命》（Scrum: The Art of Doing Twice the Work in Half the Time）（蔣宗強譯），中信出版社，2017。
英文原版，Jeff Sutherland (2014). Scrum: The Art of Doing Twice the Work in Half the Time. Crown Business.

不知道書名為啥要譯成「敏捷革命」？又不是《Agile Revolution》，明明是：

《Scrum：時半功倍的藝術》

革命與藝術，定位顯著不同。

這是引領時代，吹響革命的集結號？

Dr. Sutherland 好像一直是個比較低調的人。

為了促銷可以理解，但這麼拔高有點不好吧。

我明確反對搞什麼敏捷革命。

一句話評價：
目前市面上最好的敏捷方法入門書。

以上，是對問題的極簡回答。

以下，是對問題的極繁回答。

§ 零、目錄

一、本書與作者：版本介紹、閱讀建議、作者背景。

二、Scrum Wiki：Scrum 的詞源、術語和「敏捷方法」簡介；

三、時間和「溝通飽和度」：「敏捷方法」得以發展的兩個關鍵考量；

四、對症下藥：挖掘時間和「溝通飽和度」潛力的諸多對策。

§ 一、本書與作者

? 關於本書

?▲ 《敏捷革命》

圖片來源：亞馬遜（離線 Offline 薦書模板）

中文譯本的翻譯質量很胖胖，加之這是一本定位於呈現「敏捷方法」發展歷程的書，所以沒有特別的必要去看英文原版。

時間不夠的話，可以只看每一章的「本章要點」和「附錄：Scrum 實踐步驟」。

時間足夠的，可以看完這本，再看看埃里克·施密特、喬納森·羅森伯格：《重新定義公司：谷歌是如何運營的》（How Google Works）（靳婷婷譯），中信出版社，2015。從谷歌的行事方式中，能看到不少「敏捷方法」的影子

傑夫 · 薩瑟蘭 2014 年在谷歌倫敦辦公室的講演：
Dr Jeff Sutherland: Scrum | Talks at Google - YouTube

? 關於作者

傑夫 ? 薩瑟蘭（Jeff Sutherland），「敏捷軟體開發」的創始人之一（另一位是肯 ? 施瓦布，Ken Schwaber），Scrum Inc. 的 CEO。

軍隊生涯：畢業於「西點軍校」（美國陸軍軍官學院），隨後參加了越戰，前往泰國北部的烏隆皇家空軍基地做了當時最危險的「偵查」工作，並且幸運地活了下來（註：按照書中的說法，飛機被擊落的概率為 50%）。

學術生涯：越戰結束後，到斯坦福大學攻讀統計學碩士學位。畢業後，到美國空軍學院教授數學、統計學和概率論。後來，又去了科羅拉多大學醫學院攻讀生物統計學博士學位，研究癌症。

IT / 商界生涯：以「敏捷」（Scrum）為事業（笑。

▲ Jeff Sutherland

圖片來源：Yahoo Finance（Accessed, 2017-07-16）

§ 二、Scrum Wiki

Scrum 詞源：「這個詞語原本是橄欖球運動的一個專業術語，原意為團隊通力合作，在場地內傳球。這個過程需要認真配合、信念一致和目標明確。這個過程完美體現了我對一個團隊的所有要求。因此，我把這種敏捷開發流程命名為 Scrum」（P9-10，下文涉及《敏捷革命》一書的引文，均只標註頁碼）。

Scrum:

[C] a part of a game of → RUGBY when the players all push together in a circle, with their heads down, and try to get the ball
? 並列爭球〔橄欖球賽中球員的一種隊形排列〕
—— Cite from Longman Contemporary English Dictionary 3rd edition.

Scrum 術語：2011 年初，作者和另外的 16 位軟體開發領域內的領軍人物，在美國猶他州雪鳥滑雪聖地的一場秘密會議上，擬定了眾所周知的《敏捷軟體開發宣言》，Scrum 一詞由此正式成為術語（註：不過在此之前，Scrum 其實就有所起源啦，有興趣的可以簡單看看「Scrum」的 Wiki 詞條，了解一下）。

Scrum 方法：簡單說，就是以交付與迭代為核心的方法（註：會包含著確定優先順序、最小化可行產品 MVP、獲取反饋、調整優化等要素）。「每過一小段時間就停一停手頭的工作，檢查一下已經完成了哪些任務，看看這些任務是不是自己應該做的，看看有沒有更好的方法」（P25）。

一個親民的解釋：
張小龍在微信領導力大會上談到：「關於敏捷管理，我特別希望大家能夠多去做一些嘗試，我們今天可以想一些與眾不同的點子。我們很快把它上線了，然後可以去驗證，如果不對就下線，如果還有改進餘地，下個星期再去改它。這是一個能夠持續實現你的想法的過程。」
——《張小龍推崇的敏捷管理法到底好在哪兒》—零壹財經

?▲ The Scrum Process（Software）：產品待辦-衝刺待辦-衝刺（循環）-軟體增量開發

圖片來源：By Lakeworks - Own work, GFDL, Wikipedia（Accessed, 2017-07-17）

§ 三、時間和「溝通飽和度」

我個人的看法是：「敏捷方法」改進「瀑布方法」的關鍵之處在於，對如下兩個概念做了更準確的理解。

「這種架構之所以奏效，原因很簡單，因為我看到的是人們實際上怎麼工作的，而不是他們嘴上宣稱自己是如何工作的」（P9）。
——傑夫 ? 薩瑟蘭

① 時間

比如說，在一段時間內，人們實際上怎麼工作的呢？常常是，這樣的：

?▲ 論我們如何完成一項工作

圖片來源：約翰?佩里：《拖拉一點也無妨》（蘇西譯），封面

人是理性的動物——亞里士多德；
人不是理性的動物，而是會為自己找合理借口的動物——羅伯特 ? 海因萊因；
人是理性的動物，但在需要聽從理性的命令時，卻常常大發脾氣——奧斯卡 ? 王爾德；
有人說，人是理性的動物。我這一輩子都在尋找能證明此言非虛的證據——伯特蘭 ? 羅素。
——約翰?佩里：《拖拉一點也無妨》。

又比如說，人們實際上又喜歡什麼樣的工作感覺呢？常常是，這樣的：

大家都渴望那種「運籌帷幄；玩弄天下於鼓掌之中」的暢快感，而不是「走一步，看一步」的委屈感；
大家都享受那種 DDL 尚未來臨前「放飛自我」的感覺，「哎呀，我在準備呢，還有半年，急什麼急，真是的！」，而不是每兩周 / 一個月就要被任務「追著屁股跑」的感覺；
大家都喜歡那種「條件在手，宇宙我有」的感覺，「這個問題，還要做用戶調研？我動動腳趾頭都能想出來，你信不信？昂？！」，而不是因果關係往往靠猜的不確定感，「鬼知道用戶們在想什麼！」。

但「敏捷方法」卻不會給你製造「幻覺」的機會，「在 Scrum 中，每個衝刺周期結束之際，都必須為顧客展示一些看得見、摸得著的新價值。你可以問顧客一些問題，比如，這是你想要的嗎？這能幫你解決一些問題嗎？我們的方向是對的嗎？如果答案是否定的，那麼你就要修改你的計划了」（P132）。

② 溝通飽和度

幹活兒要信息，要干好活兒要足夠充分的信息。

溝通渠道：假設一個團隊的人數是 N，那麼溝通渠道有多少呢？N（N-1）/2，5 個人對應 10 條渠道；6 個人對應 15 條渠道；7 個人對應 21 條渠道……隨著團隊成員的增加，溝通渠道會大幅增加，最終帶來的問題 / 風險（很可能）是大家根本無從知道別人是負責什麼的，正在做什麼（同學，你體會過為了查一個 Bug，找了 8 個聯繫人的絕望么？）。

另一種 ? 不可替代性：「如果一個人有某個特定的頭銜，那麼他就傾向於只做與該頭銜匹配的事情，而且會想方設法維護該頭銜賦予他的權力，他往往會把特定的知識隱藏起來，不與團隊其他成員分享」（P87）。這種傾向造就了所謂的「另一種 ? 不可替代性」，也造就了一部分「解決一分鐘，溝通五小時」的悲壯情景。

丟猴子（注 1）：當管理者為了建立「另一種 ? 不可替代性」，而不願與他人分享必要的知識和信息時，除了會降低「溝通飽和度」，單向拖延別人行動外，麻煩也會像「迴旋鏢」一樣飛回來。為什麼會這樣呢？察覺到這一點的人，一般也不傻，不會任人魚肉的。在信息完全不充分或根本沒信息可參考時，他們就會把這些自己無能為力的決策任務丟回去，「既然只有你知道，你不做誰做？」。

?▲ Monkey on Your Back

圖片來源：Manage Your Monkeys Well. It』s No Jungle Out There - Wingd（Accessed, 2017-08-03）

對團隊來說，當「溝通飽和度」不高時，想要高效率地搞定開發任務，就會成為笑話。這就好比，當辦公室的路由器不給力的時候，你還想幹活兒？

「喬納森剛入職谷歌不久，有一次與我們的一位工程師聊天。喬納森習慣一接到電子郵件就立馬回復，還會把回復內容抄送給許多谷歌員工。對於喬納森的這個習慣，這位工程人員有些疑慮。他認為，這種做法是捨本逐末，而且郵件回復得如此勤快、傳播信息量如此之大的人，手邊必定有大把餘閒。因此，他憤然對喬納森說：「你只是一台昂貴的路由器！」路由器是非常基礎的網路設備，主要用來在不同的點之間進行信息包傳輸，因此，這句話本是帶有侮辱性的。但是，喬納森卻將這句帶刺的話當成了讚美。」
——埃里克·施密特、喬納森·羅森伯格：《重新定義公司：谷歌是如何運營的》。

注 1：這個概念是我借用的。詳見，《解放時間：誰背著猴子？》（Management Time: Who" s Got the Monkey?），哈佛商業評論：《戒掉你的「工作癮」》（《哈佛商業評論》增刊），浙江出版集團數字傳媒有限公司，2017。

§ 四、對症下藥

從前述針對時間和「溝通飽和度」的種種（可能）問題出發，「敏捷方法」發展出了一系列改進的對策。和其他管理方式不同的是，這些對策並不僅僅是指導思想（所謂「道」），更是直接變身 / 催生了「敏捷開發」的種種要素（所謂「術」）。

?▲ The Agile: Scrum Framework at a Glance（敏捷框架：衝刺-每日立會-檢查與回顧）

圖片來源：Scrum for Beginners - SlideShare（Accessed, 2017-08-03）

① 挖掘「時間」的潛力

1. 衝刺周期（對應 Sprint Circle）：以周期性來理解時間，以時間的限制來激發行動力。

2. 確定優先順序：資源有限，先做效益最好的「頭部待辦事項」。「在產品開發中，有一條反覆得到證明的鐵律，即一個產品 80% 的價值來自 20% 的功能」。如此重複，最終在確保方向正確的前提下，交付出最好的產品。

?▲ 提升價值：交付最好的產品

圖片來源：《敏捷革命》，P214。

3. 不要同時執行多項任務：避免陷入注意力的陷阱。

?▲ 項目優先順序

圖片來源：《敏捷革命》，P104。

4. 不要拖，馬上做：（這一點最後又會影響整體的溝通飽和度）。

5. 不要加班：「但是為何一個人工時減少，卻能做更多事情呢？表面上看起來毫無道理。馬克斯韋爾表示，工作時間太長的人會開始犯錯，正如我們先前提到的那樣，改正錯誤可能會比創造新成績花費更多的時間。工作超出負荷的員工比較不容易集中注意力，而且會影響別人也跟著分心，不久之後他們就會開始做出錯誤決策」（P116）。

② 挖掘「溝通飽和度」的潛力

1. 小而精的團隊：招聘那些「超越尋常」的人，組建一個優秀的團隊，降低溝通的難度；同時將核心團隊的規模控制在 7 ± 2 以內，讓溝通渠道數量保持在可接受的範圍（注 2）。

2. 多功能的團隊：瘸子走不遠，麻雀飛得快。

3. 忘掉頭銜：摘掉阻礙信息流動和成員自主權的「頭銜」，儘可能地保持透明度。

4. 每日立會：「每天在同一時間召開，詢問那三個問題，每個人都站著，而且開會時間不超過 15 分鐘」（注 3）。通過這種集體參加的小會，來溝通各自工作進展情況，同時以集體智慧去解決那些個人短時間內難以解決的問題（註：有時候 A 覺得很難解決的問題，在 B 那裡可能就是很好解決的問題，但前提是，B 得知道 A 遇到了這個問題；有時候，困難問題的解決可能需要藉助於並不在公司內部流通的「場外信息」）。

5. 一些奇技淫巧：比如刻意修上一個長長的走廊，綜合性的休息室，緊湊的、無隔斷的工作區等等，為員工的「偶遇」製造機會。

③ 流程の潤滑劑

1. Scrum 主管：安排一位能夠確保整個工作流程順利推進的人。「他的工作職責就是召集會議，確保團隊運作過程的透明度，而且，最重要的是，幫助團隊發現障礙。要做到這一點，關鍵之處就是意識到一個事實，即在很多情況下，障礙並不是機器運轉不良，也不是會計的工作做得一團糟，而是工作流程本身不能順利推進。Scrum 主管的工作職責就是經常問團隊成員：「你們如何才能做得更好？」這種方式可以引領整個團隊持續改善自己的工作」（P69）。

2. 回顧與檢查：凡涉及溝通，總免不了誤解；凡涉及協作，也總免不了缺陷。通過回顧和檢查，消除誤解，彌補已知的缺憾，爭取每次進步一點點，臻於至善（笑。

注 2：對此，有興趣的可以看看軟體開發領域赫赫有名的書，小弗雷德里克 ? 布魯克斯：《人月神話：40 周年中文紀念版》（The Mythical Man-Month: Essays on Software Engineering Anniversary Edition）（UML China 翻譯組、汪穎譯者），清華大學出版社，2015。

注 3：三個問題是指，1. 「你今天做了什麼去幫助團隊完成衝刺？」；2. 「今天你打算做什麼來幫助團隊完成衝刺？」；3. 「什麼因素阻礙了團隊的前進之路?」。

§ 五、結語碎碎念

最後，方法如戀愛，常沒有對錯之分，而更在於合適與否。「敏捷方法」並非萬能，使用起來也還要考量相當多的細節（注 3）。

注 3：最近在看的 Marty Cagan：《啟示錄：打造用戶喜愛的產品》（Inspired: How to Create Products Customers Love）（七印部落譯），華中科技大學出版社，2011 一書中，專門有兩章《第 26 章：合理運用敏捷方法》和《第 27 章：合理運用瀑布式開發方法》，談及兩種方法的適用性和優缺點，供參考。

以上。

絕逼好書！看的時候一直做筆記，不是教條的說教，作者用了非常多的事例。即使不學敏捷方法看故事都能學到很多東西。當然如果想學敏捷就更要看了，非常具有實操性。裂牆推薦！

強烈推薦敏捷愛好者，ScrumMaster，敏捷團隊都來讀一下，正本清源，會有不同的感悟。

強烈推薦對敏捷感興趣，但是對於其他執行層面的書籍看的暈乎乎的人來閱讀，可以對Scrum入門有極大的幫助（即使是不用scrum，了解一下也是好的）。

@陳澤棟書摘已經寫的非常不錯了，我嘗試從另外一個方面做一些總結。

這本書的原名字，叫做《Scrum: The Art of Doing Twice the Work in Half the Time》，直譯就是《Scrum：事半功倍的藝術》，是兩位Scrum的創始人（主要是Dr. Sutherland）講述了Scrum的由來和發展。

作為一個ScrumMaster，我學習過不少Scrum相關的書，大部分都是在「術」這個層面的（道，術，器，「術」的層面最多，奇怪的是「道」和「器」層面反而不多）。而這本書的出現，是比較權威的「道」的層面，講述Scrum為什麼這麼設計，又經歷了什麼沿革。

另外，書中提到的Scrum應用於其他行業，如教育，軍事，裝修，政務等的實踐，也腦洞大開，非常有趣。

書里的一些洞見（劇透）：

每個人都是制度的產物；
Scrum承認和接受現實，並審視導致失敗的制度，並改良；
Scrum著眼於改變外在系統，而不是讓團隊成員互相指責或挑錯；
獎勵積極的行為，確保團隊成員集中精力，共同奮鬥，最後把事情做好；
超越個體-卓越團隊的目標都超越了個體的目標；
Scrum和看板方法相似，都受到了TPS（豐田生產方式）的影響，對於在制品限制，消除浪費，提高質量等，都有參考的痕迹。

溝通飽和度：

每個人對每件事情知道的信息越多，團隊做事的速度會越快；
影響溝通飽和度的因素，主要是勞動分工的水平，即團隊內設定了多少個專業的角色和頭銜；
頭銜往往伴生權利，而他往往把特定的知識隱藏起來，不與團隊其他成員共享；
Scrum團隊的重要目標，就是要提高溝通的飽和度。

消除浪費，也是Scrum的要義：

同時執行多項任務，會讓你變得愚蠢；
半途而廢等於沒做；
一次性就把事情做好；
工時越長，效率越低；
避免不合理現象；
不要依賴「英雄」；
消除愚蠢的規定；
將令人生厭者踢出團隊；
努力讓工作流暢起來。