虽然大家都知道设立冲刺目标很有价值，但确切地怎样制定这些目标，对许多人来说却是一件让人头疼的事。冲刺目标应该在冲刺待办列表确定之前就存在吗？如果你的产品待办列表上排在最前面的任务看起来没什么联系，你该怎样从中提炼出一个冲刺目标？冲刺待办列表上的所有任务都必须和冲刺目标直接相关吗？
虽然网络上有很多优秀的文章提供了思考冲刺目标的概念模型，但将这些理论应用到实际工作中，很多人仍然感到困难。
因此，本文将分享一个真实产品开发过程中的故事，以及我们在这个过程中制定的一些冲刺目标。通过分析这些真实的案例，我们希望能帮助大家更深入地理解设立冲刺目标背后的逻辑思考，以及这个过程是如何影响冲刺待办列表的排序和任务的细化的，反之亦然。
项目背景
本文讲述的是开发一个能够通过一个统一平台访问一系列相关人力资源产品（包括我们自有的和合作伙伴的）的过程。这些产品涵盖了从工时记录到开发票，从招聘到人员规划等各个方面。这个新产品旨在解决用户需要使用许多不同的产品来处理各种任务的问题，每个产品都有自己的登录界面、仪表盘和购买流程，这让人非常头疼。
一个专门的Scrum团队负责这个产品的开发，尽管团队成员在这一年多的时间里有所变动，但产品的维护工作仍然由他们来完成。最初，冲刺的周期设定为两周，后来调整为一周。这个团队是跨功能的，囊括了需求分析、视觉设计、测试、开发和质量保证等各个方面的能力。
团队的完成定义包括了团队在每个冲刺结束时至少要完成的所有必要条件。这包括：
- 确保网页中没有失效的链接或不起作用的按钮；
- 确保网页上不会出现临时的文本或图片；
- 确保网页能在最新版本的Firefox、Chrome和Safari浏览器上以及在一系列移动设备上正常运行；
- 按照测试金字塔编写自动化测试；对所有业务逻辑编写单元测试，通过集成测试验证整个系统，以及通过UI测试来验证关键用户路径；
- 确保每个任务都经过了对相关和常见的OWASP攻击的验证。这一点在后期的冲刺中部分自动化了；
- 确保任务的代码得到了团队内其他人的同行评审，并且有另一个人验证了该任务按照规格说明书的要求正常工作；
- 确保任务被部署到了生产环境。
注意：本文只是对实际工作过程的一个粗略和不完整的概述。为了简化描述，我们省略了一些细节，并且略去了一些商业敏感信息。
产品与开发策略
在项目启动前，我们通过故事地图绘制了工作的大致框架。故事地图上的每一栏都代表了工作流程中的一个步骤，比如从网站到网上商店，再到仪表板等，总共有十二个步骤。基于此，我们为开始的几个冲刺制定了一个初步策略：
- 首先，构建一个简易的网上商店，至少能展示产品目录，让客户能购买单个产品；
- 然后，搭建一个仪表板，可以将不同产品的功能组件整合在一起，展示重要的信息；
- 接下来，扩充网上商店的功能，支持复杂的购买行为，如购买多个许可证和用户；
- 最后，为大客户提供定制化的产品版本；
这一策略为前几个冲刺的目标提供了指导。随着我们的不断学习，产品待办列表也在不断更新。
我们从一开始就同意要尽可能频繁地发布到生产环境。
冲刺1的目标：建立部署管道并向生产环境发布一个空白网站
我们一致同意要尽量频繁地进行生产部署。产品负责人希望尽早看到投资回报，不能等几个月才上线。我们也希望能通过公开的网站收集真实的反馈。这促使我们始终保持高标准的质量。因为手动发布流程可能导致发布延迟或为了省事而跳过一些重要的检查，所以我们从一开始就决定自动化这一过程。
由于这是第一次冲刺，我们还需要建立开发和生产环境。我们希望至少能向生产环境部署一小部分功能，哪怕只是为了证明我们的基础设施和部署流程是可行的。
以下是最终进入冲刺待办列表的任务：
- 在团队房间的墙上用便利贴创建冲刺待办列表和产品待办列表；
- 设置生产环境的服务器（包括数据库）；
- 建立一个构建服务器，用于编译提交，运行单元测试，并打包部署；
- 配置一个分布式服务总线（NServiceBus）；
- 在部署到生产环境前自动备份数据库；
- 建立一个空的API，连接到一个空的数据库；
- 在部署到生产环境前自动运行API的集成测试；
- 创建并部署一个空的Angular网站，连接到空API，显示部署版本；
冲刺期间我们遇到的问题
我们发现，建立基础设施对于单个冲刺来说有些过于雄心勃勃。我们与产品负责人协商，决定先只设置两台服务器。不过，建立初版的部署管道使得之后添加更多服务器变得更容易。
我们最终决定在网站上添加了logo和联系信息，还有页脚中的部署版本信息，这让网站看起来更完整。
从利益相关者的角度看，冲刺审查的内容相当有限。就工作软件而言，我们只展示了一个基础的、带有logo和页脚的网站。实际上，我们在冲刺审查期间还进行了一些调整，并且（自动）部署了这些更改。
冲刺期间的细化工作
在知道下一个冲刺会专注于主页后，设计师已经开始进行视觉设计工作了。同时，我们也具体分析了主页需要完成的各项任务。这一阶段的关键是把接下来要做的事情尽量简化到最基本，而把其他所有事情先放到产品待办列表的后面。
冲刺2的目标：在首页展示热卖产品
进入第二个冲刺，我们的目标是探索并设计在网上商店中如何展示产品。经过与产品负责人的讨论，我们决定制作一个只展示精选产品的主页。虽然潜在客户还不能直接通过网店购买产品，但至少我们可以提供一个选项，让他们留下联系信息以便我们联系他们。我们选择了10个最重要的产品作为目录的内容，因为我们暂时不想在搜索和浏览更大的产品目录上花费太多时间。这个目录会直接上传到数据库中，我们希望首先了解如何最有效地组织产品数据，然后再开发管理这些数据的后台环境。
以下是一些被列入冲刺待办列表的任务：
- 根据视觉设计制作HTML样式指南；
- 配置Bootstrap来在主页上应用基本的样式元素；
- 确定商店中的10个最关键产品，并收集它们的详细信息及图片；
- 在数据库中为这些选中的产品建立并填充产品表格；
- 开发一个页面，让访问者可以查看选中产品的详细信息；
- 在各种现代浏览器上测试主页；
- 为每个产品添加一个基础的“回电我”按钮，让潜在客户可以留下他们的电话号码；
- 向生产环境部署（多个服务器）
冲刺期间我们遇到的问题
我们发现，与我们最初的验收标准相比，产品详情页面在添加了超过三张图片后的效果更好。但是，要添加更多的图片库需要做大量的工作。因此，我们与利益相关方协商后，决定暂时只保留三张图片。我们在产品待办列表中增加了添加更多图片的选项。
在冲刺审查会议上，利益相关方对如何展示产品信息提供了宝贵的反馈。比如，他们觉得产品描述太长了（“我没时间读这么多”）。我们也因此对如何组织产品信息有了更深入的了解。尽管这些建议很有用，但并没有被放在产品待办列表的最前面。
在架构方面，这个冲刺也验证了我们是否能将网上商店部署到多个服务器上。每个服务器实例都有自己的产品目录副本，并且使用CQRS模式来保持它们同步。虽然目前还没有扩展的需求，但这是我们从一开始就在考虑的。
冲刺期间的细化工作
在这个冲刺结束后，理论上我们可以继续扩大产品目录，这会让我们有机会探索如何实现分页、搜索和排序等功能。但是，考虑到已有许多成熟的解决方案可供参考，而且利用我们使用的Angular框架来实现这些功能相对容易，我们选择不走这条路。相反，我们决定着手解决更为复杂的订单处理流程。因此，我们的重点转移到了明确我们需要完成订单处理流程所需的具体工作上，设计师甚至为此绘制了订单处理流程的初步草图。
冲刺3的目标：让访客能够订购产品
大体上，客户需要完成三个步骤来订购产品：1）选择产品，2）填写地址和账单信息，3）完成支付。我们发现了几个特殊情况，比如有些客户不能使用信用卡支付，需要开具发票；有些特定国家的客户需要获得许可后才能购买；还有一些产品是按用户授权，而其他是按产品授权的；最后，不是所有类型的信用卡都被接受或允许使用。
我们首先决定支持通过Stripe进行信用卡支付，因为这是最常见的支付方式。稍后会实现接收发票的选项。我们还决定暂时只关注产品许可，以避免现阶段处理按用户许可的复杂性。最后，我们决定不设购物车功能，因为在我们当前的销售流程中，客户往往一次只购买一种产品。
以下是被列入冲刺待办列表的一些任务：
- 下订单后，向销售部门发送电子邮件；
- 允许客户通过信用卡（通过Stripe）支付订单；
- 在审计日志中记录支付失败的情况，以便我们能追踪潜在的滥用行为；
- 当用户购买产品时，将他们的许可记录在一个独立的服务中；
- 对订单中的敏感用户信息（例如，电子邮件、地址）进行加密处理；
冲刺期间的细化工作
有了一个基本可行的订单处理流程后，我们计划扩展产品目录，吸引更多客户进行实际购买。这不仅对业务发展至关重要，还让我们有机会更好地了解客户如何使用订单处理流程。我们认为，这些信息对于指导未来冲刺中的工作将非常有价值。因此，设计师再次提前一步，开始设计更广泛的产品组合。
通过实际操作订单处理流程，我们获得了许多洞见。例如，我们遇到的问题比最初预期的还要多。
冲刺期间我们遇到的问题
实施订单流程的过程中，我们学到了很多，发现了一些之前没预料到的问题。比如，我们发现某些信用卡验证需要一天时间，虽然这种情况很少发生，但我们必须找到一种方法来处理这个问题，同时确保用户仍然可以完成购买。我们还遇到了一个挑战，即如何在没有真实信用卡的情况下测试这个流程。Stripe支持使用多种测试用的假信用卡，但我们也需要在我们的流程中加以适应。
从技术角度来看，我们注意到订单流程的连续性（即从点击下单到填写客户信息、账单信息再到确认订单的流程）有时并不适合背后服务的异步性。信用卡验证的问题就是一个例子，但我们还遇到了其他问题。例如，有一个服务负责追踪许可证，但这个服务是异步更新的。这意味着，理论上，如果动作足够快，可能会购买到两份相同的许可证。我们在这个冲刺中找到了一个临时解决方案，并在产品待办列表上排前位置添加了一个任务项，计划以后找到一个更可靠的解决方法。
冲刺4的目标：扩大产品目录以包含更多产品
有了基础的订单流程之后，产品负责人觉得下一步最有价值的事情是将更多其他产品和附加组件加入目录中。虽然订单流程确实需要进一步改进以适应更多场景，但它在当前的形态下是有效的。如何最好地展示我们全部的产品、模块和附加组件（大约30个左右），产品负责人对此感到不太确定。
- 收集我们全部产品的信息（包括图片和描述）；
- 允许访客通过关键词和产品类型搜索目录；
- 每次只展示10个产品，让访客可以在页面间前后导航；
- 将每个产品显示的图片数量增加到10张（而不是三张）；
- 解决订单流程中的一个重大问题（虽然这个问题与冲刺目标无关，但足够重要）；
冲刺期间我们遇到的问题
我们发现附加组件的多样性远超预期。因此，我们与产品负责人合作，决定现在先添加最重要的附加组件，并将其他的附加组件加入到产品待办列表中。我们利用了一些（虽然是粗略的）销售数据来指导这一决策。
在冲刺审查会议上，我们让利益相关方使用假信用卡来体验购买带有附加组件的产品。我们只是简单地把鼠标和键盘交给他们。这实际上为用户体验的潜在改进提供了宝贵的洞见，因为人们不知道在流程结束时应该做什么。一个开发人员在订单流程结束时加入了动画效果的彩带庆祝，这个小细节得到了利益相关者的赞赏。
冲刺目标的变化
在项目开始的几个冲刺之后，我们设立了一些目标，比如：
- 让销售部门可以管理产品目录；
- 允许客户通过OpenID实现各产品的单点登录；
- 为两个最常用的平台创建带基本功能的仪表板；
- 购买后帮助客户设置和配置产品A；
- 购买后帮助客户设置和配置产品B；
- 允许用户使用预付积分下单；
- 把面向用户的网站和消息翻译成用户的语言。
虽然这些目标可能不都是完美的，但它们为冲刺期间的开发工作提供了方向。每个目标都指引我们根据需要从产品待办列表中挑选和重排序工作。
这种对目标的关注与在项目最后才发布产品的方式有所不同。在后者的情况下，开发团队可能会首先关注基础设施、架构、登录机制和全球化支持，然后才是网上商店和仪表板。这种方法更多地关注目前技术上最具挑战性或最有趣的事情，而不是当前最有价值的事情。
价值与不确定性之间的权衡
我们始终在两个需求之间寻找平衡：我们怎样才能提供最大的当前价值？我们对即将到来的工作了解有多少不确定性？在一些特殊情况下，我们会使用冲刺目标来简化我们未来的工作，正如我们在第一个冲刺所做的那样。
那么，冲刺目标是先有的还是冲刺待办列表先有的呢？实际情况并非那么简单。产品负责人和开发团队之间总是会有持续的对话，通常在细化过程中讨论下一个冲刺最有意义的目标是什么。
这不仅指导了冲刺目标的制定，也指导了冲刺待办列表的选择。在挑选工作和决定我们能承诺完成的冲刺目标规模时，我们总是会问自己：“什么是最常用的？”和“现在最有价值的是什么？”发现，通过这两个问题来缩小范围到冲刺结束后绝对必须发布的内容，是非常有效的。其他的工作可以留到以后再做。
