软件开发中的Scrum框架应用技巧 —— 第二部分

卡片链接

许多软件团队使用Scrum，但这也带来了一些挑战。虽然它起源于软件开发，但它的创造者们使它足够通用，可以在各个行业中使用。其理念是，团队应该在坚持核心原则的同时适应和改进。但在现实中，这种情况却很少发生。相反，团队却常常陷入僵化的流程，完善仪式而忽视实际需要，而不是根据自身需求调整。

另一个重要的结果是，Scrum 更侧重于管理，而忽略了工程实践和基础。但如果没有坚实的工程实践和基础，Scrum 在软件开发中几乎无法运作 [Fowler09]。

在这一系列中，我们将调整Scrum方法以更好地适应软件开发的需要，并将必要的工程实践环节融入其中。

在第一篇文章中，我们探讨了如何让每日站会更加高效——专注于解决阻碍，并只跟踪重要的任务。我们还建议不要将待办事项的条目拆分为诸如开发、测试或支持这样的通用任务。我们建议只有在将任务部署到生产环境后才算完成。这可能会引发更多问题。

我们应该怎么把它们分解呢？用很多小而有实际价值的任务，在有依赖的情况下，我们如何完成这些任务？另外，我们如何命名这些任务，既清晰又不会引起混淆，同时传达最多的信息？

咱们来搞定这些问题吧。

之前我们谈到过追踪价值而不是活动本身。听起来理论不错，但在实践中呢？却没那么简单。Scrum 团队在一个固定的迭代周期中工作，通常为两周。为了适应一次冲刺周期，团队需要将 PBIs（产品待办事项）分解成更小的单元。而这正是团队经常感到棘手的地方。

最简单——也是最吸引人——的方式来分配任务是根据实现任务。这可以细分成无数部分，细到每一行代码。但这种方法也有一些问题。

让我们来看一个例子。假设我们有一个PBI：“通过与第三方PSP（支付服务提供商）集成，提供信用卡在线支付功能。”经过头脑风暴，团队将其分解成了以下任务：

• 实现信用卡在线支付
• 与第三方PSP集成
• 实现支付接口
• 测试支付功能

• 记录集成和支付过程

• 支付页面的UX。
• 后端: 集成 PSP API 接口。
• 后端: 创建 PAYMENT_LOG 数据表。
• 测试。

乍一看，这可能对开发人员来说没问题。但对于产品经理、工程经理或同事的工程师们来说，这已经太难懂了。第二天一开工，开发人员可能会采取不同的方法。这可能会让一些工单还没开始就已经过时了。

即使预期的业务结果明确（但并不总是如此），实施过程中也会学到很多新东西，不断调整和适应新情况。提前设定好的步骤很快就会变得不再适用，需要不断地做出调整。

不知不觉，“活动票”开始在看板上堆积起来，尤其是负责汇报的成员更是摸不着头脑。然而，我们需要追踪我们向Sprint目标的进度。这导致了冗长且令人沮丧的站会和状态会议。

另一个问题？假进展的感觉。团队完成了很多小任务，给人一种进展的错觉。进度看起来不错；工程师经理们也满意。然而，这些数据并不能真正反映项目的进度。

这种方法最大的问题在于它强迫我们采用瀑布模式。直到团队完成所有的工单，系统才具备任何可用性。这阻碍了验收测试、假设验证和实验。团队无法提前交付原型来观察合作伙伴如何使用。如果项目经理需要三个月后才能看到任何有意义的结果，他们怎么开展工作？

原文:

试着根据验收标准来拆分功能需求点（PBI）。这里有一些拆分的指导原则。

• 按 CRUD 操作（创建、读取、更新、删除）拆分。
• 按正常流程和边缘情况拆分。正常流程通常足以满足概念验证（PoC）或甚至生产发布。例如，可以跳过对支付方式限额的处理，返回一个通用错误信息，之后再用更具体的错误信息来细化。
• 按平台或设备拆分。先支持最简单的设备，之后再扩展到其他设备。
• 按角色或用户画像拆分。先聚焦于最重要的角色，将次要角色留待后续处理。
• 按数据规模或范围拆分。先从较小且不复杂的用户数据开始，逐步扩展到更大、更复杂的案例。
• 按功能级别拆分。先实现基本的功能，如简单的字段或算法，之后再增加更复杂的特性。
• 按地理区域拆分。由于各国本地支付方式不同，这可以成为一种自然的拆分方式。

你也可以用这些方法来进行拆分：

• 每个句子都可以独立成为一个故事。
• 有列举，每个项目都可以独立成为一个故事。
• 有像‘和’或‘或’这样的连词，它们连接的每一部分都可以独立成为一个故事。

在我们这个例子中，将PBI（产品待办事项，Product Backlog Item，PBI）拆分成几个小故事的一种可能方法是，比如：

• 用户应能够选择单张发票并通过信用卡在线进行全球范围内的支付。
• 用户应能够选择单张发票，并在线通过信用卡进行全球范围内的支付。
• 荷兰用户应该能够通过iDEAL支付多张发票。
• 中国用户应能够通过微信支付多张发票。
• 支付成功后，应给合作伙伴发送确认邮件至他们的电子邮箱。
• 用户应能够保存其支付详情，以免重复输入。

上述建议并不是唯一的可能方案。你应该考虑在你的环境中什么才是有意义的。例如，在我们的环境中，首先实现单张发票的支付是有意义的，因为它已经满足了95%合作伙伴的需求，并且在流程上与支付多张发票有很大区别。按国家和支付方式拆分也很有帮助，因为不同的支付方式有不同的表现。

即使我们在中途更改实现方式，票据保持不变。产品经理（PM）可以在功能准备好后进行验收测试或演示，以便尽早获得反馈。

最大的优势在于团队可以推出MVPs（MVP）来验证想法。在上述例子中，第一个票已经让我们能够验证从头到尾的流程，并满足我们95%的客户需求。即使在交付第一个票后，我们不得不转向另一个关键功能，我们仍然产生了大部分的效果。

虽然有一个需要注意的点。问题是，如果你将高层次的PBI分解为许多小故事，你通常不能把这些小故事部署到生产环境。如果你不能把这些小故事部署到生产，你将失去快速反馈。不过，有一种方法可以对抗这个问题。接下来我们再聊聊这个。

想象你已经根据验收准则将PBI拆分了。

• （在荷兰）合作伙伴应能够选择一张发票并通过信用卡在线支付。
• …
• 支付成功后，应该发送一封确认邮件给合作伙伴的电子邮件地址。

有些故事可以立即发布，这真是太好了！但通常，你不能单独发送每个故事。以确认信息为例，每次支付成功时，它必须发送出去。

你可能会被诱惑把“支付成功”和“电子邮件”放在一起。看起来更简单，对吧？但这样结果会出现那些拖拖拉拉数周或数月的巨大任务，团队成员在依赖关系上纠缠不清，导致进展缓慢。最终，事情开始走偏，大家开始合并任务，生怕出错。到这一步，还何必拆分任务呢？

一个简单的解决办法是放松对“完成”的定义。可以将任务视为完成，只要它进入测试或预发布环境。但这种方法带来的问题远比它解决的问题多。这不仅会弄乱你的环境，使得流程更加复杂，还会最糟糕地延迟有价值的客户反馈。

源链接 一个好的“完成”的定义是增量已经上线。

这就是功能标志发挥作用的地方。它们很容易被采用，并且确实能让工作拆分变得有效，或者说让工作变得更容易管理。

如果一个故事一开始不可立即发布，将其隐藏在功能标志后面，这样。一条简单的规则，却能产生重大影响，因为它允许在分解故事时无需考虑任何依赖关系。

相信我，这笔小投资会让每个人的生活更轻松。下面要说的这是让Scrum真正生效的工程实践。

重要的是要强调，仅仅因为它[Scrum]并没有排除技术活动的重要性，并不表示它认为这些活动不重要。—— 马丁·福瓦尔 [松散的冲刺 ].

功能标志不仅能够解决依赖关系的问题。当需求在开发过程中发生变化时（这种情况总是会发生的），或者中途发现了一些意想不到的问题，功能标志也能发挥作用。你可以发布那些已经可以正常工作的部分，而不必暴露那些还在开发中的部分。

功能标志在采用主干分支开发、持续交付和部署自动化时不可或缺。这些做法预示着高交付效率。

话说，但也别太过了。如果标志位太多，最终你会得到一个混乱且难以维护的代码库。在必要时使用它们，但也要规划工作，从而可能根本不需要这些标志位——比如先搞定确认邮件。并且，请在完成后清理旧标记。虽然这会有些小麻烦，但权衡之下——更快的发布、更顺畅的合作以及更好的风险控制——是值得的。

你应该能一眼看出团队在任何时刻都在忙些什么。我们是不是被太多bug淹没了？我们是不是在技术任务上投入了太多精力？我们当前的工作范围是否健康平衡，既有新特性也有改进？要达到这种透明度，不妨试试这个简单的办法。

首先定义关键工作项类型。对于大多数团队来说，三种类型就足够了：新功能的故事、用于修复缺陷的错误和用于保持长期稳定的技术改进。故事展示了为客户增加价值的工作，这可以是一个功能性特征，也可以是一个非功能性改进，比如更好的安全或性能。错误专注于解决影响用户的已知问题或事件。技术改进有助于减少技术债务，清理过时的功能，或支持未来的开发，即使对客户没有立即的影响。

图1 你应该能够一眼看出团队在任何时刻正在做什么。从图中可以看出一个健康的平衡：特性工单（绿色）、几个缺陷（红色）和技术改进（蓝色）。

一旦识别出这些类型，就可以将它们与您的 JIRA 任务对应起来。为了更清晰明了，您可以为这些任务添加颜色编码。我喜欢用绿色表示功能，红色表示缺陷，蓝色表示技术改进。这样，一眼就能看出团队的重点所在。如果红色太多，可能需要重新考虑优先级。如果全是蓝色，客户可能会开始怀疑何时能看到新特性。保持这种平衡可见，有助于做出更好的决策，而不会增加额外的流程负担。

我们希望我们的团队看板能够被每个人（包括团队成员、利益相关者和领导层）轻松理解。有时我们需要回顾过去的情况，这可能是为了进行回顾或年终评估。已完成工作的记录也应该清晰明了。

如果我们只追踪那些价值增加的任务单的话，那么我们本来就应该有一个清晰的看板，以及完成的任务记录。不过，我们还是可以稍微改进一下。

这里有一些建议供你参考。

票名最好不超过8到10个字。因为过长的名字会被截断，所以票名要简短但信息要丰富。

使用诸如用NL代替荷兰的缩写，用COO代替所有权转移，使名称更短。

图2 票名应足够短以适应卡片空间。JIRA会截断过长的名字以适应显示。

在开头添加最重要信息，因为展示时结尾文本更可能被隐藏。

票名必须突出其附加价值。它应该突出关键差异化和限制，比如功能或地域。票名不应过于模糊或过于狭窄。以故事“合作伙伴应该能够选择单张荷兰的发票并通过信用卡在线支付”为例。票名“荷兰单张发票在线支付”比“改善支付体验”更好。前者更准确地捕捉了票的核心要点——用户每次只能支付一张荷兰的发票。

除非这些细节是验收条件的一部分，否则工单名称不应决定解决方案或实现细节。这在处理bug时尤为重要。我们通常在对问题了解不充分时创建一个工单。因此，解决方案可能与我们最初设想的方案有所不同。所以，最好根据事实或症状来命名问题。

想象一下，当你遇到一个用户报告称在尝试打开一个页面时遇到内部错误的情况。即使你确定这是一个验证问题，你也应该根据实际情况来命名它。所以，与其叫作“合作伙伴列表加载出错”，你应该叫作“在打开页面xxx时遇到内部错误”。

技术任务常常过于笼统且缺乏具体范围，从而导致问题。常见的工单比如“清理代码”、“提升性能”和“重构代码”等。谁能说得清这些工单下面具体做了什么！这通常反映了我们在先前文章中提到的另一个问题——不关注价值，而关注过程。确保你明白自己在做什么，了解验收标准，并将工单分解得更明确一些。确保你的任务名称能传达足够的验收标准信息。

在大多数情况下——不包括 bugs——ticket 通常应该与 Epic 相关联。在 Agile 看板上，JIRA 会在 ticket 卡片上显示 Epic 名称。这提供了额外的上下文，让卡片可以显示更多信息。

优秀的团队并不会拘泥于某种框架，而是根据自身需求定制它。他们会试验、调整和优化他们的工作方式。每个团队都有其独特之处，而且每个团队一年前的状态和现在也都不相同。持续改进不是可有可无的，而是至关重要的。昨天有效的流程可能明天就不适用了，而最优秀的团队不断进化。方法论提供指导，但要使这些方法有效，是一个持续不断的努力过程。归根结底，成功的关键不在于选择“正确”的流程，而在于不断改进你当前使用的流程。