（这只是开发不能如期完成时的解决方法之一，这种方法应该是在客户比较有诚意合作的前提下使用。）
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
总计 13
然后他还要挑出总和至少为0.5个故事点的故事。
但是如果“月销售报表”这个用户故事对客户来说也是非常重要，而且其他的故事也不能推迟，这时怎么办？这时我们就要试着简化这些用户故事。比如，原来“月销售报表”是要用一个第三方报表库来实现的，而且还要画出饼状统计图，如果我们只是生成简单的文本格式的报表的话（这格式应该可以被Excel导入，以便日后的处理）。那么这个用户故事的故事点就会从4减少到2，节省了2个故事点。如果客户同意的话，我们就可以将“打印月销售报表”分成两个用户故事“生成月销售文本报表”和“生成图形报表”，然后将后者推迟到下一个发布。
现在新的故事卡片出来了：
用户故事 故事点
卖饮料 4
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售文本报表 2
总计 15
还有其他的2.5个故事点要推迟，我们可以简化“卖饮料”。假设本来我们可以卖不同价格不同类别的饮料。如果现在我们只是简单支持一种价格一种类别的饮料的话，那这个用户故事的故事点可以从4减到2了。客户如果同意的话，我们就可以将“卖饮料”分割为“卖单一饮料”和“卖多种饮料”，然后将后者推迟到下个周期发布：
用户故事 故事点
卖单一饮料 2
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
安全警报 2
打印月销售文本报表 2
总计 13
现在还剩0.5个故事点，我们再考虑一下“安全警报”。假设本来这个故事是要同时触发本机上的警报，跟通知附近的一个警察局的。如果现在我们只是触发本机的警报，那所花的故事点就可以从2减到1了。于是在客户同意的情况下，我们将“安全警报”分割为“本机安全警报”和“通知警察”，然后将后者推迟到下个发布：
用户故事 故事点
卖单一饮料 2
取消购买 2
输入管理密码 1
补充饮料 3
取出钱箱里的钱 1
本机安全警报 1
打印月销售文本报表 2
总计 12
现在我们总计有12个故事点要做了（<=12.5）。上面这个筛选在本次发布的用户故事的过程，叫“发布计划编制”。
增加开发人员来满足发布期限
在上面的例子中，我们以推迟部分用户故事到下个发布周期的办法来解决问题。这种“控制开发范围”通常是最好的解决办法。不过，这种解决办法实施不了的情况下，那你就只好保留所有的用户故事，然后增加更多的开发人员了。在这个例子中，假定我们需要“n”个开发人员，才能在50天内完成17个故事点。50÷10×2.5×n÷2.算出来，n＝2.7，我们需要3个开发人员，也就是多加一个开发人员进来。不过注意：
团队人数加倍并不等于开发周期的减半。它可能只会缩短1/3。如果团队超过10个人的话，增加更多的人员可能反而会延缓项目的进度。
而且项目开发周期越长，团队内的成员对整个项目代码的熟悉度就越少，加上不确定的人员流动，新来人员的业务不熟等其他可能性，这项目会越来越复杂。
总的意思就是，项目人数不能太多，周期不能太长。
根据参考值来掌控项目
每个迭代周期2.5个故事点的这个参考值，只是第一个迭代周期的数据，第二个迭代周期可能会变成2或者3（一般是不会变动得太大）。假设是2的情况下，那对于第三个迭代周期，我们就要将参考值设为2，然后让客户以2为故事点总数来挑选用户故事。
对于大多数项目，参考值很快就会稳定下来（比如在几个迭代周期后）。当这个值稳定下来后，我们就要重新估计开发周期，重新进行“发布计划编制”了。如果这个参考值告诉我们，我们每个迭代周期可以做3个故事点的话，我们就要让客户挑选更多的用户故事放在这次的发布计划中。相反如果这个参考值是2的话，我们就要让客户减少用户故事（需要的话可以分割一些用户故事），如果团队人员还不多的话，可以增加更多的开发人员。
这是项目的初始阶段绝对要注意的。
发布计划编制，估算每个用户故事时要考虑哪些细节，忽略哪些细节？
在项目初始，我们要找出这个发布周期内所有主要的用户故事，评估每个故事的故事点。可是要怎么评估里面的细节呢？比如对于“卖饮料”， “卖饮料”这个简单的标题，省略了很多的细节：用户会投入什么样的钱？纸币可以吗？人民币可以吗？按钮的灯的亮度要多少？可不可以多个按钮对应一种饮料？按钮被按下以后，要不要变暗？找零钱是不是全部找10分的面额？
我们是不是要考虑上面所有的细节？对于按钮灯的亮度，我们就不用考虑了，它对我们的工作量没影响。不过，零钱的面额就对我们的工作量很有影响，我们要认真考虑一下（找一堆10分的零钱就很容易实现；如果要尽量减少零钱的个数就比较麻烦了）。处理不同币种也要考虑。
一般情况，我们不用太担心会漏过什么细节。对于每个用户故事，只要考虑一些“重要”问题就行了。当然，这里面的“重要”，就要根据经验以及客户的观点来决定了。
如果我们不好估算的话怎么做
如果我们觉得，这个用户故事不好估算，那可能的原因就是：
1. 这个用户故事太大。这种情况我们就可以将这个用户故事分割出若干个新的用户故事，比如：
将“卖饮料”分割出：
1：显示总投入金额。
2：金额够买的饮料对应的按钮灯亮起来。
3：按下亮灯的按钮，可以买到对应的饮料。
2. 我们之前从没开发过自动售货机的程序。因此，我们不知道开发这样的程序有多复杂。这样的话，我们就要做一些实验了，比如做一个让售货机找钱的小程序。这种试验就叫“spike”（翻译不出来）。
迭代周期内的计划编制
对于这个迭代周期内选择的所有用户故事，不像在发布计划编制那样，只是考虑一些重要的细节，现在我们要从客户那里调查到所有的细节。比如对于“卖饮料”，我们可能会在白板上画出用户交互的草图，然后跟客户一起讨论：
这是一台自动售货机……
用户投入硬币……
假设他投入的是50分，而价格是40分，那么按钮就会亮起（别忘了我们现在做的只卖单一饮料）
用户按一个亮起的按钮，一罐饮料会掉到售货机的出口
找零钱……
在跟客户详细讨论完，了解了足够的细节以后，我们才发现，事实上这个用户故事“卖饮料（只卖单一的）”的故事点远远比我们预计的要麻烦，这时候应该类似前面的发布计划编制那样，1、分割出小的用户故事，挑出一些放在下一个迭代周期内；或者2、挑出这个迭代周期内的一些用户故事放在下一个迭代周期。反之，如果发现这个用户故事比我们想像的还要简单，那我们就要增加更多的用户故事到这个迭代周期内。
用户故事只是跟用户交流的开始，而不是全部
假想现在已经从客户那边得到足够详细的需求了，我们可以开始实现了。注意，我们不用把所有用户提供的细节都记录下来。为什么呢？假设以后，你有点忘记用户故事，而客户又在你旁边，你是直接问客户，还是去找看需求文档找到你要的东西？当然是直接问客户了。客户可以提示更准确，更完整的需求给你。特别要注意的是，以后只要你一完成一个用户故事，你就要让客户看一下，或者实际的操作一下，因为客户对已经做的的东西了解得越多，那他就可以提供越准确越完整的需求。
用户挑选完用户故事以后，在之后的两个星期内，我们就要将这些用户故事逐个完成。每个用户故事我们都会设计结构，编码，测试等等。每做完一个用户故事，我们都要让客户验证一下系统是不是他所想的那样。
在这两个星期内，如果我们提早完成了用户故事，我们就要让客户挑更多的用户故事。相反的，如果我们不能及时完成，我们就要让客户知道当前的进度。
总结
我觉得这章的内容跟其他的软件工程书一样，看看，参考参考，具体的情况还是要具体的分析，不过这里面的用户故事（user story）跟故事卡片的概念就很不错，可以引用。
