專業(yè)的Scrum團(tuán)隊(duì)

序
前言
致謝
作者簡介
第1章　成為一個高效的Scrum團(tuán)隊(duì)　001
1.1　產(chǎn)品負(fù)責(zé)人與開發(fā)團(tuán)隊(duì)之間的協(xié)作　003
1.1.1　不要把業(yè)務(wù)和IT分開　005
1.1.2　為有價值的產(chǎn)品負(fù)責(zé)　006
1.1.3　協(xié)助管理產(chǎn)品待辦列表　007
1.1.4　Sprint范圍不是固定的　008
1.1.5　產(chǎn)品負(fù)責(zé)人參與　010
1.2　創(chuàng)建Scrum團(tuán)隊(duì)的透明度　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)品待辦事項(xiàng)需要創(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待辦列表作為進(jìn)度報告　022
1.2.9　工作燃盡圖很少是完美的　023
1.2.10　防止Sprint待辦列表過時　024
1.2.11　完成代表著可發(fā)布　026
1.2.12　度量和驗(yàn)證產(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)品待辦事項(xiàng)　053
2.3.3　舔餅干　055
2.3.4　找不到的產(chǎn)品負(fù)責(zé)人　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　如何進(jìn)行有意義的估算　072
3.2.3　當(dāng)我們有看板時，還需要Scrum嗎　075
3.2.4　如何度量成功　077
3.3　如何改進(jìn)跨職能　079
3.3.1　協(xié)作是改進(jìn)的驅(qū)動力　079
3.3.2　每個人都需要做所有的事情嗎　081
3.3.3　使用測試先行的方法　084
3.4　應(yīng)對不斷的變更　086
3.4.1　為什么重構(gòu)是必選項(xiàng)　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　可以由當(dāng)事人解決的沖突　112
5.1.1　并非所有的分歧都會導(dǎo)致沖突　112
5.1.2　誰有終發(fā)言權(quán)　114
5.1.3　沖突應(yīng)該由當(dāng)事人來解決　117
5.2　需要外部干預(yù)的沖突　118
5.2.1　升級的健康沖突　119
5.2.2　有些沖突需要暴露出來　123
5.2.3　忠于Scrum團(tuán)隊(duì)還是你的部門　125
5.3　需要更強(qiáng)干預(yù)的致命沖突　126
5.3.1　給Scrum團(tuán)隊(duì)施加壓力　127
5.3.2　換一支隊(duì)伍來保護(hù)它　129
5.4　總結(jié)　131
第6章　度量成功　133
6.1　朝著目標(biāo)努力　134
6.1.1　我們需要更快地交付　134
6.1.2　我們是否在交付價值　137
6.1.3　什么是價值　140
6.1.4　實(shí)驗(yàn)回路　143
6.2　改進(jìn)團(tuán)隊(duì)成果　146
6.2.1　速率不是績效　146
6.2.2　如何（不）提升績效　148
6.2.3　你改進(jìn)不了你無法度量的東西　152
6.2.4　監(jiān)控改進(jìn)，而不是指標(biāo)　155
6.3　總結(jié)　156
第7章　Scrum和管理　157
7.1　Scrum中的管理角色　158
7.1.1　透明不是監(jiān)視　158
7.1.2　負(fù)責(zé)不是控制　160
7.2　如何實(shí)現(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　職能型組織可能阻礙團(tuán)隊(duì)發(fā)展　172
8.1.3　職能型組織提供了職業(yè)發(fā)展路徑，但要付出代價　173
8.2　復(fù)雜的組織需要徹底的簡單　176
8.2.1　Scrum可以幫助實(shí)現(xiàn)徹底的簡單　176
8.2.2　徹底的簡單需要徹底的透明　178
8.2.3　用透明取代匯報鏈和治理流程　179
8.2.