本書通過一個關于Scrum團隊的故事介紹團隊成員如何一起面對共同的挑戰，從而交付有價值的產品增量。在敘述上，本書結合案例研究與相關討論，首先介紹 Scrum 團隊遇到的特定挑戰，然后探索應對該挑戰的替代方案。本書可以幫助讀者將Scrum框架規則應用到日常工作中，優化團隊和個人的表現，改進他們的工作方式和交付有價值的產品，創造更多的價值。
本書適合所有在Scrum團隊工作的人閱讀，包括剛接觸這個框架的人與經驗豐富的Scrum實踐者。
關于Scrum的書有很多，它們大多集中在某些具體方面，如Scrum框架或Scrum角色詳情。也有一些會解釋某個特定工具或實踐，如用戶故事，這些工具或實踐使Scrum中的工作變得更容易。
這些書中有很多都很不錯，但我們發現，沒有一本書能真正讓人們做好準備，知道自己成為Scrum團隊的一員后，日常工作將會發生怎樣的變化。我們寫這本書的目的在于傳達日常經驗，并為你提供成為一個更好的Scrum團隊成員所需要的洞察力。
本書目的
本書是為Scrum團隊成員而寫的。《Scrum指南》說得沒錯：“Scrum雖然很容易理解，但是很難掌握。”對于Scrum團隊中的人來說，最困難的地方就是每天一起共事。
掌握緊密協作技能是成功的Scrum團隊所必需的，這是一種整體性挑戰，而非針對某個框架或某個支持工具的單一挑戰。
我們寫這本書的目的在于幫助在Scrum團隊中工作的人使用框架來改進自己的工作方式并交付有價值的產品。我們描述了Scrum團隊面臨的常見問題和我們所看到的實際解決方案，還討論了可能幫助你應對類似挑戰的典型解決方案。
我們建議你將這些案例研究視為僅供參考的例子。本書分享的這些案例研究并非可照搬照抄的解決方案，你需要根據自己的具體情況對其進行調整。分享它們是為了激發你的團隊成員的自省與討論，促使你們討論替代方案及其利弊，至于該怎么做還是得由你們自己決定。
我們不打算將這本書作為Scrum的入門書籍。如果你還不了解Scrum，那么你應該閱讀《Scrum指南》或者參加一個關于Scrum的課程，甚至還可能需要獲得一些使用Scrum的實踐經驗。如果你對Scrum的基礎知識有一定了解，并且希望幫助你的團隊提高使用Scrum進行協作的能力，那么請繼續閱讀。
本書讀者對象
本書適合所有在Scrum團隊工作的人閱讀。你將能夠與所描述的挑戰聯系起來，并可以使用其中介紹的理念來找到自己在Scrum團隊中的工作方式。通過閱讀本書，剛接觸這個框架的人可以避免經歷一些其他人曾經歷過的艱難困苦，而經驗豐富的Scrum實踐者將收獲更多關于常見挑戰及如何應對這些挑戰的新觀點。
那些與Scrum團隊一起工作但不是Scrum團隊成員的人也可能對本書感興趣。如果你屬于這一類，了解成功的團隊協作要素以及如何應對團隊挑戰將會對你有所幫助。你將了解成功應用Scrum需要什么樣的環境。
無論你是經驗豐富的Scrum實踐者還是對該框架仍相當陌生的新手，都應該了解《Scrum指南》中所描述的Scrum元素與規則。本書假設讀者已熟悉敏捷和Scrum的價值與原則。
本書結構
本書講述的是一個關于Scrum團隊的故事，介紹團隊成員如何一起面對共同的挑戰，從而交付有價值的產品增量。書中討論他們在使用Scrum時所學到的知識，以及他們如何優化合作方式。在敘述上，本書結合案例研究與相關討論，首先介紹Scrum團隊遇到的特定挑戰，然后探索應對該挑戰的替代方案。
你應該從頭讀到尾，跟隨書中的故事學習。各章遵循以下大綱：
第1章 介紹Scrum團隊并描述它是如何運轉的。本章重點介紹開發團隊（Development Team）和產品負責人之間的協作。產品待辦列表、Sprint待辦列表與產品增量是在快速變化的環境中保證透明度所需的工具。本章將演示這些工具如何幫助Scrum團隊成員計劃和組織他們的工作。
第2章 討論為什么在Scrum方面已經積累了一些經驗的新手Scrum團隊有時會認為Scrum不起作用。得出此結論的大部分原因在于其實現Scrum的方式死板。團隊雖然在踐行這些方法，但對Scrum的特定規則或某些工具的認識不到位。
第3章 討論策略和產品待辦列表精化，以及跨職能與不斷變化。《Scrum指南》描述了團隊解決復雜適應性問題的框架。Scrum團隊必須找到并定義自己的工作方式以及想要成功所使用的工具。
第4章 描述DevOps的理念、DevOps與Scrum的關系，以及它可以如何進一步改進Scrum團隊的工作。Scrum團隊最重要的成果是產品—《Scrum指南》稱之為“可發布的產品增量”。這是最低要求。
第5章 探討一個不可避免的事實，即當人們密切合作時就會產生沖突。某種程度的沖突是正常的、健康的，但是，它可能會升級并成為團隊和組織的問題。本章描述沖突的來源和解決方法。
第6章 討論Scrum團隊可以使用的度量標準，以及度量標準可能被濫用而因此失去價值。組織要想知道各部門的工作效果，績效和成功的度量是必不可少的。
第7章 重點介紹管理的角色及其對Scrum團隊的重要性。本章將描述傳統管理在敏捷環境中面臨的常見挑戰及其解決方案。
第8章 描述Scrum團隊需要在什么樣的組織中運轉。本章將討論傳統組織和Scrum團隊之間的常見沖突領域，例如層級制度，以及對項目而非產品的思考。你將看到Scrum團隊要想成功協作需要什么條件。
第9章 強調Scrum中的改進被描述為 “持續的”是有原因的。成為一個Scrum團隊的道路永遠沒有盡頭，向Scrum的過渡也永遠不會結束。
請不要把書中講的故事當作Scrum“模樣”的藍圖，它不是這樣的。我們的團隊探索Scrum，并做出與我們在真實團隊中看到的相同或相似的決策。這些決策有時是錯誤的，之后必須改正。Scrum需要去探索與體驗，其實現方式并不是唯一的。
我們希望你能從本書中得到更多的樂趣，也希望你能從Scrum中得到更多的樂趣。
Acknowledgements?致 謝
養育一個孩子需要全村的力量。
—非洲諺語
我認為這句諺語適用于全天下的孩子。在過去的幾年里，我發現這句諺語也同樣適用于圖書。一本書的誕生真的需要很多人。在此我想特別感謝幾個人，他們對這本書至關重要。
首先，我要感謝Uwe M. Schirmer的合作支持。從本書最開始的想法到結尾，我們一直在一起工作。我和他一起寫了這本書的初稿（你應該慶幸沒有讀過），在這個過程中，我們學到了很多寫書的禁忌。遺憾的是，由于他日程繁忙，因此無法全身心地投入到這本書的第二稿中。我很感激他付出的時間和給我的支持。
接下來，我要感謝Kurt Bittner對本書的指導與貢獻。他幫助Uwe和我起草第一稿，然后在創作第二稿的過程中給予我很大幫助。我從他那里學到了很多關于寫作和英語語言的知識。我很驚訝他竟能如此快地看完書稿，并提供建設性的、有幫助的、切中要害的反饋。感謝他在寫作的最后階段更加積極地參與，感謝他對有關管理和組織的章節所做的貢獻。
我還要感謝Scrum.org的所有支持，尤其是Ken Schwaber、Dave West、Sabrina Love和Eric Naiburg。感謝Dave和我分享這個系列叢書的想法，特別感謝他為本書作序。非常感謝Ken給予第一稿的評價，不然Uwe和我就無法改進我們的成果，也就無法有效地了解早期反饋的好處。感謝他們共同創建Scrum并為我們帶來了靈感。非常感謝Sabrina的設計，不僅僅是她對本書的設計，還有每次Scrum.org的培訓師冒出新的視覺想法卻不知道如何實現時的設計。我特別喜歡她設計的封面。非常感謝Eric對本書內容與閱讀人群劃分的幫助。
沒有我們的專家評審，這本書就不會是今天的樣子。他們提供了很多很好的建議，給的反饋也很準確直接。非常感謝Helen Sedlmeier、Oliver Hankeln、Jürgen Mohr、Mikkel Toudal Kristiansen、Thomas Barber、Svenja Trampisch、Thomas Schissler、Marc Kaufmann和Kim Nena Duggen。他們為那些我認為已經“完成”的部分輸入的許多有價值的東西總是令我感到驚喜。
我的同事Stefan Toth慷慨地允許我們使用他的視覺設計來制作架構餅圖。非常感謝他的這個隱喻，我只敢在快到飯點的時候用，因為它會讓我感到很餓。
特別感謝Pearson和每一位助力本書成形和完善的人。我想他們應該是幫助孕育此書的“村民”主力，而我只能想到那些與Uwe、Kurt和我直接合作的人。因此，我要感謝我們的原始編輯Chris Guzikowski和現任編輯Haze Humbert，他們給予我們建議與支持，也是我們與Pearson的直接聯系人。
最后，我要特別感謝我的妻子和三個孩子在我寫作本書的過程中給予我的耐心。原來“工作量應該不大”是個謊言，誰會想到呢？
Peter G?tz是一名顧問、培訓師和教練。他于2001年開始從事Java軟件開發工作，并于2006年進入咨詢行業。他也是Scrum.org的專業Scrum培訓師，自2008年以來一直以Scrum教練的身份協助團隊。作為專業Scrum開發人員培訓的負責人之一，他負責維護、開發課程材料和學習路徑。他對軟件架構和DevOps充滿熱情，喜歡討論如何使用現代架構風格和工程實踐來改進Scrum團隊的工作流程。
Uwe M. Schirmer是一位認證的Scrum專家、軟件架構師、項目經理和需求工程師。他于 20 世紀 80 年代開始從事計算機方面的工作。經過兩次職業教育后，他在德國富爾達應用技術大學學習計算機科學。他自1996年起擔任培訓師，自2000年起擔任不同客戶和項目的顧問。如今，他在埃森哲解決方案智庫（Accenture SolutionsIQ）擔任敏捷教練和軟件架構師，在幫助組織實現現代化的同時，兼顧其應用程序和基礎設施的產品、質量和體系結構。他的主要興趣是敏捷軟件開發、浮現式設計和架構、軟件架構編檔、DevOps、開發團隊和組織文化的演進。
Kurt Bittner在幫助團隊在短反饋驅動周期內交付軟件方面（作為開發人員、產品經理、產品負責人、行業分析師以及組織變革代理人）擁有超過35年的經驗。除了發布許多博客和文章外，他還與人合著了許多有關軟件工程的書籍。他目前是Pearson出版的Scrum.org系列圖書的叢書主編。
序
前言
致謝
作者簡介
第1章 成為一個高效的Scrum團隊 001
1.1 產品負責人與開發團隊之間的協作 003
1.1.1 不要把業務和IT分開 005
1.1.2 為有價值的產品負責 006
1.1.3 協助管理產品待辦列表 007
1.1.4 Sprint范圍不是固定的 008
1.1.5 產品負責人參與 010
1.2 創建Scrum團隊的透明度 011
1.2.1 假設驅動的產品待辦列表 012
1.2.2 產品待辦列表驅動對話 013
1.2.3 著眼于大局 016
1.2.4 產品待辦事項需要創造價值 017
1.2.5 Sprint待辦列表不僅僅是一個任務板 019
1.2.6 應該由誰來更新Sprint待辦列表 020
1.2.7 Sprint待辦列表不應該被隱藏 021
1.2.8 Sprint待辦列表作為進度報告 022
1.2.9 工作燃盡圖很少是完美的 023
1.2.10 防止Sprint待辦列表過時 024
1.2.11 完成代表著可發布 026
1.2.12 度量和驗證產品的價值 027
1.3 總結 028
第2章 常見問題 029
2.1 缺少基礎知識 031
2.1.1 Scrum的早期失誤 032
2.1.2 缺少共同的價值觀 034
2.1.3 缺少產品愿景 037
2.1.4 缺少跨職能特質 038
2.1.5 缺少自組織特質 040
2.2 對Scrum的常見誤解 041
2.2.1 封閉的Sprint 042
2.2.2 承諾范圍 043
2.2.3 會議太多了 045
2.2.4 Sprint評審會中沒有利益相關者 047
2.2.5 Scrum不是一種宗教 050
2.3 可以避免的錯誤 051
2.3.1 只是名義上的Scrum Master 052
2.3.2 太多的產品待辦事項 053
2.3.3 舔餅干 055
2.3.4 找不到的產品負責人 057
2.3.5 每周開兩次站會 058
2.4 總結 059
第3章 光有Scrum是不夠的 060
3.1 戰略：顧全大局 061
3.1.1 誰在Scrum中解決戰略問題 062
3.1.2 什么是涌現的結構 064
3.1.3 為什么沒有文檔是個壞主意 067
3.2 策略：從想法到結果 068
3.2.1 產品待辦列表的不同抽象層級 069
3.2.2 如何進行有意義的估算 072
3.2.3 當我們有看板時，還需要Scrum嗎 075
3.2.4 如何度量成功 077
3.3 如何改進跨職能 079
3.3.1 協作是改進的驅動力 079
3.3.2 每個人都需要做所有的事情嗎 081
3.3.3 使用測試先行的方法 084
3.4 應對不斷的變更 086
3.4.1 為什么重構是必選項 086
3.4.2 在變成大問題之前解決它們 089
3.4.3 根據原則而不是規則工作 090
3.5 總結 092
第4章 “可發布”小于“已發布” 094
4.1 什么是DevOps 095
4.1.1 它是一個角色……它是一種工具……它是DevOps 096
4.1.2 DevOps與工具有何關系 097
4.1.3 DevOps就夠了嗎 099
4.2 如何結合Scrum和DevOps 100
4.2.1 DevOps正在取代Scrum嗎 101
4.2.2 Scrum允許持續部署嗎 102
4.2.3 Scrum原則和DevOps文化是相輔相成的 105
4.2.4 如何使用DevOps改善流動 108
4.3 總結 110
第5章 解決沖突 111
5.1 可以由當事人解決的沖突 112
5.1.1 并非所有的分歧都會導致沖突 112
5.1.2 誰有最終發言權 114
5.1.3 沖突應該由當事人來解決 117
5.2 需要外部干預的沖突 118
5.2.1 升級的健康沖突 119
5.2.2 有些沖突需要暴露出來 123
5.2.3 忠于Scrum團隊還是你的部門 125
5.3 需要更強干預的致命沖突 126
5.3.1 給Scrum團隊施加壓力 127
5.3.2 換一支隊伍來保護它 129
5.4 總結 131
第6章 度量成功 133
6.1 朝著目標努力 134
6.1.1 我們需要更快地交付 134
6.1.2 我們是否在交付價值 137
6.1.3 什么是價值 140
6.1.4 實驗回路 143
6.2 改進團隊成果 146
6.2.1 速率不是績效 146
6.2.2 如何（不）提升績效 148
6.2.3 你改進不了你無法度量的東西 152
6.2.4 監控改進，而不是指標 155
6.3 總結 156
第7章 Scrum和管理 157
7.1 Scrum中的管理角色 158
7.1.1 透明不是監視 158
7.1.2 負責不是控制 160
7.2 如何實現自組織 162
7.2.1 領導不是指導 163
7.2.2 自組織并不缺乏管理 164
7.2.3 自組織并不容易 166
7.3 總結 167
第8章 敏捷組織 169
8.1 組織架構既可能幫助Scrum也可能阻礙Scrum 170
8.1.1 新工作，舊環境 170
8.1.2 職能型組織可能阻礙團隊發展 172
8.1.3 職能型組織提供了職業發展路徑，但要付出代價 173
8.2 復雜的組織需要徹底的簡單 176
8.2.1 Scrum可以幫助實現徹底的簡單 176
8.2.2 徹底的簡單需要徹底的透明 178
8.2.3 用透明取代匯報鏈和治理流程 179
8.2.
新書資訊