想象一下一种情况-测试人员发现了一个错误，并开始与开发人员进行讨论-并且他坚持认为这不是错误，因为规范没有讨论此功能。 熟悉吗？
还是因为要求不明确，他误解了这些要求。 或者相反，他们拥有太多信息，以致于在开发过程中失去了焦点，而有些信息却消失了。
在这种情况下，开发人员不是故意犯错的害虫。 在实践中，如果您为他提供了简单，可理解且最重要的是简短的要求，那么测试人员发现的错误数量将为零。
您可能还熟悉关于“错误或功能”的争议。 客户发现了缺陷，产品负责人向团队提出了意见。 测试人员和开发人员为自己辩护，通过在原始设置中没有谈论此功能的实现这一事实来对此进行解释。 然后，这些时刻就会开始积压。
我相信，所有这些任务在发布后提出，并且都是由于规范开发不完善而导致的，也是错误。 代表产品质量的错误。
事实证明，业务分析师确定需要创建哪些功能。 开发人员创建它们。 测试人员发现两者的工作都有缺陷。 这就是传统开发方法的工作方式。 但是您可以教会这三个人一起工作，立即更好地完成他们的工作，而无需进行其他更改。 这种通信方式称为3 Amigo。 也称为“故事开场秀”或“三合会”。
3 Amigo是...
3 Amigo是一种对将交付给客户的东西具有普遍理解的做法。 它有助于传达团队的声音，而不是散乱的意见交织在一起。
团队内部的这种沟通方式有助于：
- 在发展之前就期望达成共识
- 就如何立即做正确的事情达成协议
它还有助于理解：
- 我们要解决什么问题
- 有什么解决方案
- 我们需要做什么才能使任务准备就绪
这三个朋友的会议是一种共同思考的方式，可以弥合在理解业务规范方面的差距。 她帮助开发很酷的用户故事。
我们的目标是按时完成工作，但同时不要提前计划，以免细节过时。
为什么是3？ 谁在申请？
惯例的名称并不将我们限制在三个上下文中，而只是创建一个最小的框架。 为了确保在需求的开发中考虑到所有技术上的细微差别，显式和隐式的情况，该规范反映了客户的实际需求-需要3种不同的思维/上下文：业务，开发人员，测试人员。 而且，会议不仅限于这些人。 它涉及参与需求实施的每个人。 例如，如果您的任务不仅具有网络，还具有移动性，那么您需要其他上下文。 也就是说，将在移动应用程序中执行实现的人。 在我们的团队中，最经常有4位开发人员（1位ios，1位android，1位后背，1位前端），测试人员和业务分析师参加会议。
业务分析师或采购订单
业务代表（几乎总是）知道他最终想要得到什么，以及客户和企业将从中得到什么价值。 重要的是要谈论这个团队。
参加Amigo 3会议的业务分析师与参与者共享信息，以便团队中的每个人对用户的故事都有相同的理解和期望。 同样，只有他可以限制接受标准的范围，然后才可以接受。
开发者
开发人员知道如何实施业务需求，这有什么机会。 通常，他会考虑他需要了解的细节才能开始实施。 通过根据他的经验和对系统的知识提出问题，即使在需求讨论阶段，开发人员也可以帮助揭示各种细微差别。
测试仪
与其他团队成员一样，测试人员可以通过各种测试用例来丰富需求。 根据他的经验，他越来越多地对团队的任何言论表示怀疑。 因此，最好找到极端情况，隐式场景，想知道可能出什么问题，应注意什么。
该做法何时适用？
我很少看到明确提出需求的开发过程。 在大多数情况下，在开发或测试阶段就开始研究需求，然后才发现一些不一致之处。
未经测试的规范可能会有含糊，矛盾，不完整，重复甚至有时过时的要求，这是因为每个人都以自己的方式理解阅读和听到的内容。 因此，解释上会出现差异。
而且，如果文档又大又详细，那么阅读它可能要比测试或开发过程本身花费更长的时间。
在我们的业务线中，我们决定在任务开始拖延测试时采用这种做法。 我们确定了3个主要问题：
- 在测试阶段，由于需求澄清，产生了许多退货。 当业务分析师确定应该如何工作时，这些是测试和开发中的明显暂停。
- 由于规格太详细，导致任务测试被延迟。 案例很频繁，当测试人员仅花3-6个小时来研究需求并开发测试用例，而测试本身就花费了大约30分钟的时间，而最令人震惊的是在学习了2周的规范后开始测试的情况。和详细。
- 好吧，最常见的问题是在验收测试期间有很多错误。 如果在开发之前就已经考虑过这些bug，则可以避免。
因此，事实证明，尽管开发敏捷，但技术规范仍处于工作阶段。 而且，如果您不考虑某些情况，因为客户没有谈论这些情况，或者没有按照自己的意愿去做，那么在进入产品之后，积压了很多任务，甚至需要进行修改。
最后，值得用评估来表达问题。
当您真的不了解尚需完成的全部工作时，很难评估任务。 编写多少测试，由于错误或由于规范不正确而导致的变更，会有多少回报？ 即使开发人员自己对开发时间进行了准确的评估，您几乎也永远不会猜到不可预测的测试阶段将花费多少时间。
练习AC的步骤
1.我们将需求制定为用户案例
我建议申请根据用户案例开发需求。 并且作为一个故事的基础，并在一次会议上由3位好友进行研究。
在此，非常重要的一点是，业务需求实际上已被公式化为用户案例。 也就是说，它本身包含三个部分：
我作为<角色>，我想要<动作>，所以<动机>
这实际上是最受欢迎的自定义讲故事模板，称为Connextra。 还有其他模板，但我建议使用此模板。 为什么，现在我将解释。
传统上，形成用户故事时存在两个问题：
- 录制时，要么不指明角色，要么留下行动和动力
- 或者，他们指出角色和行动，并抛出动力。
这实际上会引起问题，我将尝试用简单的示例来说明哪些示例。
- 作为团队成员，了解“角色”后，您将更好地理解您需要制定的接受标准的界限。 尚不完全了解，在此用户故事中的相关人员，您可以执行必要的功能，反之亦然，以执行某种功能。
- 范例 ：团队不了解用户故事中的角色，因此在完成任务时，他们决定对api执行3种方法：添加，编辑和删除。 并且在最前面，他们将添加调用这些方法的按钮。 当他们向业务提出决策时，他们收到反馈，即客户实际上是需要添加方法的特定业务分析师。 而且他不会删除和编辑。 是的，他可以通过邮递员调用此方法。
- 团队不了解他们为其创建用户故事的“角色”的动机。 由于误解，用户故事本身的边界轮廓不清晰。 除此之外，最终的接受标准可能无法解决最终的客户问题，尽管它们将与用户故事中表达的动作相对应。
- 示例 ：一个团队雇用了一个用户故事，而业务分析师无法清楚地阐明动机。 一方面，她要让客户忠诚，并为他做一个改善。 另一方面，降低了银行的成本。 在这种情况下，实施方法和接受标准完全不同。 因为在第一种情况下，团队专注于用户接受标准。 第二-团队关注如何使最简单，最快的实施成为可能。
但是，上述格式不是前提条件。 我知道团队以Amigo 3格式召开会议，并且没有用户故事。 并以传统知识为基础。 在这种情况下，存在陷阱，但这是团队的明智选择。
Meeting 3 Amigo从准备开始。 在准备过程中，制定了要求，以便整个团队可以理解。 这些要求已经过验证，可以开始工作了。
验证包括根据INVEST标准评估历史记录。 以及故事本身的措辞质量。 在这里，任何歧义，冗长都被排除在外，并且在由INVEST评估时，要特别注意故事的大小。 如果团队知道该需求是史诗级的，那么就会分解。
需求经过转换到用户故事和团队验证（3 amigo）的阶段之后，我们可以着手制定接受标准。
2.我们在3 Amigo会议上补充了用户故事的接受标准
首先，您需要确定哪些接受标准都相同。
因此，验收标准是客户的要求； 可以检查/用户故事系统的规范。
它们有一个替代名称，即满足条件-满足期望条件（作者Mike Cohn）。
在3个Amigo团队的会议上，已经准备就绪。 他们已经有一个经过验证的用户案例，其中可能已经有一组业务代表独立制定的接受标准。
在会议期间，与会人员的任务是用足够数量的接受标准来补充/丰富历史记录，以供后续实施。
验收标准不应包括实施细节。 实际上，接受标准是控制正在开发的用户故事的业务规则。 实施细节会记录在验收测试中，但要制定所有验收标准。
仅仅因为在有限的时间范围内，您作为一个团队就可以始终“抛弃”一些对业务而言不太重要的标准范围，所以不应该将实施细节与验收标准相混淆。 如果标准中包含有关技术实施的详细信息，则您可能会丢失重要的信息和时间，这些信息和时间已经花费在讨论实施细节上。 您的实施细节直接取决于您需要执行的条件的范围。
另外，请避免使用一组步骤对场景进行顺序描述（经典测试用例管理系统）。 您的任何声明都应该是原子的。 最好对所创建函数的预期行为使用描述性样式。
例如：
* , .*>
3.我们保持时机
一个分解良好的美国通常不包含超过10个接受标准。 如果在讨论过程中找到了大量接受标准，并且所有标准都必须执行，则必须将此故事分解为具有不同接受标准池的多个故事。
如果不这样做，那么3 Amigo的会议将大大延迟。
召开3次Amigo会议的最佳时间是30分钟至1小时。
在开发之初，即团队正在学习交流和实践时，可接受的增长。
如果一个团队需要讲一个大故事，那么他们不可能在一堂课上就能够制定出所有标准和验收测试。 因为失去了注意力和注意力。 在这种情况下，您需要将会话分成几个会议。 但是在这种情况下，存在失去背景的风险，并且可能需要在第二次会议上进一步沉浸。
4.为了完成对标准的研究，我们使用了USR启发式
当我向团队教授这种做法时，我建议在他们的职业生涯之初就使用启发式方法来消除经验不足的情况。 凭借经验，团队在制定标准时拥有自己的启发式方法和清单。
USR试探法可让您在所有级别上考虑必要的条件，以获取有关客户需求的最大信息。
所以
- 用户 -用户想对系统做什么？
- 系统 -系统应该怎么做？
- 风险 -可能出现什么问题？
首先计算出USER组的所有条件，然后再继续进行系统级操作，这一点很重要。 在这里，包括前端和后端开发人员，并且他们可以在他们的系统级别制定接受条件，以实现来自USER组的条件。
最后是RISK乐队。 大多数情况下，尽管需求同样重要，但人们却忽略了需求的详细说明。 它涵盖了您可能无法实现的各种复杂情况。 但是必须大声疾呼并接受团队的风险。
在开发之前应用实践来开发测试用例的方法
形式化需求的推荐方法是用例，在俄罗斯IT中，我们称为测试用例。
在3 Amigo会议上，有一个方便的工具可以计算测试用例，称为示例映射。 在本文中，我简要地谈到了这一点。 在下一篇文章中，我们将发布有关此工具及其在三合会会议框架中如何使用的详细信息。
测试用例可以实现为历史记录的自动验收测试。 另外，在处理测试用例时，请确保将它们分组。 将测试用例分为几类是一种将故事分为几个较小的类的方法。
在测试用例中，业务规则的分解完全发生在将要实施它们的系统级别，而不是用户。
所有实施细节都必须在您的测试用例中，以便它们在实施过程中专注于开发人员。
它在一般流程中的外观（当您需要召开会议时）
建议您在一次会议中只为一个用户案例制定要求。 如果这些故事很小，或者含义相互关联，则允许更多。
由于在sprint中您需要准备工作的故事，因此在计划之前应召开3个Amigo故事会议。 否则，您可能会冒初步估计错误的风险。 实际上，在3 Amigo会议之后对故事的评估与原始评估有很大不同。
同样，将一个新项目添加到DOD中作为准备就绪的指示是有意义的，因为该故事已准备好在sprint中进行处理。
例如，我们有一些团队已开始采用这种做法，并同意如果没有针对该任务的接受标准和接受测试，他们将在计划期间不进行冲刺。
在冲刺审阅中，根据验收标准对故事进行验收。
但是同时，如果团队正在工作而不是争执不休，例如使用看板，则开会3 Amigo也适合该过程。 在这种情况下，该任务只有在经过3 Amigo会议后才能制定。
3 Amigo会议的结果是什么？
- 脚本/示例（显而易见的答案）
- 规定规则/验收标准
- 新的/分解的故事
- 对问题领域的共识
- 同情（同情，参与）
这三个朋友的主要结果是以“ 给定/何时/则”格式编写的验收测试。 实际上，编写它们可能需要的时间比我们想要的时间长，因此不建议在所有人聚在一起的会议上正式确定所有要求。 通常，开发人员或测试人员可以立即使用。 一旦他们记录了所有标准和测试用例，三位Amigos便会简短地查看发生了什么，以确保每个人都同意所记录的内容。
3 Amigo的使用实践的利益
Amigos 3策略可以对整个团队的效率以及项目的质量和可持续性产生巨大影响，从而提高可操作性和变更灵活性。
这里还有一些额外的奖励：
- 在计划时，我们不会花费太多时间将自己沉浸在历史的意义中。
- 尽早发现混乱和误解，从而加快交货速度
- 确保团队将讨论必要的工作量
- 帮助查找所有验收标准和其他质量属性。
- 测试用例的开发要容易得多。
- 我们鼓励开发人员使用测试覆盖代码
- 我们很快得出结论，不需要此功能
由于不正确的规范，我们的团队通过实践可以减少任务的返回。 伙计们学会了“第一次”开发后端任务。 也就是说，没有错误，并且立即出现在产品上。
陷阱
- 不要只限于三个人。 如果您需要更多-请致电。
- 不见整个团队。 在此会议中，必须最少要有多少人才能实施该功能。
- 不要将其视为例行会议-一种仪式。 否则，团队会因增加会议次数而产生负面影响。
5月27日至28日，作为RIT ++节的一部分，在QualityConf会议上，我将使用3 Amigo的实践进行关于需求开发的大师班。
如果您对该方法感兴趣并且有疑问，也可以通过电报@Travieso_nastya与我联系。
进近历史
该方法的作者： George Dinwiddy，2009年。
他在采访中描述了这种方法，并在一些文章中提到了我所链接的链接。 另外，作为补充材料，我将所有参考文献都附加到英语资源上，据此我学习并学习了这种做法。
https://www.agilealliance.org/glossary/three-amigos/
https://www.infoq.com/interviews/george-dinwiddie-three-amigos
https://www.agileconnection.com/article/three-amigos-strategy-developing-user-stories
https://www.stickyminds.com/better-software-magazine/three-amigos