專業(yè)的Scrum團隊

定　價：￥79.00

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

購買這本書可以去

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

ISBN：	9787111721598	出版時間：	2022-04-01	包裝：	平裝-膠訂
開本：	32開	頁數(shù)：		字數(shù)：

內容簡介

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

作者簡介

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

圖書目錄

序
前言
致謝
作者簡介
第1章　成為一個高效的Scrum團隊　001
1.1　產品負責人與開發(fā)團隊之間的協(xié)作　003
1.1.1　不要把業(yè)務和IT分開　005
1.1.2　為有價值的產品負責　006
1.1.3　協(xié)助管理產品待辦列表　007
1.1.4　Sprint范圍不是固定的　008
1.1.5　產品負責人參與　010
1.2　創(chuàng)建Scrum團隊的透明度　011
1.2.1　假設驅動的產品待辦列表　012
1.2.2　產品待辦列表驅動對話　013
1.2.3　著眼于大局　016
1.2.4　產品待辦事項需要創(chuàng)造價值　 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　完成代表著可發(fā)布　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　戰(zhàn)略：顧全大局　061
3.1.1　誰在Scrum中解決戰(zhàn)略問題　062
3.1.2　什么是涌現(xiàn)的結構　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　協(xié)作是改進的驅動力　079
3.3.2　每個人都需要做所有的事情嗎　081
3.3.3　使用測試先行的方法　084
3.4　應對不斷的變更　086
3.4.1　為什么重構是必選項　086
3.4.2　在變成大問題之前解決它們　089
3.4.3　根據(jù)原則而不是規(guī)則工作　090
3.5　總結　092
第4章　“可發(fā)布”小于“已發(fā)布”　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允許持續(xù)部署嗎　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　誰有終發(fā)言權　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　監(jiān)控改進，而不是指標　155
6.3　總結　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　領導不是指導　163
7.2.2　自組織并不缺乏管理　164
7.2.3　自組織并不容易　166
7.3　總結　167
第8章　敏捷組織　169
8.1　組織架構既可能幫助Scrum也可能阻礙Scrum　170
8.1.1　新工作，舊環(huán)境　170
8.1.2　職能型組織可能阻礙團隊發(fā)展　172
8.1.3　職能型組織提供了職業(yè)發(fā)展路徑，但要付出代價　173
8.2　復雜的組織需要徹底的簡單　176
8.2.1　Scrum可以幫助實現(xiàn)徹底的簡單　176
8.2.2　徹底的簡單需要徹底的透明　178
8.2.3　用透明取代匯報鏈和治理流程　179
8.2.