诺森专业的Scrum团队

序<br />前言<br />致谢<br />作者简介<br />章  成为一个高效的Scrum团队  001<br />1.1  产品负责人与开发团队之间的协作  003<br />1.1.1  不要把业务和IT分开  005<br />1.1.2  为有价值的产品负责  006<br />1.1.3  协管理产品待办列表  007<br />1.1.4  Sprint范围不是固定的  008<br />1.1.5  产品负责人参与  010<br />1.2  创建Scrum团队的透明度  011<br />1.2.1  设驱动的产品待办列表  012<br />1.2.2  产品待办列表驱动对话  013<br />1..  着眼于大局  016<br />1.2.4  产品待办事项需要创造价值   017<br />1.2.5  Sprint待办列表不仅仅是一个任务板  019<br />1.2.6  应该由谁来更新Sprint待办列表  020<br />1.2.7  Sprint待办列表不应该被隐藏  021<br />1.2.8  Sprint待办列表作为进度报告  022<br />1.2.9  工作燃尽图很少是完美的  0<br />1.2.10  防止Sprint待办列表过时  024<br />1.2.11  完成代表着可发布  026<br />1.2.12  度量和验产品的价值  027<br />1.3  总结  028<br />第2章  常见问题  029<br />2.1  缺少基础知识  031<br />2.1.1  Scrum的早期失误  032<br />2.1.2  缺少共同的价值观  034<br />2.1.3  缺少产品愿景  037<br />2.1.4  缺少跨职能特质  038<br />2.1.5  缺少自组织特质  040<br />2.2  对Scrum的常见误解  041<br />2.2.1  封闭的Sprint  042<br />2.2.2  承诺范围  043<br />2..  会议太多了  045<br />2.2.4  Sprint评审会中没有利益相关者  047<br />2.2.5  Scrum不是一种宗教  050<br />.  可以避免的错误  051<br />..1  只是名义上的Scrum Master  052<br />..2  太多的产品待办事项  053<br />..  舔饼干  055<br />..4  找不到的产品负责人  057<br />..5  每周开两次站会  058<br />2.4  总结  059<br />第3章  光有Scrum是不够的  060<br />3.1  战略：顾全大局  061<br />3.1.1  谁在Scrum中解决战略问题  062<br />3.1.2  什么是涌现的结构  064<br />3.1.3  为什么没有文档是个坏主意  067<br />3.2  策略：从想法到结果  068<br />3.2.1  产品待办列表的不同抽象层级  069<br />3.2.2  如何进行有意义的估算  072<br />3..  当我们有看板时，还需要Scrum&nsp; 075<br />3.2.4  如何度量成功  077<br />3.3  如何改进跨职能  079<br />3.3.1  协作是改进的驱动力  079<br />3.3.2  每个人都需要做所有的事情&nsp; 081<br />3.3.3  使用测试先行的方法  084<br />3.4  应对不断的变更  086<br />3.4.1  为什么重构是必选项  086<br />3.4.2  在变成大问题之前解决它们  089<br />3.4.3  根据原则而不是规则工作  090<br />3.5  总结  092<br />第4章  “可发布”小于“已发布”  094<br />4.1  什么是DevOps  095<br />4.1.1  它是一个角色……它是一种工具……它是DevOps  096<br />4.1.2  DevOps与工具有何关系  097<br />4.1.3  DevOps就够了&nsp; 099<br />4.2  如何结合Scrum和DevOps  100<br />4.2.1  DevOps正在取代Scrum&nsp; 101<br />4.2.2  Scrum允许持续部署&nsp; 102<br />4..  Scrum原则和DevOps文化是相辅相成的  105<br />4.2.4  如何使用DevOps改善流动  108<br />4.3  总结  110<br />第5章  解决  111<br />5.1  可以由当事人解决的  112<br />5.1.1  并非所有的分歧都会导致  112<br />5.1.2  谁有发言权  114<br />5.1.3  应该由当事人来解决  117<br />5.2  需要外部干预的  118<br />5.2.1  升级的健康  119<br />5.2.2  有些需要暴露出来  1<br />5..  忠于Scrum团队还是你的部门  125<br />5.3  需要更强干预的致命  126<br />5.3.1  给Scrum团队施加压力  127<br />5.3.2  换一支队伍来保护它  129<br />5.4  总结  131<br />第6章  度量成功  133<br />6.1  朝着目标努力  134<br />6.1.1  我们需要更快地交付  134<br />6.1.2  我们在交付价值  137<br />6.1.3  什么是价值  140<br />6.1.4  实验回路  143<br />6.2  改进团队成果  146<br />6.2.1  速率不是绩效  146<br />6.2.2  如何（不）提升绩效  148<br />6..  你改进不了你无法度量的东西  152<br />6.2.4  监控改进，而不是指标  155<br />6.3  总结  156<br />第7章  Scrum和管理  157<br />7.1  Scrum中的管理角色  158<br />7.1.1  透明不是监视  158<br />7.1.2  负责不是控制  160<br />7.2  如何实现自组织  162<br />7.2.1  领导不是指导  163<br />7.2.2  自组织并不缺乏管理  164<br />7..  自组织并不容易  166<br />7.3  总结  167<br />第8章  敏捷组织  169<br />8.1  组织架构既可能帮Scrum也可能阻碍Scrum  170<br />8.1.1  新工作，旧环境  170<br />8.1.2  职能型组织可能阻碍团队发展  172<br />8.1.3  职能型组织提供了职业发展路径，但要付出代价  173<br />8.2  复杂的组织需要的简单  176<br />8.2.1  Scrum可以帮实现的简单  176<br />8.2.2  的简单需要的透明  178<br />8..  用透明取代汇报链和治理流程  179<br />8.2.4  打破“孤岛”，围绕客户价值进行调整  181<br />8.3  总结  181<br />第9章  持续改进永远不会停止  183<br />9.1  如何持续改进  184<br />9.1.1  失败：学会的步  184<br />9.1.2  我们已经改进了我们能改进的一切  187<br />9.1.3  Scrum Master要被淘汰&nsp; 189<br />9.2  回顾是改进的驱动力  190<br />9.2.1  强化积极面  190<br />9.2.2  专注于一个单一的改进  191<br />9..  随着时间的推移改变组织的文化以提高专注度  192<br />9.3  Scrum会实现&nsp; 193<br />9.3.1  我们什么时候才能实现Scrum  194<br />9.3.2  在产品上线后如何使用Scrum  197<br />9.3.3  Scrum不需要外部专家的意见  198<br />9.4  总结  200<br />参考文献  201

本书通过一个关于Scrum团队的故事介绍团队成员如何一起面对共同的挑战，从而交付有价值的产品增量。在叙述上，本书结合案例研究与相关讨论，首先介绍 Scrum 团队遇到的特定挑战，然后探索应对该挑战的替代方案。本书可以帮读者将Scrum框架规则应用到日常工作中，优化团队和个人的表现，改进他们的工作方式和交付有价值的产品，创造更多的价值。<br /> 本书适合所有在Scrum团队工作的人阅读，包括刚接触这个框架的人与经验丰富的Scrum实践者。