硝烟中的Scrum和XP读书笔记
CH1-1 Scrum不是方法学，它是一个框架。
CH1-2 Scrum 的强大和令人痛苦之处就在于你不得不根据自己的具体情 况来对它进行调整；
CH2-1 产品Backlog中包含了：
故事、特性、需求+优先级
并且是用用户的术语的表达；
CH2-2 how to demo实际是对用户故事的细化，是设想的用户操作场景，可以作为用户故事的验收准则。
CH2-3 指出如何解决问题的应该是开发团队， 产品负责人只需要关注业务目标 ；多问为什么来澄清业务目标。
CH3-1 在迭代策划会议之前：
PB要准备好；
Story的优先级确定好；
PO要充分理解了需求。
CH3-2 PO确定story的重要性，其他人不可以。
CH4-1 举办 Sprint 计划会议，是为了让团队获得足够的信息，能够在几个 星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信 心。
CH4-2 每个故事都含有三个变量，范围(scope)和重要性(importance)由产品负责人设置。估算 (estimate)由团队设置。
CH4-3 迭代策划会议上，团队从最重要的 故事开始逐一讨论每个故事，一一估算时间。
CH4-4 在某些情况下，团队对故事做出的时间估算，跟产品负责人的想法 不太一样。这可能会让他调整故事的重要性;或者修改故事的范围， 导致团队重新估算，然后一连串诸如此类的后续反应。
CH4-5 如果PO不想参加策划会议怎么办？
说服他；
换掉他；
代表他；
等待他；
CH4-6 内部质量与外部质量：内部质量好，外部质量未必好，内部质量差，外部质量肯定差。
CH4-7 永远保证内部质量！即使外部质量差，也要保证内部质量！
CH4-8 Scrum 中的一切事情都有时间盒。 会按照时间盒安排工作，学会制定合乎情理的时间盒，这对会议 长度和 sprint 长度同样有帮助。
CH4-9 可以为spriint计划会议定义一个详细的日程表，但并非强制的。
CH4-10 短的 sprint=短反馈周期=更频繁的交付=更频繁的客户反馈=在错 误方向上花的时间更少=学习和改进的速度更快。
CH4-11 产品负责人一般会喜欢短一点的sprint，而开发人员喜欢时间长的 sprint。所以sprint的长度是妥协后的产物。
CH4-12 确定了自己最喜欢的长度之后，就要在长时间内坚持住。
CH4-13 一定要有迭代目标。
CH4-14 用业务术语表达迭代目标，便于团队外的人理解。
CH4-15 如果PO想要尽早实现的故事没有被放在本次迭代中，他可以：
改变优先级；
裁减选中的故事的范围，减少功能，以便于能把想尽早实现的故事纳入进来；
拆分选中的故事，将不重要的部分替换掉；
CH4-16 如果 sprint 时间不长，小团队根据直觉进行估算可以收到很好的效果。
CH4-17 把事情完全做完，即达到可以交付的状态，否则，它的价值就是 0(也许还会是负数)！
CH4-18 “昨日天气(yesterday’s weather)”技术的两个条件（并非绝对）:
团队已经完成了几个 sprint；
会以几乎完全相同的方式(团队长度不变， 工作状态等条件不变)来进行下一个 sprint。
CH4-19 如果没有昨日天气，则先估计一个值作为参照物。
CH4-20 最原始的故事索引卡片远比电子表格更能让大家都参与进来。
CH4-21 不同类型的故事完成标准可能不同。
CH4-22 在策划会议上对故事理解最深刻的人往往首先发言，这影响了其他人的观点。
CH4-23 我们必须提醒团队成员，他们要对这个故事中所包含的 全部工作进行估算。而不是“他们自己负责”的部分工作。测试人 员不能只估算测试工作。
CH4-24 故事是可以交付的东西，是产品负责人所关心的。任 务是不可交付的东西，产品负责人对它也不关心。
CH4-25 实施TDD时，每个故事拆分的第一个任务几乎都是编写测试程序，最后一个任务几乎都是重构。
CH4-26 技术故事可以转为用户故事，或者作为用户故事的一个任务。
CH4-27 透明是scrum的核心价值，尽量不要对PO隐藏什么。
CH4-28 迭代策划会议结果的优先级：
优先级 1:sprint 目标和演示日期。
优先级 2:经过团队认可、要添加到这个 sprint 中的故事列表。
优先级 3:Sprint 中每个故事的估算值。
优先级 4:Sprint 中每个故事的“如何演示”。
优先级 5:生产率和资源计算，用作 sprint 计划的现实核查。包括 团队成员的名单及每个人的承诺(不然就没法计算生产率)。
优先级 6:明确每日例会固定举行的时间地点。
优先级 7:把故事拆分成任务。
CH5-1 通过一个简短的信息公告让公司的其他同事了解项目组的进展。
CH6-1 管理sprint backlog的最有效方式是物理的看板！
CH6-2 非工作日不体现燃尽图的横坐标上。
CH7-1 大多数最有趣最有价值的设计讨论，都是 在任务板前面自然而然地发生的。
CH7-2 预留一个白板作为设计墙：设计草图，顺序图，GUI原型，领域模型等。
CH7-3 团队成员坐在一起：互相听到，互相看到，隔离噪音。
CH7-4 如果SM同时也是行政主管，那么就要给团队留出自管理的时间。
CH8-1 在开站会时，更新任务板。
CH8-2 站会迟到，就要被惩罚。
CH8-3 始终记得，让团队成员自愿地领任务，而不是派发任务。
CH8-4 如果有人不积极主动，就考虑赶鸭子上架。
CH9-1 Sprint演示可以督促团队真正完成一项工作，获得反馈，展示给其他团队我们的进展，激励或鞭策团队。
CH9-2 Sprint 演示不关注怎么做，不关注细节，不需要准备，不需要演讲，聚焦于目标，聚焦于完成的功能。
CH9-3 不便于演示的功能或非功能需求可以展示测试报告。
CH10-1 回顾可以避免重复犯错。
CH10-2 找一个专门的房间来回顾，让大家都能集中精力参与进来。
CH10-3 如果估计的生产率与实际生产率差别比较大，应该做原因分析。
CH10-4 可以用圆点投票法选出最终需要落地的措施。
CH10-5 跨团队之间可以互相旁听回顾会议，以进行经验教训的分享。
CH11-1 在两次迭代之间留出休整的时间。
CH12-1让团队来做估算。
CH12-2 不要让他们花太多时间做估算。
CH12-3 粗略估算，而不是承诺。
CH12-4 估算时留有时间缓冲，以避免糟糕的时间估算、未预期的问题和 未预期的特性等造成影响。
CH13-1 结对编程值得尝试，但并非强制，可以把代码审查作为结对编程的替代方案 。
CH13-2 TDD与持续集成都是强烈推荐的实践。
CH14-1 应该有验收测试阶段，但是要缩短时间。
CH14-2 开发人员常常都是很差劲的测试人员。尤其是他们测试自己代码的时候。
CH14-3 测试人员不说完成，则该工作就是未完成。
CH14-4 如果测试人员根本不会编程，他可以跟开发人员结对。好的测试人员常常能想出多种不同类型的测试，可以和开发人员互补。
CH14-5 旧功能中的缺陷优先级高于新需求的优先级。
CH15-1 要想拆分小团队，必须确保他们彼此之间不会产 生互相干扰!
CH15-2 多团队的spring节奏保持一致。
CH15-3 多个团队协同时，需要有总体的需求与团队的协调人。
CH15-4 多团队的产品负责人只有1个，SM可以有多个。
CH15-5全能团队，全能个人。
CH15-6 尽量避免兼职成员。
CH15-7 Scrum of scrum 可以每天开，也可以每周开。
CH15-8 多团队的站立会议可以错开时间，便于产品负责人参加。
CH15-9 救火团队专门用来处理缺陷，屏蔽干扰。
CH16-1 远程窗口处理异地开发。
CH16-2 聚焦日：每周一天在家办公。
2019年7月18日