11-12-14
第四章 我们怎样制定Sprint计划
步骤：参照Checklist
输入：…………
输出：
sprint目标
团队成员名单（以及他们的投入程度，如果不是100%的话）
sprint backlog
确定演示日期
确定每日例会的时间，地点
策略：
**PO必须参加
*PO必须参加。理由：
1，因为在Sprint会议中，PO需要根据团队的估计成果对最初的估计的范围和重要性进行调整。
2，PO需要回答团队提出的问题。
*如果PO不参加怎么办？
1，劝；2，找代表；3，换；4，推迟
**不能在质量让步
*不能在质量上让步。
理由：现在节省下来的一点时间，接下来的日子里你就要一直为它付出代价。
*如何识别质量让步。
“临时方案”这个词应当在你的脑中敲响警钟。
*如何处理？
让PO把范围缩小；
**限制Sprint会议的时间
如果超时，就打断。理由：
1，如果现在没有结论，延长一个小时仍然不会有结论。
2，会让下一个Sprint会议更有效率。
**sprint长度：2-4星期
短：频繁交付，容易反馈。
长：避免疲于应付演示。
**确定sprint目标
*必须确定sprint目标
理由：避免后期大家对于做什么感到迷惑。
*目标可能很愚蠢。
例子：挣更多钱；完成3个故事；打动CEO；为用户使用；
*挖掘目标的方法：
提问："我们为什么要进行这个sprint？为什么我们不直接放假算了？"
**决定sprint要包含的故事
*PO如何影响sprint的故事：
1，调整优先级。踢出一个故事；
2，缩小范围；
3，拆分故事；
**团队如何决定吧哪些故事放到sprint中
答案：本能估计+生产率计算
在生产率计算时需要考虑：投入程度+昨日天气。
步骤：先使用生产率计算，然后本能估计是否能完成（我要求他们暂时忘掉数字，感觉一下：在一个sprint里一口咬这么多东西会不会难以下咽。）。
**如何使用索引卡
从backlog上抄到索引卡上，会后将讨论的结果重写到backlog中。虽然浪费了一些时间，但是却能够提高sprint会议的效率，这还是值得的。
**定义“完成”
*是否包括测试？有些需要某人确认，比如“操作指南的完成的概念是被运营团队认可”，等等。
*如果你常常对怎样定义完成感到困惑，你或许应该在每个故事上都添加一个字段，起名为“何谓完成”。
**使用纸牌做时间估计
*每个人都要参加。理由：
1，不一定谁来实现；
2，每个故事由很多角色参加，比如美工，测试，因此……
3，确保每个人都对故事进行了理解。
4，容易发现估计差异。
*使用同时亮牌的方法。避免干扰。
*如果有分歧就进行讨论，而非取平均值。
*数字不是线性的，避免让我们误认为估计是准确的。如果需要准确的估计，就拆分故事。
**明确故事内容（很重要）
方法：
1，通过团队给出的评估点数，与PO的想法不同，进而得到分歧，进而澄清误会。
2，描述”如何演示“会发现团队与PO的认识的不同。
**拆分故事
我认为：1-2天。便于跟踪进度。
**把故事拆分成任务
自：总结一下任务：
1，需求、逻辑探讨；
2，界面和客户商量，以及反馈；
3，GUI设计；
4，GUI实现；
5，单元测试；
6，逻辑编码，重构；
7，数据库以及存储过程；
8，文档？可选
9，持续继承？可选
**每日例会时间
9，9：30，10。
**sprint会议优先级
1，确定sprint目标和演示日期；
2，经过团队认可的，sprint故事列表；
3，Sprint每个故事的估算值
4，每个故事的”如何演示“
5，生产率和资源计算；
6，每日例会时间。也可以有SM定，然后发送给大家。
7，故事拆分成任务。可以在每日例会中做。
**技术故事（很重要）
**bug和需求
把bug作为需求进行新的Sprint的讨论
＋＋＋＋＋![]()
第四章 我们怎样制定Sprint计划
步骤：参照Checklist
输入：…………
输出：
sprint目标
团队成员名单（以及他们的投入程度，如果不是100%的话）
sprint backlog
确定演示日期
确定每日例会的时间，地点
策略：
**PO必须参加
*PO必须参加。理由：
1，因为在Sprint会议中，
2，PO需要回答团队提出的问题。
*如果PO不参加怎么办？
1，劝；2，找代表；3，换；4，推迟
**不能在质量让步
*不能在质量上让步。
理由：现在节省下来的一点时间，
*如何识别质量让步。
“临时方案”这个词应当在你的脑中敲响警钟。
*如何处理？
让PO把范围缩小；
**限制Sprint会议的时间
如果超时，就打断。理由：
1，如果现在没有结论，延长一个小时仍然不会有结论。
2，会让下一个Sprint会议更有效率。
**sprint长度：2-4星期
短：频繁交付，容易反馈。
长：避免疲于应付演示。
**确定sprint目标
*必须确定sprint目标
理由：避免后期大家对于做什么感到迷惑。
*目标可能很愚蠢。
例子：挣更多钱；完成3个故事；打动CEO；为用户使用；
*挖掘目标的方法：
提问："我们为什么要进行这个sprint？
**决定sprint要包含的故事
*PO如何影响sprint的故事：
1，调整优先级。踢出一个故事；
2，缩小范围；
3，拆分故事；
**团队如何决定吧哪些故事放到sprint中
答案：本能估计+生产率计算
在生产率计算时需要考虑：投入程度+昨日天气。
步骤：先使用生产率计算，然后本能估计是否能完成（
**如何使用索引卡
从backlog上抄到索引卡上，
**定义“完成”
*是否包括测试？有些需要某人确认，比如“
*如果你常常对怎样定义完成感到困惑，
**使用纸牌做时间估计
*每个人都要参加。理由：
1，不一定谁来实现；
2，每个故事由很多角色参加，比如美工，测试，因此……
3，确保每个人都对故事进行了理解。
4，容易发现估计差异。
*使用同时亮牌的方法。避免干扰。
*如果有分歧就进行讨论，而非取平均值。
*数字不是线性的，避免让我们误认为估计是准确的。
**明确故事内容（很重要）
方法：
1，通过团队给出的评估点数，与PO的想法不同，进而得到分歧，
2，描述”如何演示“会发现团队与PO的认识的不同。
**拆分故事
我认为：1-2天。便于跟踪进度。
**把故事拆分成任务
自：总结一下任务：
1，需求、逻辑探讨；
2，界面和客户商量，以及反馈；
3，GUI设计；
4，GUI实现；
5，单元测试；
6，逻辑编码，重构；
7，数据库以及存储过程；
8，文档？可选
9，持续继承？可选
**每日例会时间
9，9：30，10。
**sprint会议优先级
1，确定sprint目标和演示日期；
2，经过团队认可的，sprint故事列表；
3，Sprint每个故事的估算值
4，每个故事的”如何演示“
5，生产率和资源计算；
6，每日例会时间。也可以有SM定，然后发送给大家。
7，故事拆分成任务。可以在每日例会中做。
**技术故事（很重要）
**bug和需求
把bug作为需求进行新的Sprint的讨论
＋＋＋＋＋