《用户故事与敏捷开发》阅读笔记03
今天我读了《用户故事与敏捷开发》的第八，九，十，十一四章内容，第八章主要讲如何估算用户故事，也就是估算项目的一些功能需要多长时间能实现。作者指出故事点估算是一个很好的办法，故事点代表时间的模糊单位，不同的人对故事点的定义不同，也就是时间不同。故事估算应该有整个团队集体完成，原因有两条，一是故事还没有具体分配给个人，第二团队决定的估算可能比个人的估算更有用。一般来讲参加估算的人越多越好，每个开发人员写下自己的估算值，然后一起讨论为每个故事确定一个尽量让大家都满意的估算值，没有必要非要达成完全一致，当然客户也可以参加，但不能提出自己的估算，只是尽可能详细的解答开发人员的问题。三角测量是帮助团队验证他们没有逐渐改变一个故事点含义的有效方法具体做法是根据一个故事与其他一个或多个故事的关系来估算此故事。当采用迭代的方法来进行故事估算时，我们可以根据第一轮完成的故事点数，来预计以后迭代过程中迭代的长度。而团队是否结对编程，对故事点估算是没有影响的。
第九章讲发布计划，对于项目发布时间并不是一个准确的日期，一般是由开发人员和客户约定的一个日期范围，但作为开发人员，我们必须规划项目在第几轮迭代后要实现哪些功能。对于发布的项目要求哪些功能，作者给出了DSDN优先级排列的方法，有四个准则：必须有，应该有，可以有，这次不会有。“必须有”是指系统的基本功能。“应该有”是指很重要但短期内有替代解决方法的功能。“可以有的功能”是指如果没有时间可以在发布中不予考虑的功能，“这次不会有的功能”是指客户期望拥有但同时承认需要在后续发布中实现的功能。根据作者的介绍故事的优先级排列需要考虑很多因素，大家一直在讨论的一个问题，对于一个项目先做最有风险的部分，还是先做最有价值的部分，作者提出虽然很多时候人们倾向于先做有价值的部分，但最终还是要有客户决定，当然客户需考虑技术团队的意见。
第十章，迭代计划，迭代计划会议是客户为团队调整故事优先级的最佳时机。会议主要任务是开发人员将客户交代的故事充分理解，分解出任务，这有利于团队中每个人任务的划分，而对于每个人承担的任务，一般由自己认领，当然迭代期间，并不是一成不变的，根据实际要做出相应的调整，预想估算总是会不准确的。
第十一章，测量并监控速率，作者给出了项目测量速率的办法以及注意事项，在迭代中团队完成故事的总点数即是项目速率，但最初速率往往不准确，一般要经过两三轮迭代之后，才能获得一个长期的，比较稳定的速率。对于保证合理速率的办法是每轮迭代画出计划速率和实际速率而客户也需要每天与团队进行沟通，及时了解项目进行情况。除此之外，另一个监控进展的好办法是画出迭代燃尽图，表示每轮迭代末剩余的工作量，而且燃尽图还可以对团队进行自管理。鼓励团队成员准时完成任务。
