SPIDR - 完美分割用户故事的五种简单技巧

根据INVEST原则,对用户故事的要求是它必须“足够小”或具有合适的大小。用户故事应该足够小,可以在冲刺中完成6-10个。当然这也取决于开发团队的速度。为了原则上实现这一目标,必须相应地分割大型故事。在下文中,我想向您介绍Mike Cohn的简单快速的SPIDR方法。他总结了五种技术,几乎每个大型用户故事都可以分为几种。

钉鞋

Spike是敏捷软件开发中使用的术语。尖峰是功能的小型原型实现,通常用于新技术的评估和可行性。

该方法涉及调查和建立知识。如果其他SPIDR方法效果不佳,则应该使用它。借助这些新获得的知识,可以更好地理解一些故事,并可能更容易地分裂。然而,该方法相对抽象,因此比其余方法更难应用。

路径

如果用户故事中有多个可能的备用路径,则一个选项是从这些路径中的某些路径创建单独的用户故事。为每条路径写一个故事并不是绝对必要的,只要它有意义。例如,让我们看一个用户想要在线商店购买的用户故事。现在有两种可能的途径:使用信用卡付款或使用Paypal付款。理论上,信用卡付款可以进一步细分,但你需要权衡每种类型的信用卡是否有自己的故事。然而,支付购买的首要任务分为上述两种备选方案。因此,新创建的故事更小,更容易估计。

接口

在该上下文中的接口可以是例如不同的设备或设备类型,例如由iOS或Android供电的智能电话。用户故事也可以根据这种多样性进行划分。让我们坚持使用不同操作系统的示例:例如,在项目中,可能存在仅与Android设备的使用相关的用户故事,或者专注于Web浏览器的其他用户故事。为了避免使故事过于庞大和全面,您应该问自己要开发哪些设备或接口。也许第一个开发结果应该只引用iOS设备,因为可能更大的目标组。

数据

当初始故事仅涉及相关数据的子范围时,可以使用另一种用于分割用户故事的技术。以一个旨在吸引游客到特定城市的网站为例。例如,如果它是以博物馆而闻名的城市,那么第一个故事可能包括该地区不同博物馆的信息。随后的故事可能包括穿越城市的各种旅游,以及另一项户外活动。

规则

业务规则或技术标准可能是另一个分裂因素。以在线购买电影票为例。通常存在约束,例如基于相应电影的业务要求,例如每个电子邮件地址最多五个票的在线购买限制。

有了这个故事,可以想象开发团队省略了这个限制,允许每个访客购买尽可能多的门票。然后可以在第二次迭代步骤中添加限制。像这样的增量交付意味着初始故事不会立即完全实现,而是以几个较小的步骤提供。有时忽略技术规范或业务规则是有意义的,如果通过这样做,您可以更快地实现满足用户或客户的可呈现结果。可以在以后检索省略的故事。

小用户故事 - 更容易实现

用户故事分裂并不总是那么容易:许多初学者倾向于将他们的故事过于全面而且过于庞大。但是,当涉及到开发团队的改进,并最终实现故事时,很快就会发现必须制作更小的故事。在我之前关于写(好)用户故事的博文中,我坚持认为故事应该是“可估计的”和“小的”。如果您知道如何分割大型故事,则更有可能发生这种情况。正如编写用户故事一样,练习也是完美的。


敏捷软件开发

  • 什么是敏捷软件开发?
  • 什么是用户故事?
  • 什么是用户故事映射?
  • 用户故事与敏捷软件开发的使用案例

你可能感兴趣的:(scrum,agile,敏捷,敏捷开发,敏捷交付)