这本书是教练给的读书雷达中的第一本，几年前我就读过，本次重读，记录下体会。
需要有且仅有一个PO
Jeff Sutherland对Scrum运作的检查标准：
• Scrum团队必须要有产品负责人，而且团队都清楚这个人是谁。
• 产品负责人必须要有产品Backlog，其中包括团队对它进行的估算。
• 团队必须要有燃尽图，而且要了解他们自己的生产率。
• 在一个Sprint中，外人不能干涉团队的工作。
序言中提到的这几点，以前没有特别关注或是留下印象。在试点团队运作了一段时间后，才体会到这几点的价值和意义。方教练从转型开始就要求找到一个大PO对两个项目负责，现在看来这一点是非常重要的。任务的优先级必须有一个人拍板，否则多团队的协作运行一定会出现问题。关于团队速率和燃尽图，现在试点团队还没有输出，不过这个问题倒不是太大，后续几个迭代应该是会有的。
迭代完成要有可交付成果
Scrum和极限编程（XP）都要求团队在每一次迭代的结尾完成一些可以交付的工作片段。
有些产品研发团队是在按照Scrum的四会方式运作，但是迭代完成后没有评审会，没有潜在可交付的产品，其实是因为在产品研发阶段缺少直接的下游用户，这样团队就缺少了反馈，持续的对产品进行迭代改进的输入就少了。
不要对质量妥协
经验告诉我：牺牲内部质量是一个糟糕透顶的想法。现在节省下来一点时间，接下来的日子里你就要一直为它付出代价。一旦我们放松要求，允许代码库中暗藏问题，后面就很难恢复质量了。
质量内建，质量是不能让步和妥协的。试点项目在研发阶段可以做到这一点，但是在面向合同类项目时是否仍然能坚持并得到认同和支持，这一点很值得怀疑，就是试点团队自己对这件事情也不太有把握。要转变思路其实还是挺难的，不过明年的质量目标已经设定，费用计算类的缺陷要做到0泄漏，非费用计算类的泄漏率要控制在5%，在这个指标正式发布之后，希望大家的质量意识能够有所转变。
时间盒的力量
Scrum中的一切事情都有时间盒。我喜欢这条简单如一的规则，并一直力求贯彻到底。
固定时间盒，这个力量远比想象的要大，它逼迫团队提升效率。似乎会议时间开得过长一定会成为初涉Scrum的团队的通病，有的团队很快能解决这个问题得到改进，有的团队就不行。
目标，目标
Sprint目标需要回答这个根本的问题，“我们为什么要进行这个sprint？为什么我们不直接放假算了？”要想从产品负责人的口中哄骗出sprint目标，你不妨一字不差的问他这个问题看看。
有时候做事情总是会忘记这一点，只要手头有件事情在忙着，就会心安理得。手头没事情的时候就会觉得空虚。有目标就有奋斗的动力，这是把团队凝聚在一起的有效手段。
我是有底线的
