00.发布计划很重要原因：
a.她可以帮助产品所有者和整个开发小组判断他们在获得一个可发布的产品之前，必须花多长时间开发多少东西。产品越早发布，开发公司就可以越早开始获得他在此项目中投资的回报
b.发布计划传递了对于在多长时间内可能开发什么内容的期望。很多公式需要这个信息，因为它可以用于其他的战略规划活动
c.发布计划可以作为项目小组前进的路标。如果没有发布的概念，开发小组就会无止境地从一个迭代走向另一个迭代。
01.规划一次发布的部分工作是确定什么时候可以完成多少功能。
02.在进行发布规划时，我们并不想建立一个计划，指出将由哪个开发人员负责哪个用户故事或哪项任务，或者支持迭代中按什么顺序完成任务。在发布规划时建立那种细节水平上的计划是危险的，而且会产生误导。
03.要记住发布计划中的对象是用户故事，他们是对要交付的功能的说明，而不是要执行的独立的开发任务。在进行发布规划时，要吧用户故事分解成开发任务还为时过早，而且对某些用户故事的理解也不充分。
04.日期驱动(date-driven)的项目就是必须在特定日期发布，实现的功能可以协商的项目。而功能驱动(feature-driven)的项目则是我们希望能今早发布，但是某组功能的实现更为重要的项目。
05.产品所有者必须确定他想开发的功能的优先级。好的产品所有者会承担确定优先级的最终责任，但是会考虑开发小组的成员建议，尤其是有关开发顺序的建议。
06.发布计划是一个很好的高层次视图，显示了开发小组如何试图交付他们能够完成的最有价值的产品。
07.迭代计划是在迭代规则会议上制定的。产品所有者、分析员、程序猿、测试人员、数据库工程师和用户交互设计师等人都应该参加这个会议。把原始想法转变成功能的工作中所需设计的所有人员都应该参加这个会议。
08.
09.在我们一起来看要在迭代规划中完成的事情之前，重要的是先澄清一件不会完成的事。规划一次迭代时，任务不会分配给特定的个人。在迭代开始时候，睡将负责哪项任务可能会显而易见；但是，根据小组整体相对整个任务集的进度，一开始显而易见的事也许不会在迭代中发生。
10.在小组成员抱有“我们是一个整体”的态度时（小组成员会相互弥补其他人为完成的工作，并且知道别人对自己也会这么做），项目才会完成得最好。如果个人在迭代开始时就签订任务，这种做法与为达到迭代目标而做出统一的承诺是矛盾的。
11.发布计划是对整个产品发布过程的展望，通常是从新项目启动开始3-6个月的时间。与之相对，迭代计划知识对一次迭代的展望，通常是2-4周的时间。在迭代计划中，发布计划中的用户故事分解成了任务。对迭代计划中的用户故事进行估计时采用的是故事点或者理想日，而对迭代计划中的人物进行估计则是采用的理想小时。
12.迭代规划的主要目标是对粒度较粗的发布规划中建立的嘉定进行细化。
13.通过这些讨论，开发小组可以更好地理解应该和将要构建什么东西，他们还会建立为了达到此次迭代ide目标所需完成任务的列表。
14.速度驱动迭代
15.用户故事和主体的优先级是根据它们对产品的经济价值、它们的成本、小组可以学到的内容的量和重要性，以及减少的风险量来确定。
16.速度驱动的迭代规划中的下一步是确定开发小组的目标速度。在得到了优先级和目标速度之后，开发小组需要确定他们在迭代中想要达到的目标。这个目标简要地说明了这次迭代期间他们想完成的工作。
17.尽量明确直到养成习惯
新的敏捷开发小组往往不熟悉或者不能熟练编写自动化的单元测试。不过，在最初的几次迭代中，他们就可以逐渐培养出这一技能。
您需要为与项目有关的会议确定、估计并包含相应的任务。对会议进行估计的时候，一定要考虑所有参与者都需要花时间，还要考虑用于准备会议的时间。
敏捷开发小组的目标之一是在发现故障（bug）的迭代中就修复它们。
18.如果有负责这项工作的人做出估计，他的自豪感和自尊心可能会妨碍他在以后承认做出的估计不正确。如果估计是共同做出的，就不会存在这种对承认错误的不情愿。
19.承诺驱动是规划一次迭代的另一种方法。承诺驱动的迭代规划包含许多与速度驱动的迭代规划相同的步骤。但是，她不是使用“昨日天气”的方法来确定子啊当前迭代中应该规划多少个故事点理想日，而是要求开发小组吧用户故事逐个添加到迭代中，直到他们无法承诺完成更多的故事。
