提示：本文共有 1042 个字，阅读大概需要 3 分钟。
因为需要将每个用户故事按重要性分配到相应的迭代过程，所以每个迭代过程的时间就可以根据用户故事大致估算出来，所以要学会估算用户故事所需的时间。估算用户故事可以采用故事点估算的方法，这种方法的优点就是团队可以定义自己认为合适的故事点，可以根据自己团队的情况具体定义，比较灵活。正因为这个原因，有的团队倾向于用理想时间，有的团队则倾向于使用模糊时间。估算的主要目的之一是知道整个项目的工作量，通常将估算量换算成时间，而模糊时间需要考虑项目过程中可能出现的情况，所以采用理想时间更为简单。
进行估算时尽可能整个团队都进行参与，估算时需要客户将故事读给开发人员，开发人员要根据需要尽可能向客户提问，客户进行回答，如果不能回答需要另作处理。之后开发人员根据情况进行估算，经过几轮的讨论所有人达到一致。之后为了验证团队对故事点含义没有发生改变需要进行三角测量（即将故事按照估算的故事点数分类，查看各个故事的故事点数是否正确）。对于结对编程的团队来说可以以理想结对日或理想个人日来估算故事点，二者的区别只在于素速率值（一轮迭代中完成的故事点数）不同。
使用故事点时要正确使用需注意以下几点：1、每个团队对自己的故事点的定义是不同的，不能相互比较；2、如果一个故事被分割成多个小故事，小故事估算的故事点总和不必与大故事相同。
进行完估算后项目开始进行，在项目过程中需要进行产品的发布，所以制定发布计划就是必不可少的过程。
理想情况下，开发人员应该与客户谈一个发布的日期范围而不是一个具体的时间，所以发团队制定发布计划应该以一个可接受的日期范围为起点，以此来保证发布时间的灵活性。发布计划中还应包含有要发布功能，而这些功能取决于用户排列的故事的优先级，优先级较高的故事中包含的功能应该优先发布。而对于故事的优先级的排序是一个非常冗长复杂的过程，可以借助DSDM方法来排列。故事的排列顺序要从多个维度进行考虑：1、故事如果不能如期完成会有怎样的风险；2、推迟实现一个故事时给其他故事可能带来的影响；3、故事完成所需的成本；4、根据架构的需要；客户进行排序时则会考虑：1、故事对于客户的重要性；2、故事对于少数用户重要性。
项目过程中迭代长度要设置的尽可能短，方便项目随时进行调整，便于对项目进度的观察，并且尽量保持固定的迭代长度，有利于团队的开发速度。
所以在项目开始之前要对故事点进行估算，按照优先级分配到相应的迭代长度，每个迭代长度要尽可能短，发布计划应该以一个可接受的日期范围为起点，包括相应的功能。
看到此处说明本文对你还是有帮助的，关于“用户故事与敏捷开发方法笔记04”留言是大家的经验之谈相信也会对你有益，推荐继续阅读下面的相关内容，与本文相关度极高！
