专栏首页程序你好敏捷开发中,User Stories最佳实践

敏捷开发中,User Stories最佳实践

在本文中,讨论User Stories创建、计划和编写User Stories相关的代码的最佳方式,以及回答一些最常见的问题。

许多团队开始使用“用户故事(User Stories)”这个术语,因为他们转向了敏捷。用户故事是一种收集客户需求的简单而优雅的技术。然而,使用用户故事来构建优秀的软件需要一定的理解和实践。

让我们仔细看看用户故事(User Stories)是什么,以及如何在项目中成功使用这种技术。

什么是用户故事?

用户故事是一个简短而简单的功能描述,它为用户或客户带来价值,并且团队可以在迭代中交付这些功能。

用户故事应该回答三个问题:

我们为谁实现它?——期望<用户>的类型

我们实现是什么功能?——我希望<功能>

我们为什么要实现它?——<价值,和好处>

在此之后,用户故事的典型格式是:

作为一个<某种类型用户>,我想要<功能>,以便<好处>。

用户故事的例子:作为注册用户,我希望能够将我的照片下载到我的个人资料中,以便其他用户可以看到我的样子。

有创建用户故事的过程吗?

没有创建用户故事的正式过程。然而,应该遵循一个指导方针来创建一个好的用户故事。它叫做3c,是由极限编程的创始人之一Ron Jeffries提出的。

卡片是用户故事的书面描述。它没有捕获应该构建的所有细节。相反,它是一个提醒,一个必须进行后续沟通的承诺。

对话用于讨论用户故事的细节。它可以通过一些文档来补充。

由用户验收测试来进行确认,以确保用户故事满足用户/客户的验收标准。

如何编写高质量的用户故事

要确保用户故事具有适当的质量,一个好的做法是遵循比尔•韦克(Bill Wake)的“投资”(INVEST)首字母缩写的标准。INVEST还有助于确定用户故事是否被很好地理解并为开发团队开始工作做好了准备。

独立——用户故事不应该依赖于另一个用户故事,因此用户故事可以按照任何顺序开发。

可协商——用户故事的细节在产品所有者和开发团队之间的口头对话中协商。

有价值——用户故事应该为用户/客户带来所需的价值。

可评估——开发团队应该充分理解用户故事,以便对其进行评估。

小的-用户故事应该小到适合在一个迭代(1-3周)中。

可测试性——应该为用户故事编写适当的验收标准,以便对其进行验证。

什么不是用户故事?

让我们坦诚地告诉自己:用户故事的定义必须是从真正业务用户的角度,不可能是“技术用户(开发者本身)故事”,因为在这种情况下,它不会给用户/客户带来直接的价值。尽管如此,当许多团队需要完成诸如代码重构之类的技术任务时,他们还是喜欢创建用户故事。我建议将其他工作项用于此类任务,并与您的产品所有者就此类工作达成一致,以便他了解为什么有必要这样做。与非功能性需求任务、界面设计任务、复杂的用户交互任务或bug相关。

您可以自由地为这些任务创建其他工作项。例如,约束故事可以用来表示非功能需求。用户故事是捕获产品功能的一种很好的技术,但是我们没有义务将它用于所有目的。

用户是谁?

在编写用户故事之前,应该清楚地了解创建用户故事的用户是谁。有时,新接触用户故事技术的团队会忽略它,他们最终会创建具有不必要功能的软件。所以,做一个适当的用户调查,让所有的用户类型或用户角色或角色写下和描述。可以帮助您实现这一点的两种技术是用户角色建模和角色。

谁负责编写用户故事?

通常,客户代表(如产品所有者)负责用户故事。尽管如此,用户故事并不是高层给团队的规范,而是产品所有者和团队之间的协作技术。这就是为什么如果用户故事是合作编写的更好。一个好的方法是成立一个故事编写研讨会,由团队合作编写。

细节在哪里?

由于用户故事不是规范,所以细节以不同的方式表达:

在用户故事编写的3C原则中,第二个C是对话(Conversation)。会话是敏捷最重要的方面之一。因此,大部分细节都是通过客户代表和开发团队之间的口头交流来传达的。

第三个“C”是确认( Confirmation)。用户验收测试是确认用户故事满足用户/客户的验收标准,并作为正式的文档细节。BDD(行为驱动开发)是编写验收测试的一种很好的技术。

如果需要,一些用户故事可能包含额外的书面细节。

如何知道用户故事何时完成?

使用已“完成”技术的定义。简单地说,Done的定义是团队成员之间对完成工作的意义的共同理解。完成的定义通常以活动检查表的形式创建,该检查表展示了商定的价值(满足用户接受标准的用户接受测试)和质量(满足质量标准的用户接受测试)。

团队有时会忽略最后一个,什么会使用户故事在迭代结束时不能交付给客户。定义Done技术有助于避免这种情况。

参看下面定义的例子

完成时:

单元测试通过了

代码是同行评议

通过用户验收测试

集成测试是通过了

回归测试是通过了

用户指南更新了

如何开始定义产品范围?

在项目的开始,我们需要定义一个产品的粗略范围,以便对它有一个全局的看法。这可以用史诗(Epics)来完成。史诗是有一个共同目标的大量工作。可以将Epic视为稍后创建的更详细的用户故事的占位符。史诗通常需要多次迭代才能完成。

组织用户故事的最佳方式是什么?

使用杰夫·巴顿发明的故事映射技术。故事映射代表了对需求组织的自顶向下的方法,也是确定优先级和计划的好方法。

敏捷扩展BABOK® Guide v2 状态:

“故事映射提供了解决方案支持的活动序列的可视化和物理视图。它使用二维网格结构在水平维度上显示产品关键方面的序列和分组,在垂直维度上显示故事的细节和优先级。故事映射是一种分解技术,它允许从端到端视图开始对解决方案进行演化理解,并深入到详细的用户故事。”

故事映射的例子(由Steve Rogalsky创建):

本文分享自微信公众号 - 程序你好(codinghello)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2018-06-21

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何通过设计思维创造更好的软件系统?

    对我们大多数人来说,“设计”这个词是对经典的思考。建筑风格的吸引力或漂亮汽车的吸引力,从美学的角度来看,汽车或家庭可能设计得很好,但它们可能不太适合自己的工作。

    程序你好
  • 从业务数据分析到机器学习应用的一次经历

    程序你好
  • 区块链技术能颠覆整个在线广告行业运行模式?

    程序你好
  • Google-优秀移动站点设计10招

    Google-优秀移动网站设计10招 1)添加一个醒目的搜索条:在移动终端上,人们希望能够快速找到自己需要的东西 2)把大表格拆分成小块:别搞一个长长的表格页面...

    架构师之路
  • 用户生命周期,从运营到数据的最全攻略在这里

    上一篇{用户流失,该怎么分析}中,有很多同学留言想看用户生命周期的分析,今天它来了。用户生命周期管理,是系统化运营和拍脑袋运营的重要区别。不做系统化设计,就会沦...

    1480
  • 诸葛io客户成就总监邱千秋:数据驱动下的理财产品业务增长探索

    数据猿导读 科技金融相比传统金融具备更高的效率、更大的灵活性和更强的抵御金融风险的能力。想跑在金融标杆的前列,一方面要将用户体验做到极致,另一方面要保持不断创新...

    数据猿
  • 读《增长黑客》

    这是《我精心挑选了18本给0岁运营的书单》中的《增长黑客》一书的读书笔记。上一次花了1周读了《引爆点》一书。这次花的时间有点多,主要是内容太多了。呵呵。 下面是...

    mixlab
  • 激活和留存

    增长黑客的拉新和常规市场/运营的拉新区别在于,增长黑客更看重的是新用户为产品带来的实际价值,这个价值可以是电商产品中的用户购买转化,也可以是内容社区产品中的用户...

    葆宁
  • 用户生命周期,从运营到数据的最全攻略在这里

    上一篇{用户流失,该怎么分析}中,有很多同学留言想看用户生命周期的分析,今天它来了。用户生命周期管理,是系统化运营和拍脑袋运营的重要区别。不做系统化设计,就会沦...

    接地气的陈老师
  • 关于用户增长你必须要知道的那些事儿

    增长是一件与用户活跃、留存息息相关的事,如果纯粹为了做增长,拉来了一批无效用户,这样的增长是没有意义的。

    数据通20847430

扫码关注云+社区

领取腾讯云代金券