掃一掃
關注中圖網
官方微博
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
專業的Scrum團隊 版權信息
- ISBN：9787111721598
- 條形碼：9787111721598 ; 978-7-111-72159-8
- 裝幀：平裝-膠訂
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
專業的Scrum團隊 內容簡介
本書通過一個關于Scrum團隊的故事介紹團隊成員如何一起面對共同的挑戰，從而交付有價值的產品增量。在敘述上，本書結合案例研究與相關討論，首先介紹 Scrum 團隊遇到的特定挑戰，然后探索應對該挑戰的替代方案。本書可以幫助讀者將Scrum框架規則應用到日常工作中，優化團隊和個人的表現，改進他們的工作方式和交付有價值的產品，創造更多的價值。
本書適合所有在Scrum團隊工作的人閱讀，包括剛接觸這個框架的人與經驗豐富的Scrum實踐者。
專業的Scrum團隊 目錄
序
前言
致謝
作者簡介
第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.
前言
致謝
作者簡介
第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.
展開全部
專業的Scrum團隊 作者簡介
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系列圖書的叢書主編。
書友推薦
- >
月亮與六便士
- >
【精裝繪本】畫給孩子的中國神話
- >
隨園食單
- >
史學評論
- >
山海經
- >
名家帶你讀魯迅:朝花夕拾
- >
巴金－再思錄
- >
中國人在烏蘇里邊疆區:歷史與人類學概述
本類暢銷
