硝烟中的Scrum和XP 读书笔记
1、注意：产品负责人之外的人也可以向产品backlog中添加故事，但是他们不能说这个故事有多重要，这是产品负责人独有的权利。他们也不能添加时间估算，这是开发团队独有的权利。
2、使用纸牌进行时间估算。（书46）
------------Sprint计划会议------
1、举办Sprint计划会议，是为了让团队获得足够的信息，能够在几个星期内不受干扰地工作，也是为了让产品负责人能对此有充分的信心。
2、，Sprint计划会议会产生一些实实在在的成果：
?? sprint目标。
?? 团队成员名单（以及他们的投入程度，如果不是100%的话）。
?? sprint backlog（即sprint中包括的故事列表）。
?? 确定好sprint演示日期。
?? 确定好时间地点，供举行每日scrum会议。
2、Sprint计划会议产品负责人必须参加（原因参考书27），如果产品负责人不愿参加的解决方案。
3、Sprint计划会议长时间讨论不出结果，解决方法定下时间盒，在这个区间内讨论出结果（参考书30）
4、Sprint计划会议日程安排样例见（书31）
5、Sprint演示日期是sprint 计划会议的产出物，它被确定下来以后，也就确定了sprint的长度，一般3个星期，可以根据实际情况调整。
6、每次sprint计划会议都要确定sprint目标。半死不活的目标也比啥都没有强。这个目标可以是“挣更多的钱”，或者“完成优先级排到最前面的三个故事”，或“打动CEO”，或“把系统做的足够好，可以作为beta版发布给真正的用户使用”，或“添加基本的后台系统支持”等等。它必须用业务术语表达，而不是技术词汇，让团队以外的人也能够理解。
7、在sprint中包含多少故事由团队决定，而不是产品负责人或其他人。
团队怎么决定把哪些故事放到sprint里面？
产品负责人怎么影响他们的决定？（书34）
8、团队怎么决定把哪些故事放到sprint里面？
本能反应；（询问是否能实现，凭开发人员经验给予回答）；
生产率计算；
9、生产率计算；
--》昨日天气（yesterday’s weather）
当前的sprint：可用 人--天 * 投入程度 = 估算生成率（估算的完成故事点 人--天）
---》投入程度（是一个估算值，通过前几个sprint的平均，若是第一个sprint则取个估算值如70%）
前几个sprint的：实际完成 人--天 / 可用 人 --天 = 投入程度
10、“任务”和“故事”的区别
故事是可以交付的东西，是产品负责人所关心的。任务是不可交付的东西，产品负责人对它也不关心
11、sprint计划成果：按优先级从高到底 ：sprint目标和演示日期 、经过团队认可、要添加到这个sprint中的故事列表、Sprint中每个故事的估算值、Sprint中每个故事的“如何演示、生产率和资源计算，用作sprint计划的现实核、明确每日例会固定举行的时间地点、把故事拆分成任务。
--------------Sprint演示-------
1、Sprint演示注意事项 （书 82）
----------sprint回顾----------
1、sprint回顾 注意事项 （书84）
---------------
1、在质量上不能让步，产品负责人可能想牺牲质量换取时间，不可取，解决方法（参考书28），可以抽取部分低级功能为单独一个故事点，放到以后实现。
2、报告工作内容，让公司知道工作情况（书60）
3、如果没有任何事情需要测试，那测试人员该做什么？（书109）
4、sprint解决过往sprint中留下的bug的方法？（书114）
----------疑问-------------
1、如果产品负责人想把故事点A加入sprint，但是A又关联B、C，而同时把B、C加入sprint无法完成，这种情况怎么办？
2、如果团队决定把A加入sprint，但负责A的队员说无法完成（有故意拖长时间的嫌疑）怎么办？
3、一个团队只有一个产品经理（通常应该是甲方人吧），这个产品经理能理解整个企业的所有业务吗？
4、故事那么多，要分解的任务那么多，一次完成分解吗？不太现实吧。
一个团队只有一个产品经理（通常应该是甲方人吧），这个产品经理能理解整个企业的所有业务吗？不太现实吧，需求不可能都从他那里得到吧，开sprint计划会议的时候涉及到比较细的任务时，他能理解那么细的业务么，是不是得甲方提供需求的人员参加，而不是单单一个产品经理？
5、sprint计划 时 团队所有人员参加，但不是每个人都熟悉所有的业务。
