（书摘：用户故事与敏捷方法）第九章 发布计划

     大部分软件项目以每2到6个月为一个新的发布周期，这是最好的。以产品的开发路线图开始规划发布通常很有帮助，路线图展示未来几个新发布中关注的重点。这个产品的开发路线图毫无疑问会不断改变------这是我们所期望的，因为这些改变标明我们更加了解自己的产品，它的市场以及我们开发产品的能力。

     产品的开发路线图可以很简单，它可以是未来几个发布要关注的重点列表，或者像Kent Beck所称的“主题”。

     一旦得到了这些问题的答案，就可以通过估算团队能在每轮迭代中完成多少工作来计划发布了。利用我们能在一轮迭代中完成多少工作量来估算，我们可以做一个合理的预测，即完成符合用户期望的发布需要多少轮迭代。

 

小结

• 在计划发布时，有必要知道客户预期的大致发布日期和故事的相对优先级。

          理想情况下，开发人员和客户可以谈一个日期范围，而不是一个具体日期。

• 故事应该以明确的顺序排列（第一个，第二个，第三个等等），而不是利用诸如“非常高，高，中等”模糊顺序的分组。

          为了一个计划一个发布，客户必须排列故事的优先级。把故事分成诸如高优先级，中优先级和低优先级这三种类型是很有用的，但这会导致乏味冗长的争论，会针对某个故事是高优先级还中优先级而争论不休。幸运的是，我们可以借用来自DSDM的方法，它是另一种敏捷过程。

           DSDM包括一个排列优先级的方法，称之为莫斯科(MoSCoW)规则。MoSCoW是以下短语的缩写：

           必须有（Must have）

           应该有（should have）

           可以有（Could have）   

           这次不会有（Won't have this time）

           “必须有的功能”是指系统的基本功能。“应该有的功能”是指很重要但短期内有替代解决方法的功能。如果项目没有时间约束，通常认为应该有的功能是强制性的。“可以有的功能”是指如果没有时间就可以在发布中不予考虑的功能。列为“不会有的功能”是客户期望拥有但同时承认需要在后续发布中实现的功能。

•   故事的优先级由客户确定，但也要考虑开发人员的想法。

            开发人员实现故事时会有一个顺序，就像客户所期望的那样。当客户和开发人员对这个顺序有不同意见时，最后每次都应该是客户说了算。

            但是，客户在没有从开发团队那里获得某些信息之前，很难确定故事的优先级。至少，客户要知道每个故事需要大约多久才能完成。在确定故事的优先级前，应该先估算它们，并且在故事卡上写下估算。

            此时，客户不会把对故事的估算加起来，然后决定一个发布中包括什么，不包括什么。而是利用这些估算，结合自己对于每个故事价值的评估，把故事进行优先级排序，使交付给自己公司的价值最大化。一个特别的故事对于客户公司可能极有价值，但需要花一个月时间来开发。一个不同的故事可能只有它一半的价值，但可能要只要花一天时间就能开发完。

            使用混合优先级。如果客户在确定一个故事的优先级时遇到问题，可能需要分割这个故事。分割故事能使客户对故事的优先级排列出不同的优先级。

            高风险故事。敏捷方法旗帜鲜明地支持先做最有价值的部分。这让敏捷项目能够避免过早地解决风险，同时也推迟了可能并不需要的一些基础性代码的开发。赞同先做最有价值的部分，还能使项目可能尽早发布，那时只提供最有价值的功能。但是，即使以价值优先为向导，我们在排列优先级时仍然需要考虑风险。许多开发人员倾向于先做风险最高的故事。有时这是恰当的，但这仍然必须由客户决定。然而，在排列故事优先级时，客户应该考虑技术团队的意见。

            根据架构需要安排优先级。

• 使用速率将以理想日为单位的估算转换成日历日。

          假设客户已经安排好所有故事的优先级。团队累加每个卡片的估算，总共有100个故事点。使用故事点使得估算故事变得更加容易，但现在我们需要一种方法，将故事点转换成项目的预计工期。

          答案当然是使用速率。速率代表一轮迭代中能完成的工作量。一旦知道团队的速率，就可以用它将理想日转变成日历日。例如，假设故事项目需要100个理想日，如果速率是25，我们就可以估算出完成项目需要100/25=4轮迭代。

• 估算团队的初始速率很有必要

          可以通过下面的方法获得初始速率。

          -- 使用历史值

          -- 执行一轮初始迭代，使用那轮迭代的速率

          -- 猜测

          如果我们需要猜测速率，这种方法至少应该是言之有理的，能清楚地跟别人解释。幸运的是，确实有合理方法的，并且定义大约一个理想工作日为一个故事点。

           如果故事点是一个理想工作日，我们可以通过估算完成一个完整的理想工作日实际需要多少天籁估算初始速率。在迭代过程中，团队显然会受到许多干扰，阻止团队享受理想日。因为有干扰，把一轮迭代三分之一到一半的开发日作为预计速率是很常见的。

• 创建发布计划

         因此，如果项目有100个故事点，若估算的速率是每轮迭代20个故事点，则可以预计总共需要5轮迭代。发布计划的最后一步是把故事分配到每轮迭代中。客户和开发人员一起协作，选择优先级最高的20个故事点，并且将它们放入到第一轮迭代中。下一组次高优先级的20个股试点放入第二轮迭代中，如此进行直到分配完所有的故事。

         取决于团队是否在同一地点工作，以及组织所需要的规范，有许多方法可以沟通发布计划。例如，我用过以下方法：

• 对于工作在一起的团队，我把故事卡钉在墙上，用列来表示迭代。
• 对于记录在电子表格中的故事，我根据它们的迭代进行排序，然后再每轮迭代的最后一个故事后画一条厚重的粗线。
• 对于有兴趣的远程利益相关者，我复印记录卡给他们。
• 对于有兴趣的，比较讲究形式的远程利益相关者，我给他们创建简单的甘特图。

• 警告

          小心，不要太迷信发布计划！本章描述的方法将帮助你估算项目所需要的大致工期，让你可以声明“在5~7轮迭代后，可以准备发布产品”。但是，这些方法不足以精确说明“我们会在6月3日完成”。

 

开发人员职责

• 负责提供信息（有时包括基本假设和可能的替代方法）给客户，以帮助她排列故事优先级。
• 负责在基础性或者架构性需求与其他客户需求之间取得权衡，避免不切实际地提高基础性需求或架构性需求的优先级。
• 建立发布计划，负责在实际估算的基础上，适当包括一定长短的时间用以项目缓冲。

客户职责

• 负责以自己对故事价值的估计来确切排列用户故事的优先级。把故事排列为高，中，低这三个优先级是不够的。
• 负责诚实地表达发布期限。如果在7月15号需要，请不要为了保险起见而告诉开发人员6月15号就需要。
• 负责理解理想日和日历日的不同。
• 在想对故事的不同组件排列不同的优先级时，负责分割故事。
• 负责了解为何不应该谴责活批评一位个人速率为0.6的程序员，只因为她的速率小于1.0。