11-12-14
第4部分 进度安排
前2部分主要介绍如何估计每个需求的规模，和如何确定优先级。本部分关注如何建立进度表。
首先是规划一次发布的主要步骤，然后是规划一次迭代的步骤。然后是确定规划长度的建议。以及估计小组效率和速度。
最后两章是针对复杂情况的，一是前提较少时如何规划项目，一是多个小组的规划。
第13章 发布规划基础【自：我觉得这章很好，而且没有什么的多余的话，因此值得直接使用书籍回忆。】
发布计划重要的原因/目的：
首先，提前确定发布的功能和发布的时间。
其次，对时间和功能的估计，可以方便进行其他活动的安排。
第三，可以作为路标。避免盲目的从一个迭代走向另外一个迭代。这让容易让团队失去激情。
13.1 发布计划
/|\ \|/
| |
----------------------------------------------------------------------------------------------------------------
13.1.1 确定满意条件
13.1.2 估计用户故事的规模
13.1.3 选择迭代周期的长度
13.1.4 估计速度
13.1.5 确定用户故事优先级
13.1.6 选择用户故事和发布周期
13.2 更新发布计划
13.3 例子
第14章 迭代规划
目的：提供可供小组用于驱动迭代中会发生的工作的短期，更为详细的视图。小组需要知道那些事情是必须的。
策略：
*在迭代会中确定。
*需要团队全员参加。
*使用Excel记录。使用任务卡片管理。
理由：
*迭代规划时不分配任务给特定的个人。
理由：
#实际可能不是某人完成。
#失掉“我们是一个团队”的概念。
速度驱动与承诺驱动
速度驱动：
步骤：
1，团队调整故事优先级。
*来自市场的变化和反馈。
*来自迭代会议的反馈。
2，团队确定速度。
*昨日天气。
3，团队选择迭代目标（目标就是一个概括的说明而已）。
*不需要十分精确。
4，团队选择具有最高优先级的支持该目标的故事。
5，拆分任务。
*只包含为此项目增加价值的工作。（例如：不要包含：回复邮件，开会，等等。但是它们要计算在“投入率”上）。
*尽量明确直到习惯。例如，如果没有习惯单元测试，则就把单元测试作为一个任务明确的表示出来，以免忘记。如果日后已经成为习惯了，则可以去掉该类任务，因为我们会在开发时习惯性的进行测试。
*考虑到会议（很重要）。
*Bug。开始不算，后来算故事。
*处理依赖性。如果依赖性变化，就需要重估工作量。
*难以分割的工作。考虑“占位符”。
6，对任务进行估计。
*任务估计以理想时间估计。
*共同估计。
理由：
#未必由指定的某人实现。
#别人帮助提醒。
#差异可以发现问题。
#自尊心。
*可以进行一些设计。否则无法分配任务以及估计。
*合适规模。1-2天。
理由：
#流
#避免瓶颈。
#每天汇报。
另外，学习“占位符”。
＋＋＋＋＋![]()
第4部分 进度安排
前2部分主要介绍如何估计每个需求的规模，和如何确定优先级。
首先是规划一次发布的主要步骤，然后是规划一次迭代的步骤。
最后两章是针对复杂情况的，一是前提较少时如何规划项目，
第13章 发布规划基础【自：我觉得这章很好，而且没有什么的多余的话，
发布计划重要的原因/目的：
首先，提前确定发布的功能和发布的时间。
其次，对时间和功能的估计，可以方便进行其他活动的安排。
第三，可以作为路标。避免盲目的从一个迭代走向另外一个迭代。
13.1 发布计划
- 发布计划包括哪些内容：【自：根据性价比确定时间+功能】
规划一次发布的部分工作是确定在什么时间可以完成多少功能。 有些时候，我们会先确定一个日期， 在看在指定时间内能完成多少功能。而另一些时候， 我们会确定一组功能，看看需要多长时间。【自： 该过程可能要反复几次，并可能要将结果想上级汇报，并反复调整。 】 - 注意问题一：避免细节：【自：避免安排人员，分解成任务，
安排顺序】 记 住发布规划不是计划，不需要列出由哪个开发人员负责哪个用户故事或哪项任务， 或者指出在迭代中按什么顺序完成任务。在建立发布规划时候， 那种细节水平上的 计划是危险的，而且会产生误导。 最好把对由谁负责什么工作和互动顺序的决策留给负责这些负责这些 任务的人员，并且尽可能的推迟。 - 注意问题二：面向的对象：【自：单位是用户故事，而非任务】
要记住发布计划中的对象是用户故事，而不是任务。这些工作在“ 迭代规划”中完成。 - 具体形式：【自：即故事列表+额外信息】
发布计划本身常常被简单的记录成一个列表， 列出项目将要开发的故事。 很自然的，只要项目，公司和工作环境允许， 您就可以再发布计划中包含额外的信息。例如， 您也许会希望传达一些隐藏在计划下的关键假设。最值得注意的是： 小组 有哪些成员，迭代周期有多长， 第一次迭代开始以及最后一次迭代结束的日期。第21章“ 与计划有关的沟通”中将介绍跟多有用的信息。 - 主要步骤：以下为主要步骤：
| 确定满意条件----> | 估计用户故事的规模----> | 可以按照任意顺心进行： 选择迭代周期长度 估计速度 ----> 确定用户故事优先级 | 选择用户故事和发布周期 |
/|\
|
------------------------------
13.1.1 确定满意条件
13.1.2 估计用户故事的规模
13.1.3 选择迭代周期的长度
13.1.4 估计速度
13.1.5 确定用户故事优先级
13.1.6 选择用户故事和发布周期
13.2 更新发布计划
13.3 例子
第14章 迭代规划
目的：提供可供小组用于驱动迭代中会发生的工作的短期，
策略：
*在迭代会中确定。
*需要团队全员参加。
*使用Excel记录。使用任务卡片管理。
理由：
*迭代规划时不分配任务给特定的个人。
理由：
#实际可能不是某人完成。
#失掉“我们是一个团队”的概念。
速度驱动与承诺驱动
速度驱动：
步骤：
1，团队调整故事优先级。
*来自市场的变化和反馈。
*来自迭代会议的反馈。
2，团队确定速度。
*昨日天气。
3，团队选择迭代目标（目标就是一个概括的说明而已）。
*不需要十分精确。
4，团队选择具有最高优先级的支持该目标的故事。
5，拆分任务。
*只包含为此项目增加价值的工作。（例如：不要包含：回复邮件，
*尽量明确直到习惯。例如，如果没有习惯单元测试，
*考虑到会议（很重要）。
*Bug。开始不算，后来算故事。
*处理依赖性。如果依赖性变化，就需要重估工作量。
*难以分割的工作。考虑“占位符”。
6，对任务进行估计。
*任务估计以理想时间估计。
*共同估计。
理由：
#未必由指定的某人实现。
#别人帮助提醒。
#差异可以发现问题。
#自尊心。
*可以进行一些设计。否则无法分配任务以及估计。
*合适规模。1-2天。
理由：
#流
#避免瓶颈。
#每天汇报。
另外，学习“占位符”。
＋＋＋＋＋