如果我们不好估算的话怎么做

如果我们觉得，这个用户故事不好估算，那可能的原因是：

1.  这个用户故事太大。这种情况我们可以将这个用户故事分割出若干个新的用户故事，比如：
将“卖饮料”分割出：
1：显示总投入金额。
2：金额够买的饮料对应的按钮灯亮起来。
3：按下亮灯的按钮，可以买到对应的饮料。
2.  我们之前从没开发过自动售货机的程序。因此，我们不知道开发这样的程序有多复杂。这样的话，我们要做一些实验了，比如做一个让售货机找钱的小程序。这种试验叫“spike”（翻译不出来）。

迭代周期内的计划编制

对于这个迭代周期内选择的所有用户故事，不像在发布计划编制那样，只是考虑一些重要的细节，现在我们要从客户那里调查到所有的细节。比如对于“卖饮料”，我们可能会在白板上画出用户交互的草图，然后跟客户一起讨论：
这是一台自动售货机……
用户投入硬币……
假设他投入的是50分，而价格是40分，那么按钮会亮起（别忘了我们现在做的只卖单一饮料）
用户按一个亮起的按钮，一罐饮料会掉到售货机的出口
找零钱……

在跟客户详细讨论完，了解了足够的细节以后，我们才发现，事实上这个用户故事“卖饮料（只卖单一的）”的故事点远远比我们预计的要麻烦，这时候应该类似前面的发布计划编制那样，1、分割出小的用户故事，挑出一些放在下一个迭代周期内；或者2、挑出这个迭代周期内的一些用户故事放在下一个迭代周期。反之，如果发现这个用户故事比我们想像的还要简单，那我们要增加更多的用户故事到这个迭代周期内。

用户故事只是跟用户交流的开始，而不是全部

假想现在已经从客户那边得到足够详细的需求了，我们可以开始实现了。注意，我们不用把所有用户提供的细节都记录下来。为什么呢？假设以后，你有点忘记用户故事，而客户又在你旁边，你是直接问客户，还是去找看需求文档找到你要的东西？当然是直接问客户了。客户可以提示更准确，更完整的需求给你。特别要注意的是，以后只要你一完成一个用户故事，你要让客户看一下，或者实际的操作一下，因为客户对已经做的的东西了解得越多，那他可以提供越准确越完整的需求。
用户挑选完用户故事以后，在之后的两个星期内，我们要将这些用户故事逐个完成。每个用户故事我们都会设计结构，编码，测试等等。每做完一个用户故事，我们都要让客户验证一下系统是不是他所想的那样。

在这两个星期内，如果我们提早完成了用户故事，我们要让客户挑更多的用户故事。相反的，如果我们不能及时完成，我们要让客户知道当前的进度。

总结
　　我觉得这章的内容跟其他的软件工程书一样，看看，参考参考，具体的情况还是要具体的分析，不过这里面的用户故事（user story）跟故事卡片的概念很不错，可以引用。