书籍详情
专业的Scrum团队
作者：[德]彼得·格茨 [德]乌维·M.席尔默 [德]库尔特·比特纳
出版社：机械工业出版社
出版时间：2022-04-01
ISBN：9787111721598
定价：¥79.00
购买这本书可以去
内容简介
本书通过一个关于Scrum团队的故事介绍团队成员如何一起面对共同的挑战，从而交付有价值的产品增量。在叙述上，本书结合案例研究与相关讨论，首先介绍 Scrum 团队遇到的特定挑战，然后探索应对该挑战的替代方案。本书可以帮助读者将Scrum框架规则应用到日常工作中，优化团队和个人的表现，改进他们的工作方式和交付有价值的产品，创造更多的价值。本书适合所有在Scrum团队工作的人阅读，包括刚接触这个框架的人与经验丰富的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系列图书的丛书主编。
目录
序
前言
致谢
作者简介
第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.
猜您喜欢
