怎样在Scrum中分解产品待办项目: 10种强大策略

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/chktsang/article/details/96283890

已经掌握了Scrum的团队知道,成功的关键在于产品Backlog的及时,日益完善和工作细分。他们更喜欢带有许多小(功能)项目的Sprint Backlogs,而不仅仅是几个大项目。较小的项目可以改善流量,并降低冲刺失败的风险。

在本文中,我将解释为什么分解工作很重要,以及为什么应该跨职能而不是僅由尖端技术来完成。我将提供10个有用的策略,让Scrum团队用来分解工作

为什么以及何时分解产品待办项目

软件开发本质上是不可预测的。积压的一些产品待办事项(PBI)需要比预期更多的挑战,而其他项目风险较細。因此,如果冲刺的工作只包含一些大项目,那么低估工作甚至只是单个项目将可能对冲刺产生深远的影响。而且,由于较大的项目往往难以估计和理解,因此短跑失败的可能性会进一步增加。

经验丰富的Scrum团队花费时间和精力将大型PBI分解为较小的故事。虽然他们有时会在规划新冲刺期间这样做,但他们已经了解到这种“精炼”过程应该是连续的,以便使冲刺 - 特别是冲刺计划 - 运行得更顺畅。因此,当冲刺正在进行时,该团队还会花时间分解PBI用于下一个冲刺,甚至可能是后面的1-2冲刺。但这是以“适時” (Just-in-time) 的方式完成的,因此团队花费的时间越来越少,冲刺的步伐亦会越来越快了。

这种分解工作的过程提高了共享理解,提高了估算的准确性,并促进了产品负责人的工作优先次序。但要做得好并不容易,并且需要练习“适时” (Just-in-time) 进行。值得庆幸的是,敏捷社区已经设计了许多有用的策略来将工作分解成更小的部分。

为什么垂直分解优于水平分解?

从广义上讲,有两种方法可以分解大型PBI。第一种方法称为 “横向分解”,涉及根据需要完成的工作或涉及的层或组件来分解故事。因此,必须为UI,数据库,某些组件,前端和测试完成的工作分为Backlog中的技术项目。这在Scrum中不能很好地工作,原因如下:

  • 单个项目不会产生可用的,可证明的软件:假设一个团队在sprint中处理网上商店的订单流程。如果他们将水平分割PBI,他们最终将完成设计,数据库,前端和测试的工作。虽然这些项目肯定较小,但它们并不能自行提供工作软件。毕竟,只有UI完成时,或者只修改了数据库时,新功能才能生效。如果没有足够的测试,上线也是一个坏主意。因此,单个项目不会导致工作不能产生可用的软件和 - 通过扩展 - 产生商业价值。只有所有工作的组合完成及集成后才能产生商业价值。但只有完成所有任务。这通常是一个问题,正如本段下一点的解释那样;
  • 增加瓶颈,而不是减少瓶颈:水平分解通常伴随着“筒仓思维” (Silo Thinking)。每个成员都取自软件开发所需的一个孤岛 (Silo)。设计人员将负责设计,数据库人’将设置数据库,开发人员’编写代码,测试人员’进行测试。如果团队成员所擔當的角色不可互换(使用这种方法通常就是这种情况),很有可能出现瓶颈。如果设计人员无法按时完成工作,这将影响设计后面的任务。由于团队成员无法互相帮助,每次延迟,问题或中断都会影响整个冲刺;
  • 水平切片无法区分优先级:如果产品所有者包含水平切片,那么产品负责人如何确定优先顺序?由于这些项目都不能自行提供商业价值或工作软件,因此产品负责人将无法确定工作的优先顺序。切片很可能是技术性的,这会在产品负责人和团队之间产生距离和误解;

虽然PBI的横向分解将导致较小的项目,但它严重限制了团队交付工作软件,解决瓶颈和确定工作优先级的能力。因此,它增加了冲刺失败的风险。

在Scrum中,垂直分解更有用,其中PBI被分解为更小的PBI(而不是技术任务)。如果PBI是垂直分解的,它们会被分解,使得较小的项目仍然可以产生可用的,可测試的软件。功能不会因跨技术层而分开。因此,如果PBI是 "作为客户我可以支付我的订单,故此我可以获得我想要的产品",它可以分解为更小的PBI,如 "作为客户我可以通过电汇支付,所以我可以得到我的产品" 又或者是 "作为客户我可以用信用卡付款,所以我可以得到我的产品"。

一个比喻将进一步澄清差异。想象一下,用一层奶油,水果和蛋糕切片蛋糕。如果你要水平切蛋糕,每个客人只会得到一整块蛋糕,奶油或水果。我相信你的客人会期待别的东西。 只获得一层蛋糕,而不允许他们获得整个蛋糕各层的组合,这是合理的切法吗? 更友好的方法是将蛋糕切成垂直切片,每个切片都有一些蛋糕,奶油和水果:

 

有许多策略可用于分解大型PBI。我收集了十个最有用的。正如您将看到的,这些策略不仅有助于打破PBI,还有助于决定什么是重要的、什么不是。这样,产品负责人可以更轻松地确定工作的优先次序,并就Scrum团队应该花费的时间做出更明智的决策。

策略1:按工作流程步骤分解

如果PBI涉及某种工作流程,则该项目通常可以分解为单独的步骤。将PBI用于常规网上商店的订购流程:

作为客户,我可以在购物篮中支付货款,以便我在家里收到我的产品

鉴于相当标准的订单程序,我们可以确定以下步骤:

  • 作为客户,我可以使用我的帐户登录,因此我不必每次都重新输入我的个人信息;
  • 作为客户,我可以查看并确认我的订单,因此我可以在付款之前纠正错误;
  • 作为客户,我可以通过电汇支付我的订单,以便我可以确认我的订单;
  • 作为客户,我可以用信用卡支付订单,以便我确认订单;
  • 作为客户,我收到了订单的确认电子邮件,因此我有购买证明;

通过打破这样的大型PBI,我们提高了对功能和估算能力的理解。产品负责人也可以更轻松地确定工作的优先顺序。工作流程中的某些步骤可能现在不重要,可以移动到将来的sprint中。也许订单确认电子邮件可以暂时手工完成,或者客户现在只能用信用卡付款。也可以要求客户(暂时)为每个订单重新输入他们的个人信息。这肯定会限制网店的功能,但它确实允许Scrum团队在sprint结束时审查(甚至可能部署)已完成的功能,测试它并使用反馈进行必要的更改。

策略2:按业务规则细分

PBI通常涉及许多明确或隐含的业务规则。再次使用此PB,用于常规网上商店的订购流程:

作为顾客,我可以在购物篮中购买商品,这样我就可以在家里收到我的产品

鉴于相当标准的订单程序,我们可以确定以下“业务规则”:

  • 作为店主,我可以拒绝10美元以下的订单,因为它们没有盈利;
  • 作为店主,我可以拒绝来自美国以外的客户,因为运输费用使这些订单无利可图;
  • 作为店主,我可以从库存中预订48小时的订购产品,因此其他客户可以看到实际库存;
  • 作为店主,我可以在48小时内自动取消尚未收到付款的订单,因此我可以再次将其出售给其他客户;

业务规则通常是隐含的,因此挖掘它们需要一些技巧和分析能力。采用另一种策略可能会有所帮助(如下所述,#7); 如何测试功能?通常,测试用例意味着重要的业务规则。一旦确定了业务规则,它将再次提高我们的理解和估算能力。产品所有者可以决定某些业务规则暂时不重要,或者可以以简化形式实现。也许现在可以在48小时内未收到付款时手动将未付款产品退回库存,或者手动取消订单。更实际的是,网站上的一条消息说明“订单不在美国境外发货”或“最低订单价格必须至少为10美元”,现在可能就足够了。

策略3:用快乐 / 不快乐流程细分

功能通常涉及快乐的流程和一个或多个不快乐的流程。快乐流程描述了一切顺利时功能的行为方式。如果存在偏差,异常或其他问题,则会调用不愉快的流。使用此PBI登录安全网站:

作为客户,我可以使用我的帐户登录,以便我可以访问受保护的页面

如果我们考虑定期登录程序,我们可以确定一个快乐的流程和几个潜在的不愉快流程:

  • 作为用户,我可以使用我的帐户登录,以便我可以访问安全页面(快乐);
  • 作为用户,我可以在登录失败时重置密码,因此我可以尝试再次登录(不快乐);
  • 如果我的登录名不知道,我可以选择注册一个新帐户,这样我就可以访问安全页面了(不高兴);
  • 作为网站所有者,我可以阻止连续三次登录错误的用户,这样我就可以保护网站免受黑客攻击(不满意);

不愉快的流程描述异常。通过识别各种流程,我们可以更清楚地了解所需的功能。产品负责人可以更轻松地确定现在重要的内容。可能在三次失败后阻止用户现在并不重要,因为第一个版本中只有少数用户。或者,也许可以通过向客户服务员工暂时发送电子邮件来重置密码。同样,通过拆分功能,我们可以更准确地提出有关业务价值的问题,并相应地做出决策。

您可能不需要立即获得iPad支持

策略4:按输入选项 / 平台细分

大多数Web应用程序必须支持各种输入选项和/或平台,如台式机,平板电脑,移动电话或触摸屏。通过输入选项分解大项目可能是有益的。为团队带一个数字Scrum Board:

作为团队成员,我可以查看Scrum Board,因此我知道我们作为一个团队的工作方式

我们可以识别以下输入选项:

  • 作为团队成员,我可以在桌面上查看Scrum Board,因此我知道sprint的状态;
  • 作为团队成员,我可以在手机上查看Scrum Board,因此我知道sprint的状态;
  • 作为团队成员,我可以在触摸屏上查看Scrum Board,因此我知道sprint的状态;
  • 作为团队成员,我可以在打印输出上查看Scrum Board,因此我知道sprint的状态;

通过这种方式分解大型项目,产品负责人可以更轻松地确定哪些输入选项或平台更重要。桌面版本现在可能已经足够,而移动版本可以推向未来的sprint。或者,打印输出可以暂时使用简单的PDF捕获实现,而无需创建特别适合打印的版本。

策略5:按数据类型或参数分解

一些PBI可以根据它们返回的数据类型或它们应该处理的参数进行拆分。举例来说,网店的搜索功能:

作为客户,我可以搜索产品,以便查看和订购

搜索产品的方法有很多种。所有这些潜在参数都可以考虑并分解为更小的PBI:

  • 作为客户,我可以按产品编号搜索产品,这样我就可以快速找到我已经知道的产品;
  • 作为客户,我可以搜索价格范围内的产品,以便搜索结果更具相关性;
  • 作为客户,我可以按颜色搜索产品,以便搜索结果更具相关性;
  • 作为客户,我可以在产品组中搜索产品,以便搜索结果更具相关性;

通过以这种方式分解搜索功能,我们可以更清楚地了解将使用哪种搜索参数。这使我们能够更准确地估计功能,但它也允许产品负责人做出有关优先级的决策。由于产品数量少,分页可能还不相关。当产品数量增长时,它可能会变得相关。或者也许现在可以以简化的方式实现一些搜索功能。此策略的另一个示例是在基于返回的数据类型分解涉及管理信息的功能时。某些信息可以在图表或图形(数据类型)中以可视方式显示,但也可以现在以表格格式(数据类型)显示。

战略6:按行动分解

PBI通常涉及许多默认操作,例如Create,Read,Update或Deleted(通常缩写为CRUD)。当功能涉及实体(例如产品,用户或订单)的管理时,CRUD操作非常普遍:

作为店主,我可以在我的网上商店管理产品,因此如果更改价格和产品信息,我可以更新

通过识别此功能所需的各个操作,我们可以推导出以下较小的功能:

  • 作为店主,我可以添加新产品,以便客户购买;
  • 作为店主,我可以更新现有产品,因此我可以根据价格或产品信息的变化进行调整;
  • 作为店主,我可以删除产品,因此我可以删除不再存货的产品;
  • 作为店主,我可以隐藏产品,因此暂时不能出售;

当提出这种策略时,许多团队想知道较小的项目是否真正提供了商业价值。毕竟,只有在您之后无法更新或删除实体时才创建实体的重点是什么?但也许产品负责人拥有如此有限数量的产品,可以直接在数据库中进行编辑或删除。有时,可以以简化的形式容易地实现操作。删除产品可以通过两种方式完成; 您可以完全删除记录和所有相关记录,也可以“软删除”产品。在这种情况下,产品仍在数据库中,但标记为“已删除”。有时这些方法中的一种更容易实现,并且现在可以“足够好”。

策略7:按测试场景 / 测试用例分解

当仅基于功能难以分解大型PBI时,此策略非常有用。在这种情况下,有助于询问如何测试一个功能。必须检查哪些方案才能知道功能是否有效?采取任务计划系统:

作为经理,我可以将任务分配给员工,这样他们就可以完成任务

如果我们根据潜在的情况考虑这个功能,我们可以将项目细分为:

  • 测试案例1:如果已经分配了员工,则不能将他或她分配给其他任务;
  • 测试案例2:如果员工报告有病,他或她应该用视觉标记;
  • 测试案例3:如果员工报告生病,则不能将他或她分配到任务中;
  • 测试案例4:如果尚未分配员工,则可以将他们分配给任务;
  • 测试案例5:可以为员工分配触摸屏显示器;

这种策略实际上可以帮助您隐式应用其他策略。通过考虑测试,您自动最终得到许多业务规则(#1,#2,#3和#4),(un)快乐流(#1,#2和#3)甚至输入选项(# 5)。有时,测试场景可能非常复杂,因为设置测试并完成测试所涉及的工作。如果测试场景开始时不常见或者没有足够高的风险,产品负责人可以决定暂时跳过该功能,并专注于提供更多价值的测试场景。在其他情况下,可以简化测试场景以涵盖最紧迫的问题。无论哪种方式,相关的测试场景都可以轻松转换为积压项目并添加到sprint或backlog中。

策略8:按角色分解

PBI通常涉及执行该功能的一部分的许多角色(或组)。使用PBI将新文章发布到公共报纸网站:

作为新闻机构,我们可以在我们的主页上发布新文章,因此客户有理由定期返回

通过考虑所涉及的各种角色,我们可以将功能分解为以下几点:

  • 作为客户,我可以阅读一篇新文章,因此我可以了解重要事件;
  • 作为记者,我可以写一篇文章,所以我们的客户可以阅读;
  • 作为编辑,我可以在将文章放到网站上之前查看该文章,以便我们可以防止错别字;
  • 作为管理员,我可以从网站上删除文章,以便我们可以提取违规文章;
  • 作为客户,我可以查看并确认我的订单,因此我可以在付款之前纠正错误;

通过将功能分解为必须执行该功能的角色,我们可以更清楚地了解所需的功能,并可以更准确地估计所涉及的工作。编写PBI是应用此策略的好方法。它还有助于产品负责人确定优先顺序。某些角色目前可能不太相关,可以在以后实施。也许当时没有必要让编辑。或者记者可以调用编辑器手动检查文章。

策略9:按 “优化现在” 与 “优化后期” 分解

通常,PBI可以在不同程度的完善和所描述的功能的优化中实施。拿这个PBI:

作为访客,我可以搜索附近的酒店,所以我可以缩小搜索范围

这样的故事可以在不同程度的优化中细分:

  • 作为访问者,我可以从地址搜索半径范围内的酒店,因此我可以缩小搜索范围;
  • 作为访问者,我可以输入邮政编码自动填写地址,所以我不必手动输入整个地址;
  • 作为访问者,我可以使用我的位置(GPS)在附近搜索,所以我不必手动输入地址;
  • 作为访客我立即获得了附近搜索最多的酒店,而其他酒店正在后台加载,所以我更快得到结果;

让我明确一点:这个策略不应该被用作现在编写“糟糕代码”和将来编写“更好代码”的借口。Scrum团队应始终努力提供可维护,(自动)测试和编写良好的代码。该策略涉及功能优化。无论如何,产品负责人可以更轻松地确定这些项目的优先顺序。也许现在足以让访问者按地址(和半径)进行搜索,而将来会实现更复杂的功能(自动完成,GPS)。

策略10:按浏览器兼容性细分

在策略#4的变体中,用于Web应用程序的PBI通常需要在各种浏览器平台上工作。现代浏览器往往更符合标准,并且更容易开发,而旧版浏览器通常需要黑客和自定义才能使一切正常工作。讲这个故事:

作为客户,我可以查看产品详细信息,因此我知道是否要购买它

通过考虑浏览器版本,我们可以将工作分解为更小的项目:

  • 作为客户,我可以在符合标准的现代浏览器中查看产品详细信息,因此我知道是否要购买它;
  • 作为客户,我可以在IE7中查看产品详细信息,所以我知道是否要购买它;
  • 作为客户,我可以在文本浏览器中查看产品详细信息,因此我知道是否要购买它;

尽管在完全支持所有浏览器版本的情况下提供此功能当然更为可取,但确实存在这种分解可行的情况。也许绝大多数访问者使用现代浏览器,需要更少的努力来支持旧浏览器(除了警告之外)。或者,应用程序可以在内部网络上运行,所有用户都可以使用Internet Explorer 7.同样,这可以让产品负责人确定优先级,并帮助团队在最重要的功能上花费时间和精力。

其他策略

在分解大型PBI时,还有许多其他有用的策略:

  • 根据确定的验收标准细分项目。这看起来非常明显,但它通常是打破故事的最简单,最自然的方式。确定PBI的验收标准需要与本文中描述的策略类似的策略;
  • 根据难以实现的部件和更容易的部件细分项目。在设计严谨的UI中设置一个功能可能很困难,但是使用简单的UI来实现它可能很容易,而且现在已经足够了。同样,这一切都是为了务实和提供商业价值;
  • 根据外部依赖关系细分项目。有时功能取决于外部因素,例如为远程Web服务实现消费者(例如,用于电子支付或连接到Twitter)。这可能很困难,但可能没有最高优先级。或者可以暂时模拟依赖关系;
  • 根据可用性要求细分项目。这包括翻阅记录列表的功能,使盲人或具有色盲或实施面包屑的人可读的网站;
  • 根据SEO要求细分项目,例如为特定关键字设置专用登录页面,为Google Analytics设置目标或设置XML站点地图;

 

什么时候产品Backlog项目足够小?

对于理想情况下PBI的小小,没有明确的规则。这在很大程度上取决于短跑的长度,应用的性质以及团队的规模和经验。通常需要Scrum团队进行几次冲刺才能找出最佳位置。

我自己的经验是,团队应该努力将至少5个故事添加到为期一周的冲刺(每天一个)。它们不必具有相同的尺寸,但它们本身不应该太大。当团队使用Story Point估算时,他们通常会同意将故事的最大大小用于sprint。因此,只有少于(比如说)8分,故事才会进入冲刺阶段。这也为即将开展的工作的改进过程提供了明确的目标。

关于Scrum团队的潜在顾虑

当Scrum团队试图打破PBI时,我经常会听到一些担忧。首先,团队担心较小商品的商业价值下降。当然,与较大的物品相比,较小的物品会降低商业价值。但是,分解功能的主要目的是降低风险,增加流量并增加可在每个sprint结束时查看的工作功能。另一种方法是继续使用非常大的功能块,以及上述所有后果和风险。

另一个问题是,分解功能会导致更多工作。对于团队而言,在完成某项功能之前,始终更容易,更快速地继续工作。重新审视冲刺中的点点滴滴感觉很浪费。虽然这在某种程度上可能是正确的,但仍有充分的理由仍然这样做。在Scrum中,我们实施了一个流程,旨在持续审查和测试我们的工作,并根据我们得到的反馈进行调整。因此,您现在可能想到的功能可能与我们使用Scrum时实际实现的功能有很大不同。尽管继续开发一项功能可能很诱人,但很有可能您将时间浪费在将要进一步改变的功能上(基于用户,利益相关者等的反馈)。

最后一个问题是许多团队没有立即“获得”如何分解功能。因此遇到一些阻力并不罕见。这是可以理解的; 尝试新事物很困难,因为它会使人感到脆弱。解决这个问题的最好方法是坚持并轻轻地指导团队,帮助他们打破他们的PBI。

总结

在这篇文章中,我强调了(不断)将大型PBI分解为较小的PBI的重要性。冲刺应该优选地包括许多小物品而不是仅仅几个大物品。冲刺中只有少量很大的项目,冲刺失败的风险就越大。我提供了10个有经验的Scrum团队使用的着名策略,可能对您的团队有用。祝好运!

展开阅读全文

没有更多推荐了,返回首页