2018年5月31日,星期四10:41

BA技能集-划分用户案例

撰写者

在过去的三年中,我花了很多时间与大量开发人员合作。他们的技能和经验差异很大,但是我遇到的一个一致的行为是,他们都在逻辑结构中工作。

他们的重点往往是一次只关注一个作品,而不是一遍又一遍,然后进行回顾。

这也是很多年前我过渡到敏捷后趋向于满足自己的要求的方式。尽管我会从总体上大致了解需求,但细节来自一次处理少量需求。这样,在细节中提出了进一步的要求,并且循环继续进行。

尽管我以不同的方式积累了很多经验,并撰写了需求,但主要是用户故事,这是开发团队的首选需求。

在过渡初期,我发现我的一些更复杂的用户案例往往太大而无法在单个sprint中交付。随着时间的流逝,我获得了更多的技能,并获得了更多的经验,可以将较大的故事分解为更易于管理的部分。

我坚信彼得·德鲁克(Peter Drucker)的话:“衡量的东西得到管理”。因此,在如此短的sprint窗口内,保持轻巧的用户故事可以为整体交付提供真正的价值,并允许团队交付更多可量化的价值。

分解故事的方法有很多,但最引起我共鸣的是Mike Cohn的SPIDR方法。一旦您了解了基本概念,它也恰好是较简单的方法之一。

SPIDR 是用于拆分用户故事的5种技术的缩写。

S –  Spikes
P –路径
I –接口
D –数据
R –规则

尖刺

在逆转首字母缩写趋势时,S(Spikes)实际上是一种倾向于最后且最少被调用的技术。与敏捷开发过程中的峰值类似,峰值发生在无法估计故事的情况下,并且需要一定的时间才能进行进一步的研究和理解。

这是因为随着知识的增加,我们更有可能更好地理解故事并将其分解为较小的故事。

作为一名学士学位,我经常觉得如果提出尖峰调整,我无法满足开发人员的充分要求。话虽如此,我知道它们的价值,尤其是在最近使用团队尚未熟悉的新技术时。如果没有更好地了解这个故事,开发团队和我就有交付不合格产品的风险。

在尝试编写单行代码之前,我曾经与最好的开发人员一起计划过纸上的开发工作。同样,高峰可以让您有更多的时间来更好地理解和计划客户的需求,因此,我们有更多的机会在没有麻烦的返工的情况下首次交付实际价值。


广告

路径

一条路径描述了朝着相同最终目标存在替代流的位置。让我们以我最近参与的一个项目为例。高层的故事是客户需要能够在商店内付款。这个故事有许多可用的路径。例如,可以使用现金,信用卡(芯片和密码以及非接触式),客户信用帐户和移动支付(包括苹果支付和安卓支付)进行支付。

在这种情况下,原始故事可以分为6个较小的故事,每个故事都有自己的特定细节和单独的测试。

作为一名学士学位,我们必须研究拆分的各个优点,确定是否有6个故事比4个故事更具价值,其中有2个故事具有相同的要求,涵盖多种支付方式。

然后,我们可以估计每个故事,而不必一次完成所有工作,我们可以做目前最有价值的事情,并在以后的项目中继续工作。

每个路径都允许我们在其自己的故事中指定每个路径,然后将某些路径重新分组(如果它们没有提供额外的价值,则视为单独的故事)。

介面

接口指的是跨不同渠道或来自不同渠道的详细信息量。让我们再举一个我最近的项目中的例子。一旦完成,该项目将为客户提供跨多个渠道订购的功能,包括网站和移动网站(针对手机和平板电脑进行了优化),但是在初始阶段,我们选择仅通过网站提供服务。尽管移动客户是客户的重要子集,但最大的价值是将项目交付那里,获得客户反馈并评估初始性能,以便我们更好地为客户服务。移动电话将紧随其后,如果这样做的话,基于我们将最初的故事分为各个渠道的事实,这将是一个更好,更完善的客户服务。

根据界面拆分故事可提供更大的灵活性,并能够更准确地估算每个界面所需的开发和测试时间。

数据

例如,假设我们正在重写我们的网站。我们有许多与内容相关的大故事,这些故事将要显示在网站的目标页面上。我们知道,按照一年中的时间来看,传统上来说,女性服装很可能会成为男装和家居装饰品的最大卖家。因此,我们将撰写一些故事,以突出显示这些类型的产品。目前,我们只关注女装,因为这是一年中这个时候最有价值的地方。稍后,我们将对家居用品进行同样的处理,然后再进行男装处理。

我们根据最有价值的数据来划分故事,从而在为客户/业务投入的时间上获得最佳回报。根据数据拆分故事可提供更大的灵活性。

规则

商业,法规,技术规则等…。所有这些都提供了分解故事的潜力。

让我们以拥有信贷帐户的服装零售商的客户为例。公司在客户开设帐户时对客户进行了信用检查。零售商会根据其信用评分在内部设置不同的信用额度,以降低客户拖欠还款的风险,并通过降低客户将自己的信用额度过度延伸到无法负担还款的能力来提高道德操守。

在这种情况下,业务规则规定,客户不能以高于公司定义的信用额度的值在其信用帐户中购买商品。

为了简化故事,可以忽略此规则,并且开发人员的第一次迭代允许购买金额最大的最大贷方帐户。具有更复杂逻辑的其他规则将在以后的迭代中提供,但是要测试信贷帐户购买的功能,在没有自我施加的业务规则的情况下推出,可以使业务更快地测试其余功能。

根据包含/排除规则拆分故事可以更快地交付和测试。然后,可以通过更改当前工作的版本在以后的迭代中实现规则的值。

Success 和 Story Sizes

我坚信,理想情况下,最大规模的故事可以让单个开发人员在几天内完成交付。基于该原理,在冲刺过程中,可以交付的故事数量使项目经理/产品所有者可以预测实际的交付日期并更好地计划发布。

作为业务分析师,当务之急是给开发人员最大的机会,以便在sprint计划中准确估计故事并在每个sprint中交付大量故事。我的最终目标是尽早且经常地将所需功能的有效版本展示在客户面前。能否成功很大程度上取决于积压中的故事大小。

乔恩·德比郡

拥有将近10年的业务分析师经验,涉及从医疗保健到零售的各个领域。我积累了各种各样的技能,能力和技巧。
我一直在努力提高自己,提高自己的知识和技能水平,并乐于帮助和指导该领域的其他人。

来自乔恩·德比郡的最新消息

©BA Times.com 2020

麦格雷戈徽标白色网站