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