《敏捷软件开发实践：估算与计划》-读书笔记115-第13章 发布计划精粹
以下文章选自《无以名之》
《敏捷软件开发实践：估算与计划》第13章 发布计划精粹，重点和要点的思维导图及文字内容。
第13章 发布计划精粹
You improvise. You adapt. You overcome.
发布计划是建立很高层次的、覆盖超过一次迭代周期长度的计划的过程。一次典型的发布可能会覆盖 3~6 个月，而且根据迭代周期的长度，可能会包括 3~12 次或更多次迭代。
发布计划很重要的原因有以下三点：
一，它可以帮助产品负责人和整个团队判断他们在获得一个可发布的产品之前，必须花多长时间开发多少东西。产品越早发布（而且它在发布时越好），组织就有可能越早开始获得它在此项目中的投资回报。
二，发布计划传递了对于在多长时间内可能开发什么内容的期望。发布计划可用于所在公司其他战略计划活动。
三，发布计划可以作为项目团队前进的路标。发布计划提供了把迭代组合成一个令人满意的整体的相关上下文。通过发布计划可以让团队看到他们当前的期望最终到达哪里。
13.1 发布计划
计划发布的部分工作是确定在什么时间可以完成多少特性。有时，我们会先确定一个日期，再看在这个时间内可以完成多少特性；有时，我们从一组用户故事开始，看需要多少时间来完成它们。粗略地看，确定一次发布中可以包含多少工作，以及确定要实现哪些用户故事是一个非常简单的过程。
一，用计划出的迭代次数乘上团队预期的或历史的速度，就可以得到能够完成的工作总量。
二，选择合适这个工作量，能够完成的用户故事数量。
三，产品负责人和团队讨论所有的用户故事，确定它们的优先级，以便在确保工作总量不超过预期 的同时，交付尽可能多的价值。
发布计划本身常常被简单地记录成一个列表，列出项目将要开发的用户故事。在发布计划中建立详细的计划不仅危险且会产生误导。最好把由谁负责什么工作和活动顺序的决策交给开发团队。要记住，发布计划中的对象是用户故事，它们是对要交付的功能的说明，而不是要执行的独立的开发任务。
13.1.1 确定满意条件
很多项目使用进度、范围和资源作为项目是否能达到这些经济目标的主要指示器，即产品负责人的满意条件是由对进度、范围和资源目标的组合来定义的。产品负责人通常会在每次发布计划会议提出对这些因素的期望目标。虽然针对每个因素都会确定一个目标，但通常有一个是更突出的。
一般来说，项目要么是由日期驱动，要么就是由特性驱动。日期驱动（date-driven）的项目就是必须在特定日期发布，实现的特性可以协商的项目。特性驱动（feature-driven）的项目则是我们希望能够尽早发布，但是某组特性的实现更重要的项目。
13.1.2 估算用户故事
估算代表了开发用户故事的成本。不需要对所有特性都进行估算，只有那些具备合理的可能性，会被选中包含到即将来临的发布中的新特性，才需要分别进行估算。产品负责人的期望列表常常会延伸到未来的两次、三次甚至更多次的发布。我们并不需要对更遥远的工作进行估算。
13.1.3 选择迭代周期长度
大多数敏捷团队采用 2~4 周的迭代周期开展工作。时间更长或更短的周期都是可能存在的。计划一次发布时，需要选择合适的周期长度。
13.1.4 估算速度
如果团队曾经共同工作过，最好的办法一般就是使用他们最近表现出的速度。但如果采用的技术或针对业务的领域发生了显著变化，使用团队过去的速度可能就不合适了。
13.1.5 确定用户故事优先级
大多数项目要么时间太少，要么要开发的特性太多。一般不太可能在可用的时间内完成每个人想要的所有事情。产品负责人必须确定他想开发的特性的优先级。好的产品负责人会承担确定优先级的最终责任，但同时也会考虑团队其他成员的建议，尤其是有关开发顺序的建议。
13.1.6 选择用户故事和发布日期
在获得团队每次迭代开发速度的估算之后可以确定发布计划将有多少次迭代。
如果项目是受特性驱动的，我们可以对所有必需特性的大小估算值求和，然后除以预期的速度。这样就可以得到完成要求的功能所需的迭代次数。
如果项目是受日期驱动的，我们可以查看日历表确定迭代的次数。将迭代的次数乘以预期的速度可以告诉我们发布中可以有多少个故事点或是理想日。然后在用户故事的优先级列表中数出相应的故事点或理想日，了解在要求的时间内可以完成多少功能。
团队在制定发布计划时要讨论和决定发布计划应该有多详细的问题，通常有两个观点：
一，建立一个显示出在每次迭代中要开发什么的发布计划。
缺点：把特定的特性分配到特定的迭代需要花更多的时间。
优点：能提供额外的细节，有助于协调多个团队之间的工作。
二，只简单地决定在整个发布中要开发什么，而把每次迭代的具体内容留到以后再考虑。
缺点：提供的详细信息较少。
优点：需要的时间较少。
一个较好的折中办法是：确定最初 1~3 次迭代的具体工作，而把发布计划的剩余部分当成一个装下所有工作的大桶。
典型的发布计划会议中总是会有大量的讨价还价（give-and-take）和假设分析（what-if）的疑问。可以采用一个简单且最佳的操作方法是：让所有人都可以坐到一起，在 3×5 英寸的记录卡片或易事贴上写下用户故事或特性。计划一次发布时，产品负责人要选择具有最好优先级的对象放入第一次迭代。卡片可以堆叠或排列起来，显示哪些用户故事组成一次迭代。可以在桌子上或墙上排列卡片。
13.2 更新发布计划
发布计划完成之后，应该按照一定的频度对发布计划进行回顾和更新，而不要只把它存在某个地方或束之高阁置之不理。如果团队的速度保持得相当稳定，而且迭代计划没有产生什么出乎意料的事，你可能会长达 4~6 周都不用正式地更新发布计划。
13.3 例子
SwimStats 网站，通过市场研究，发现作为目标群的游泳教练和运动员希望得到产品待办列表中用户故事所说明的特性。
13.3.1 确定满意条件
4 个月以后将开始春季游泳赛季。SwimStats Web 站点的第一次发布应该在此之前 1 个月完成。这是一个日期驱动的项目：3 个月的时间内必须形成可以发布的东西，即使它可能只包含用于小游泳队的最基本功能。作为创业型公司，预算是固定的。项目要由公司的三名开发人员（1 个程序员、1 个数据库管理员和 1 个测试员）完成。
13.3.2 估算大小
负责这个项目的 3 个开发人员和产品负责人一起开会。开发人员提出有关用户故事的问题，而产品负责人则澄清每个故事的意图。团队选择采用故事点进行估算，并分配了估算值。
13.3.3 选择迭代周期长度
整个项目只有 3 个月的时间，产品负责人和开发人员一致认为 4 周的迭代周期太长。每个人都同意采用 2 周的迭代长度。
13.3.4 估算速度
3 个开发人员处理这个项目，他们预测的速度是每次迭代完成 8 个故事点。
13.3.5 确定用户故事优先级
产品负责人根据已经完成的市场研究确定了用户故事的优先级。
13.3.6 选择用户故事
这是一个日期驱动的项目，3 个月后发布，因此有 6 次 2 周长度的迭代，后面有 1 周时间备用。根据每次迭代 8 个故事点的估算速度，发布计划中可以包含 6×8=48 个故事点。
产品负责人按照他认为每个用户故事对 SwimStats Web 站点的首次发布所具有的价值进行了排序，把它们按照降序列在产品待办列表中。产品负责人可以选择 48 个故事点，从上往下，他总共选择了 46 个故事点。开发人员指出被产品负责人列为最低优先级的用户故事（作为系统管理员，我可以配置用户权限和用户组）实际上是必需的， 这个用户故事的估算值是 3，会导致整个发布的大小为 49，超出了计划的 48 点。产品负责人决定放弃最后一个估算为 8 点用户故事，这使得发布的大小减少到了 41 点。只要团队能够比进度提前 1 点，他就希望把放弃的那个 8 点的用户故事加回来。
13.4 小结
发布计划是覆盖了比一次迭代更长时间范围的高层次计划。大多数团队每 3~6 个月会进行一次发布。根据开发的软件类型不同，更频繁或更少的发布也不少见。最简单的情况下，发布计划是微不足道的：用预期的速度乘以计划的迭代次数，然后选择用户故事，让它们的大小估算值的总和充满这次发布。
发布计划并不需要精确说明在每次迭代中要完成哪些工作。通常很少会需要这么详细的程度。对大多数项目而言，指出第一次迭代中要处理的用户故事就足够了，可以把剩下的用户故事留到以后再按优先级分配到其他迭代中。
发布计划是一个迭代过程，首先要确定产品负责人对这个项目的满意条件。这些条件通常包括了在进度、范围和资源方面的目标。如果无法计划一个项目来满足最初的满意条件集，就需要重复计划过程，看能否满足一个缩小了的满意条件集；不然的话，可能推迟一些交付某些要求的功能；或采用一个更大的团队。一旦建立了发布计划，通常要在每次迭代开始时更新它。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
《敏捷软件开发实践：估算与计划》第13章 发布计划精粹，重点和要点的思维导图及文字内容。
第13章 发布计划精粹
You improvise. You adapt. You overcome.
发布计划是建立很高层次的、覆盖超过一次迭代周期长度的计划的过程。一次典型的发布可能会覆盖 3~6 个月，而且根据迭代周期的长度，可能会包括 3~12 次或更多次迭代。
发布计划很重要的原因有以下三点：
一，它可以帮助产品负责人和整个团队判断他们在获得一个可发布的产品之前，必须花多长时间开发多少东西。产品越早发布（而且它在发布时越好），组织就有可能越早开始获得它在此项目中的投资回报。
二，发布计划传递了对于在多长时间内可能开发什么内容的期望。发布计划可用于所在公司其他战略计划活动。
三，发布计划可以作为项目团队前进的路标。发布计划提供了把迭代组合成一个令人满意的整体的相关上下文。通过发布计划可以让团队看到他们当前的期望最终到达哪里。
13.1 发布计划
计划发布的部分工作是确定在什么时间可以完成多少特性。有时，我们会先确定一个日期，再看在这个时间内可以完成多少特性；有时，我们从一组用户故事开始，看需要多少时间来完成它们。粗略地看，确定一次发布中可以包含多少工作，以及确定要实现哪些用户故事是一个非常简单的过程。
一，用计划出的迭代次数乘上团队预期的或历史的速度，就可以得到能够完成的工作总量。
二，选择合适这个工作量，能够完成的用户故事数量。
三，产品负责人和团队讨论所有的用户故事，确定它们的优先级，以便在确保工作总量不超过预期 的同时，交付尽可能多的价值。
发布计划本身常常被简单地记录成一个列表，列出项目将要开发的用户故事。在发布计划中建立详细的计划不仅危险且会产生误导。最好把由谁负责什么工作和活动顺序的决策交给开发团队。要记住，发布计划中的对象是用户故事，它们是对要交付的功能的说明，而不是要执行的独立的开发任务。
13.1.1 确定满意条件
很多项目使用进度、范围和资源作为项目是否能达到这些经济目标的主要指示器，即产品负责人的满意条件是由对进度、范围和资源目标的组合来定义的。产品负责人通常会在每次发布计划会议提出对这些因素的期望目标。虽然针对每个因素都会确定一个目标，但通常有一个是更突出的。
一般来说，项目要么是由日期驱动，要么就是由特性驱动。日期驱动（date-driven）的项目就是必须在特定日期发布，实现的特性可以协商的项目。特性驱动（feature-driven）的项目则是我们希望能够尽早发布，但是某组特性的实现更重要的项目。
13.1.2 估算用户故事
估算代表了开发用户故事的成本。不需要对所有特性都进行估算，只有那些具备合理的可能性，会被选中包含到即将来临的发布中的新特性，才需要分别进行估算。产品负责人的期望列表常常会延伸到未来的两次、三次甚至更多次的发布。我们并不需要对更遥远的工作进行估算。
13.1.3 选择迭代周期长度
大多数敏捷团队采用 2~4 周的迭代周期开展工作。时间更长或更短的周期都是可能存在的。计划一次发布时，需要选择合适的周期长度。
13.1.4 估算速度
如果团队曾经共同工作过，最好的办法一般就是使用他们最近表现出的速度。但如果采用的技术或针对业务的领域发生了显著变化，使用团队过去的速度可能就不合适了。
13.1.5 确定用户故事优先级
大多数项目要么时间太少，要么要开发的特性太多。一般不太可能在可用的时间内完成每个人想要的所有事情。产品负责人必须确定他想开发的特性的优先级。好的产品负责人会承担确定优先级的最终责任，但同时也会考虑团队其他成员的建议，尤其是有关开发顺序的建议。
13.1.6 选择用户故事和发布日期
在获得团队每次迭代开发速度的估算之后可以确定发布计划将有多少次迭代。
如果项目是受特性驱动的，我们可以对所有必需特性的大小估算值求和，然后除以预期的速度。这样就可以得到完成要求的功能所需的迭代次数。
如果项目是受日期驱动的，我们可以查看日历表确定迭代的次数。将迭代的次数乘以预期的速度可以告诉我们发布中可以有多少个故事点或是理想日。然后在用户故事的优先级列表中数出相应的故事点或理想日，了解在要求的时间内可以完成多少功能。
团队在制定发布计划时要讨论和决定发布计划应该有多详细的问题，通常有两个观点：
一，建立一个显示出在每次迭代中要开发什么的发布计划。
缺点：把特定的特性分配到特定的迭代需要花更多的时间。
优点：能提供额外的细节，有助于协调多个团队之间的工作。
二，只简单地决定在整个发布中要开发什么，而把每次迭代的具体内容留到以后再考虑。
缺点：提供的详细信息较少。
优点：需要的时间较少。
一个较好的折中办法是：确定最初 1~3 次迭代的具体工作，而把发布计划的剩余部分当成一个装下所有工作的大桶。
典型的发布计划会议中总是会有大量的讨价还价（give-and-take）和假设分析（what-if）的疑问。可以采用一个简单且最佳的操作方法是：让所有人都可以坐到一起，在 3×5 英寸的记录卡片或易事贴上写下用户故事或特性。计划一次发布时，产品负责人要选择具有最好优先级的对象放入第一次迭代。卡片可以堆叠或排列起来，显示哪些用户故事组成一次迭代。可以在桌子上或墙上排列卡片。
13.2 更新发布计划
发布计划完成之后，应该按照一定的频度对发布计划进行回顾和更新，而不要只把它存在某个地方或束之高阁置之不理。如果团队的速度保持得相当稳定，而且迭代计划没有产生什么出乎意料的事，你可能会长达 4~6 周都不用正式地更新发布计划。
13.3 例子
SwimStats 网站，通过市场研究，发现作为目标群的游泳教练和运动员希望得到产品待办列表中用户故事所说明的特性。
13.3.1 确定满意条件
4 个月以后将开始春季游泳赛季。SwimStats Web 站点的第一次发布应该在此之前 1 个月完成。这是一个日期驱动的项目：3 个月的时间内必须形成可以发布的东西，即使它可能只包含用于小游泳队的最基本功能。作为创业型公司，预算是固定的。项目要由公司的三名开发人员（1 个程序员、1 个数据库管理员和 1 个测试员）完成。
13.3.2 估算大小
负责这个项目的 3 个开发人员和产品负责人一起开会。开发人员提出有关用户故事的问题，而产品负责人则澄清每个故事的意图。团队选择采用故事点进行估算，并分配了估算值。
13.3.3 选择迭代周期长度
整个项目只有 3 个月的时间，产品负责人和开发人员一致认为 4 周的迭代周期太长。每个人都同意采用 2 周的迭代长度。
13.3.4 估算速度
3 个开发人员处理这个项目，他们预测的速度是每次迭代完成 8 个故事点。
13.3.5 确定用户故事优先级
产品负责人根据已经完成的市场研究确定了用户故事的优先级。
13.3.6 选择用户故事
这是一个日期驱动的项目，3 个月后发布，因此有 6 次 2 周长度的迭代，后面有 1 周时间备用。根据每次迭代 8 个故事点的估算速度，发布计划中可以包含 6×8=48 个故事点。
产品负责人按照他认为每个用户故事对 SwimStats Web 站点的首次发布所具有的价值进行了排序，把它们按照降序列在产品待办列表中。产品负责人可以选择 48 个故事点，从上往下，他总共选择了 46 个故事点。开发人员指出被产品负责人列为最低优先级的用户故事（作为系统管理员，我可以配置用户权限和用户组）实际上是必需的， 这个用户故事的估算值是 3，会导致整个发布的大小为 49，超出了计划的 48 点。产品负责人决定放弃最后一个估算为 8 点用户故事，这使得发布的大小减少到了 41 点。只要团队能够比进度提前 1 点，他就希望把放弃的那个 8 点的用户故事加回来。
13.4 小结
发布计划是覆盖了比一次迭代更长时间范围的高层次计划。大多数团队每 3~6 个月会进行一次发布。根据开发的软件类型不同，更频繁或更少的发布也不少见。最简单的情况下，发布计划是微不足道的：用预期的速度乘以计划的迭代次数，然后选择用户故事，让它们的大小估算值的总和充满这次发布。
发布计划并不需要精确说明在每次迭代中要完成哪些工作。通常很少会需要这么详细的程度。对大多数项目而言，指出第一次迭代中要处理的用户故事就足够了，可以把剩下的用户故事留到以后再按优先级分配到其他迭代中。
发布计划是一个迭代过程，首先要确定产品负责人对这个项目的满意条件。这些条件通常包括了在进度、范围和资源方面的目标。如果无法计划一个项目来满足最初的满意条件集，就需要重复计划过程，看能否满足一个缩小了的满意条件集；不然的话，可能推迟一些交付某些要求的功能；或采用一个更大的团队。一旦建立了发布计划，通常要在每次迭代开始时更新它。
版权声明
本人所读图书的版权属于原著者和译者。这里仅为个人学习使用。但由本人学习整理所形成的音频、图片、文字和视频等的版权为本公众号拥有，任何人不得未经授权转载。
如果你觉得本文有用，欢迎分享给其他人。谢谢。
