cxu0262

aic准则和bic准则_如何编写敏捷的用户故事：7条准则

aic准则和bic准则

从根本上讲，敏捷用户故事是简短，简单的工具，用于记录目标用户为实现目标所需的单个动作或意图。最简单的用户故事的格式为：“作为用户类型或角色 ，我要采取行动或意图，以便获得理由或受益 ”，至少可以回答三个简单问题，即故事在谁，什么以及为何积压在队列中。

随着团队的成熟和组织在多个团队和计划中使用敏捷，敏捷用户故事通常具有更多的定义和结构，以确保对意图和基本需求有共同的理解。

[了解您的企业如何在敏捷开发中脱颖而出。 | 将您的敏捷职业提升到新的水平：如何提高您的Scrum Master技能。 | 不确定“敏捷”的真正含义是什么？ InfoWorld 解释了敏捷方法。 | 通过InfoWorld的App Dev Report新闻通讯了解编程方面的热门话题。 ]

编写敏捷用户故事的入门

有足够的资源来帮助新产品所有者，业务分析师，Scrum Master和技术潜在客户了解编写用户故事的基础。一些开始的地方包括Atlassian ， FreeCodeCamp ， Agile Modeling的文章，以及这200个用户故事示例。最完整的文章之一是Alexander Cowan最好的敏捷用户故事。有一些有关故事写作的书籍，包括Jeff Paton和Peter Economic的用户故事映射以及Mike Cohn所应用的用户故事 。您还可以参加Udemy ， Learning Tree ， VersionOne和Lynda的故事写作课程。

比尔•韦克（Bill Wake）首先认同的一个基本原则是投资好故事 。 Invest代表“独立，可转让，有价值，可估计，规模小和可测试”，这是敏捷故事作者的一个很好的清单。 “ 编写用户故事的敏捷领导者指南 ”是一篇文章，解释了如何应用投资原则。

基本知识相对容易，但是我经常听到并见证利益相关者，产品所有者，开发人员和测试人员之间关于需求质量或故事是否真实完成的脱节。有时，在所需的详细程度，适合技术要求的位置以及应使用用户故事创建哪些工件的观点上存在分歧。

考虑到这些问题，这里有七个有关编写敏捷用户故事的基本准则。

1.为将要使用它们的听众编写故事

在编写故事之前，请记住，故事是供参与开发过程的人们以不同的需求和责任阅读和理解的。故事作者和撰稿人应牢记观众的思想，并草拟故事以解决集体需求：

产品负责人可能不是编写故事的人，尤其是如果您的组织将此功能委派给业务分析师，或者如果有多个人参与故事编写，则尤其如此。产品负责人希望确保故事能够充分体现用户的需求和意图。他们应该通读详细的接受标准，但不一定要被技术实施细节所困扰。产品负责人还应该了解故事如何与大局一致，因此他们必须对史诗和功能的定义方式以及如何将故事分配给它们产生积极的兴趣。
利益相关者不会阅读故事的详细信息，但会从史诗中深入挖掘并阅读故事的摘要。如果您有很多利益相关者，请考虑使用描述性格式的摘要，并将“作为用户类型或角色 ”描述移动到用户故事描述的开头。
技术负责人通常是团队中第一个审查故事的人，他们将研究需求，以了解一个故事是否太大并应分为多个故事，或者看故事是否需要先期的技术工作来确定最佳故事。解。
受让人是负责在每日站立会议上审查详细信息并报告进度的个人。受让人应在故事中检查是否有依赖关系，这些依赖关系可能在冲刺期间成为障碍。
团队成员经常查看所有故事，以在分配给冲刺的其他故事的背景下了解他们分配的故事。
测试人员确定验收标准中是否存在未发现的差距或风险，然后考虑如何在自动化测试框架中最好地实施这些差距或风险。
团队的分析师（可能是项目经理或项目管理办公室的成员）希望对故事进行完全标记和分类，以便可以从待办事项中提取有意义的指标。

2.首先要考虑用户

尽管敏捷的用户故事可能需要很多细节，但从用户的角度入手非常重要。故事应该定义用户想要完成什么动作或意图，以及为什么要满足需求，核心价值或从体验中得出的目标。

对于更复杂的应用程序，定义不同的用户角色以说明不同用户类型的需求，价值和使用模式是一门重要的学科，可以增强故事编写。罗曼·皮克勒（Roman Pichler）在“ 撰写优秀用户故事的10条技巧 ”中指出，“角色目标可帮助您发现正确的故事。问问自己产品应提供哪些功能以满足角色的目标。” 使用角色来加强用户目标可以提供一个更重要的含义，说明故事为何如此重要，并有助于确定待办事项的优先级。

3.回答为什么故事很重要

了解，记录和讨论用户需求或用户角色目标只是围绕产品所有者为何优先考虑故事的一个维度。故事还应该提供商业价值，这是很难量化的，但在故事，故事，史诗或发行层面可能是合格的。

当授权开发人员提出不同的实现选项时，回答为什么对开发人员很重要。例如，如果新的体验还生成了更好的客户数据，那么改善用户登录体验的功能也可能使企业受益。即使故事的接受标准并不特定于此要求，开发人员也可以思考此附加业务价值并优化实现此目标的实现。

4.定义验收标准而不规定解决方案

故事写作中最重要的学科是起草验收标准。这些通常是简短的通过或失败语句的项目符号列表，这些语句记录了需求，约束，度量标准和期望。这些接受标准通常以几种方式使用：

技术负责人和团队使用它们来基于复杂性和努力来估计故事点。
开发人员将实现选项的范围缩小到符合接受标准的选项。
产品负责人可以减少验收标准的范围或复杂性，以较低的估算值推动实施。
站立期间，受让人会传达符合困难条件的区块或问题。
质量保证工程师使用验收标准来开发自动化测试。
产品负责人在敏捷演示过程中会审查关键标准，以确保故事完成。

编写接受标准并非易事。接受标准的接受标准突出了一些问题，例如提供过多的标准，定义过于模糊的标准或记录无法轻松验证的复杂标准。一些作者使用接受标准模板来定义简短，原子和可测试标准的结构。

5.用故事来定义什么和为什么；定义有关如何实施的任务

我看到团队在编写故事时犯下的关键错误之一是在实现过程中过于冗长和具体。这些写得不好的故事，投资于描述如何在描述的费用通常实现用户需要什么， 为什么它解决了自己的目标了很多的努力，以及它带动的商业价值。

有几种原因可能会发生这种情况。

经验不足的产品所有者可能会使用故事来描绘其实现愿景。换句话说，他们可能过度指定用户设计和功能实现，而不是共享目标用户的体验和收益。有些产品负责人混淆他们的东西怎么可能工作（该过程由他们来了解需求），它应该是如何工作的，意外的打开内部实现例如到外部实现规范概念化。

其他产品所有者可能会要求团队“为我打造”，从而超越自己的界限。这是我20个产品所有者的不良行为之一，对于这些问题，我建议产品所有者与解决方案团队合作。

故事可能会因实施细节而变得混乱的另一个原因是，某些团队和技术负责人需要这种细节水平。致力于增强现有应用程序的新成立的技术团队可能需要这种详细程度，直到他们更好地了解应用程序的工作方式并完全理解用户需求为止。一些与离岸开发商或自由职业者合作的分布式团队可能还希望记录实施细节，以确保这些成员了解其职责。

对于这样的团队，最好的办法是链接到实现图，并记录谁在做什么和如何做，以及与故事相关的任务。大多数敏捷管理工具都允许任务或子任务，并且这种详细程度通常与故事的主体分开。这篇文章中的图表很好地说明了这一重要原则，即使用敏捷故事分解用户体验和业务流程，并添加任务以定义各个工作的实现。

6.标记您的故事以推动分析并进行改进

一旦编写，处理并完成了故事，许多团队就会寻求捕获指标并执行分析，以推动流程改进或用于增加投资的业务案例。

这里有些例子：

将故事标记为技术债务，以量化债务的规模，团队用于解决债务的速度的百分比以及每次发行时完成的总债务。
定义功能和技术高峰故事，以推动实验和创新，然后报告其对业务产生的影响。
如果您的团队正在评估敏捷的用户故事，请团队在冲刺结束时标记故事，以表明它们是被高估还是被低估了，以提高估计的准确性。
使用标签，组件和自定义字段可以帮助在积压中搜索历史理解或度量。例如，只要将故事标记为功能和技术组件，就可以知道哪些故事影响了API或哪些要求导致了对应用程序特定区域的最后功能改进。
标记故事以收集或处理敏感信息（例如个人身份信息（PII），电子商务交易）或受行业监管的数据（例如HIPAA数据），以实现安全性和合规性检查。
向产品所有者和团队提供反馈。除了标记一个故事已完成之外 ，产品负责人还可以向团队提供反馈，例如认可出色的工作 。同样，团队可以向产品所有者提供有关用户故事的整体质量和可解释性的反馈。

7.定义敏捷的故事模板和样式指南

与多个敏捷团队和产品负责人合作的大型组织可能希望为故事编写起草标准和样式指南。一致性可以帮助新产品所有者更快地学习写作技巧，还可以提高团队成员使用信息的效率。

设计故事模板的另一个原因是，不同类型的产品和应用程序适合于不同的用户故事表达和工件。一些例子：

业务流程案例可能需要链接到工作流程图，并且还指定角色和权限。
面向客户的应用案例应该具有线框的链接，并包括性能标准。
API故事应记录预期的使用模式和指标。
商业智能和数据可视化故事应提供有关所要求的分析需要哪些字段和信息的指南。

模板可帮助团队和产品所有者之间在编写敏捷故事时重点关注的内容之间架起桥梁。

这不是敏捷故事的重点吗？敏捷的故事编写实践，准则和原则可帮助团队在考虑如何实施之前了解对于用户和业务而言重要的内容。

翻译自: https://www.infoworld.com/article/3336476/how-to-write-agile-user-stories-7-guidelines.html