1
在最近的一次迭代计划会议上，我们将需求评审、原型评审、迭代计划放在一个会议里面，导致会议时间超长且没有突出重点。
同时，会议中还暴露了另外两个问题：一是会议讨论过程中达成的共识并没有被有效的记录下来；二是pbi的梳理和优先级排序没有做。
针对上面的几个问题，作者给出了一个较为实用的答案：在sprint计划会议中使用索引卡而不是excel表。带来的好处有：
- 大家站起来四处走动，更长时间动保持清醒，注意力在会议进展；
- 每个人都有参与感，而不是被动接受信息；
- 多个故事可以同时编辑；
- 调整优先级非常容易；
- 会议中达成的共识可以直接以卡片形式实时产出；
- 调整完的内容可以直接放入看板。
准备在下一次的迭代计划会议中尝试一下。
2
在此前的“快速启动工作坊”中，团队对“故事内容是否能用技术术语”这个细节有过讨论，作者也描述了在pbi中不要使用技术术语来描述故事的原因：
- 指出该如何解决问题的应该是开发团队；
- po只需要关注业务指标；
- 即使po有技术背景，那也应该在描述清楚业务目标的前提下，在注解中写下技术描述。
不过我认为，现实情况下，互相补位是非常有必要的。如果po具备技术背景能用开发人员听得懂的描述方式来描述故事，应该对任务质量和开发效率都能起到正面作用的。
3
另外，作者对“质量”有一个有意思的定义。他将“质量”分为了“内部质量”和“外部质量”。“外部质量”是用户能明确感知到的，比如页面刷新慢、界面设计让人摸不着头脑等等；“内部质量”是指用户看不到的，比如代码可读性、测试覆盖率、系统架构设计的一致性等等，这些对系统的可维护性有深远影响。
作者认为：
- 内部质量不可妥协；
- 外部质量可由po决定重要性和范围。
在我们团队可能恰好相反。在“注重用户体验”的互联网时代，把“外部质量”放到很关键的位置我觉得是没问题的，但至少“内部质量”这块，在我们团队是有责任缺失的，需要好好反思。
4
最后，这本书很实践。在第十四章“我们怎样做测试”的最后一小节“回到现实”中，作者说：“也许你会认为：我们在所有的Scrum团队中都有测试人员，针对每个产品都有大规模的验收测试团队，在每个sprint结束以后都会进行发布，等等。其实，我们也没做到。我们有几次能成功的做到这种程度，也能看到它所带来的正面影响。但我们的质量保证过程想要得到认可，还有很长的路要走，我们仍有很多东西要学。”
没错，我们还有很长的路要走，我们仍有很多东西要学。
