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

定　價(jià)：￥79.00

作　者：	[德]彼得·格茨 [德]烏維·M.席爾默 [德]庫(kù)爾特·比特納
出版社：	機(jī)械工業(yè)出版社
叢編項(xiàng)：
標(biāo)　簽：	暫缺

購(gòu)買這本書可以去

當(dāng)當(dāng)網(wǎng) (￥59.20)

ISBN：	9787111721598	出版時(shí)間：	2022-04-01	包裝：	平裝-膠訂
開本：	32開	頁(yè)數(shù)：		字?jǐn)?shù)：

內(nèi)容簡(jiǎn)介

　　本書通過(guò)一個(gè)關(guān)于Scrum團(tuán)隊(duì)的故事介紹團(tuán)隊(duì)成員如何一起面對(duì)共同的挑戰(zhàn)，從而交付有價(jià)值的產(chǎn)品增量。在敘述上，本書結(jié)合案例研究與相關(guān)討論，首先介紹 Scrum 團(tuán)隊(duì)遇到的特定挑戰(zhàn)，然后探索應(yīng)對(duì)該挑戰(zhàn)的替代方案。本書可以幫助讀者將Scrum框架規(guī)則應(yīng)用到日常工作中，優(yōu)化團(tuán)隊(duì)和個(gè)人的表現(xiàn)，改進(jìn)他們的工作方式和交付有價(jià)值的產(chǎn)品，創(chuàng)造更多的價(jià)值。本書適合所有在Scrum團(tuán)隊(duì)工作的人閱讀，包括剛接觸這個(gè)框架的人與經(jīng)驗(yàn)豐富的Scrum實(shí)踐者。

作者簡(jiǎn)介

　　Peter G？tz是一名顧問(wèn)、培訓(xùn)師和教練。他于2001年開始從事Java軟件開發(fā)工作，并于2006年進(jìn)入咨詢行業(yè)。他也是Scrum.org的專業(yè)Scrum培訓(xùn)師，自2008年以來(lái)一直以Scrum教練的身份協(xié)助團(tuán)隊(duì)。作為專業(yè)Scrum開發(fā)人員培訓(xùn)的負(fù)責(zé)人之一，他負(fù)責(zé)維護(hù)、開發(fā)課程材料和學(xué)習(xí)路徑。他對(duì)軟件架構(gòu)和DevOps充滿熱情，喜歡討論如何使用現(xiàn)代架構(gòu)風(fēng)格和工程實(shí)踐來(lái)改進(jìn)Scrum團(tuán)隊(duì)的工作流程。 Uwe M. Schirmer是一位認(rèn)證的Scrum專家、軟件架構(gòu)師、項(xiàng)目經(jīng)理和需求工程師。他于 20 世紀(jì) 80 年代開始從事計(jì)算機(jī)方面的工作。經(jīng)過(guò)兩次職業(yè)教育后，他在德國(guó)富爾達(dá)應(yīng)用技術(shù)大學(xué)學(xué)習(xí)計(jì)算機(jī)科學(xué)。他自1996年起擔(dān)任培訓(xùn)師，自2000年起擔(dān)任不同客戶和項(xiàng)目的顧問(wèn)。如今，他在埃森哲解決方案智庫(kù)（Accenture SolutionsIQ）擔(dān)任敏捷教練和軟件架構(gòu)師，在幫助組織實(shí)現(xiàn)現(xiàn)代化的同時(shí)，兼顧其應(yīng)用程序和基礎(chǔ)設(shè)施的產(chǎn)品、質(zhì)量和體系結(jié)構(gòu)。他的主要興趣是敏捷軟件開發(fā)、浮現(xiàn)式設(shè)計(jì)和架構(gòu)、軟件架構(gòu)編檔、DevOps、開發(fā)團(tuán)隊(duì)和組織文化的演進(jìn)。Kurt Bittner在幫助團(tuán)隊(duì)在短反饋驅(qū)動(dòng)周期內(nèi)交付軟件方面（作為開發(fā)人員、產(chǎn)品經(jīng)理、產(chǎn)品負(fù)責(zé)人、行業(yè)分析師以及組織變革代理人）擁有超過(guò)35年的經(jīng)驗(yàn)。除了發(fā)布許多博客和文章外，他還與人合著了許多有關(guān)軟件工程的書籍。他目前是Pearson出版的Scrum.org系列圖書的叢書主編。

圖書目錄

序
前言
致謝
作者簡(jiǎn)介
第1章　成為一個(gè)高效的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　為有價(jià)值的產(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ū)動(dòng)的產(chǎn)品待辦列表　012
1.2.2　產(chǎn)品待辦列表驅(qū)動(dòng)對(duì)話　013
1.2.3　著眼于大局　016
1.2.4　產(chǎn)品待辦事項(xiàng)需要?jiǎng)?chuàng)造價(jià)值　 017
1.2.5　Sprint待辦列表不僅僅是一個(gè)任務(wù)板　019
1.2.6　應(yīng)該由誰(shuí)來(lái)更新Sprint待辦列表　020
1.2.7　Sprint待辦列表不應(yīng)該被隱藏　021
1.2.8　Sprint待辦列表作為進(jìn)度報(bào)告　022
1.2.9　工作燃盡圖很少是完美的　023
1.2.10　防止Sprint待辦列表過(guò)時(shí)　024
1.2.11　完成代表著可發(fā)布　026
1.2.12　度量和驗(yàn)證產(chǎn)品的價(jià)值　027
1.3　總結(jié)　028
第2章　常見問(wèn)題　029
2.1　缺少基礎(chǔ)知識(shí)　031
2.1.1　Scrum的早期失誤　032
2.1.2　缺少共同的價(jià)值觀　034
2.1.3　缺少產(chǎn)品愿景　037
2.1.4　缺少跨職能特質(zhì)　038
2.1.5　缺少自組織特質(zhì)　040
2.2　對(duì)Scrum的常見誤解　041
2.2.1　封閉的Sprint　042
2.2.2　承諾范圍　043
2.2.3　會(huì)議太多了　045
2.2.4　Sprint評(píng)審會(huì)中沒有利益相關(guān)者　047
2.2.5　Scrum不是一種宗教　050
2.3　可以避免的錯(cuò)誤　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　每周開兩次站會(huì)　058
2.4　總結(jié)　059
第3章　光有Scrum是不夠的　060
3.1　戰(zhàn)略：顧全大局　061
3.1.1　誰(shuí)在Scrum中解決戰(zhàn)略問(wèn)題　062
3.1.2　什么是涌現(xiàn)的結(jié)構(gòu)　064
3.1.3　為什么沒有文檔是個(gè)壞主意　067
3.2　策略：從想法到結(jié)果　068
3.2.1　產(chǎn)品待辦列表的不同抽象層級(jí)　069
3.2.2　如何進(jìn)行有意義的估算　072
3.2.3　當(dāng)我們有看板時(shí)，還需要Scrum嗎　075
3.2.4　如何度量成功　077
3.3　如何改進(jìn)跨職能　079
3.3.1　協(xié)作是改進(jìn)的驅(qū)動(dòng)力　079
3.3.2　每個(gè)人都需要做所有的事情嗎　081
3.3.3　使用測(cè)試先行的方法　084
3.4　應(yīng)對(duì)不斷的變更　086
3.4.1　為什么重構(gòu)是必選項(xiàng)　086
3.4.2　在變成大問(wèn)題之前解決它們　089
3.4.3　根據(jù)原則而不是規(guī)則工作　090
3.5　總結(jié)　092
第4章　“可發(fā)布”小于“已發(fā)布”　094
4.1　什么是DevOps　095
4.1.1　它是一個(gè)角色……它是一種工具……它是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改善流動(dòng)　108
4.3　總結(jié)　110
第5章　解決沖突　111
5.1　可以由當(dāng)事人解決的沖突　112
5.1.1　并非所有的分歧都會(huì)導(dǎo)致沖突　112
5.1.2　誰(shuí)有終發(fā)言權(quán)　114
5.1.3　沖突應(yīng)該由當(dāng)事人來(lái)解決　117
5.2　需要外部干預(yù)的沖突　118
5.2.1　升級(jí)的健康沖突　119
5.2.2　有些沖突需要暴露出來(lái)　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ì)伍來(lái)保護(hù)它　129
5.4　總結(jié)　131
第6章　度量成功　133
6.1　朝著目標(biāo)努力　134
6.1.1　我們需要更快地交付　134
6.1.2　我們是否在交付價(jià)值　137
6.1.3　什么是價(jià)值　140
6.1.4　實(shí)驗(yàn)回路　143
6.2　改進(jìn)團(tuán)隊(duì)成果　146
6.2.1　速率不是績(jī)效　146
6.2.2　如何（不）提升績(jī)效　148
6.2.3　你改進(jìn)不了你無(wú)法度量的東西　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ā)展路徑，但要付出代價(jià)　173
8.2　復(fù)雜的組織需要徹底的簡(jiǎn)單　176
8.2.1　Scrum可以幫助實(shí)現(xiàn)徹底的簡(jiǎn)單　176
8.2.2　徹底的簡(jiǎn)單需要徹底的透明　178
8.2.3　用透明取代匯報(bào)鏈和治理流程　179
8.2.