如何在BDD规范研讨会上取得成功？

今天，我们试图通过举办一个规范研讨会将BDD引入我们的软件开发过程中。

在这个研讨会上，我们有2个开发人员，1个测试人员和1个业务分析师。研讨会持续了1h30，到最后，我们设法为我们的新功能找出了一些BDD方案。我们试图集中精力寻找可能错过的场景和困难的场景。

在研讨会结束时，实际上有些人对研讨会不满意。

一位开发人员觉得他浪费了时间，因为业务分析师习惯于直接向他给出方案并与她一起进行审查。业务分析师对我们的方案覆盖范围没有信心（感觉我们可能会漏掉其他重要内容），但更重要的是，因为她本可以自己弄清楚所有这些方案，所以这次研讨会也是浪费时间并且在较短的时间内。

这个实验性的研讨会持续了1h30，到最后，我们对所做的事情没有足够的信心...确保我们可以花更多的时间在上面，但是老实说，大多数人在1h30的头脑风暴后精疲力尽以开展业务来自广管局的规则。

所以我的问题是，这种研讨会实际上如何运作。从理论上讲，给定要开发的新功能，您可以将树“ amigos”（dev / tester / ba）放在同一个房间中，以便他们可以协作使用示例编写新功能的不同要求。我可以看到所有的好处。特别是在知识共享和共同产品/最终目标/完成的愿景方面。

我们从这个实验的结论是，它实际上是更经济有效的方法首先对例子BA工作在他自己的，只有再有场景进行审查/由3“吾友”返工。通过让广管局独自工作，我们实际上更加自信，我们将不会错过任何东西，而我们仍然可以在事后审查方案以进行双重检查。我们认为，仅凭一次简单的头脑风暴/刻意发现会议就不足以真正满足一项新功能的所有要求。业务分析师实际上是此类人员的最佳人选。我们能做的最好的事情是回顾她写的内容，然后看看我们是否有共同的理解（这可能导致重写她的某些情况或添加她可能错过的新情况）。

那么，如何才能在实践中有效地发挥作用呢？

如果您可以从描述中得出场景，那么您就完成了。

我经常在BDD中看到的一种反模式是，人们感觉需要详细讨论每个场景并写下来。

某些场景已被很好地理解，足以从简短的描述中得出它们。例如，如果我说“我希望本周登录功能”，您就会知道应该是什么样子。您知道存在正确密码，错误密码和错误用户名的情况。我们真的不需要讨论这些细节或详细捕获它们。

同样，我可能会说：“这是用户注册的表单。我们需要能够创建新用户，让他们编辑其详细信息并删除自己，但删除实际上并不能删除，而应该将他们标记为已删除。因此他们可以根据需要恢复其帐户。”

您可能会问：“帐户恢复是否是此功能的一部分？”

“如果需要，它们可以是两个功能。”

“好的，所以我们有创建，读取，更新，删除的场景；这应该很容易。让我们谈谈帐户恢复；听起来更有趣。”

通常，如果行为描述足以使开发团队获得场景，则无需进行讨论。如果有任何疑问，您可以这样做，但是如果您完全捕获任何场景，则可能只想捕获需要记住的场景。

如果您以前从未做过，或者不确定，请讲解这些场景。

将重点放在不寻常的区域上，特别是如果您具有以前从未做过的功能。这些都是进行对话和写下任何令人惊讶的例子的好地方。根据BDD模板，我通常会问两个问题：

给定上下文
当事件发生时
，则应发生结果。

• 是否有其他情况对于同一事件产生不同的结果？
• 还有其他重要的结果吗？

如果桌上的每个人都觉得无聊，那么您正在谈论的功能可能会很容易理解。通常足以说：“它应该像X一样工作，但应使用Y ”。这就是Dan North所说的Ginger Cake模式。就像巧克力蛋糕的食谱，只是用生姜代替巧克力。

即使业务利益相关者能够自己得出方案，对于开发团队来说，能够与他交谈，选择和内化他的语言也很重要。然后，该语言将被带入代码中，使他们能够在将来进行更好的对话，并帮助项目的新手了解正在发生的事情。如果开发人员不会讲这种语言，他们将不会使用它。

如果业务利益相关者或分析师真的不想花时间在会议中捕获事物，我宁愿开发人员与测试人员合作写下场景，然后请他进行审查。与反之相反，这更有可能发现误解。

有时BDD不起作用。

另一种可能性是您发现业务涉众不确定的情况。“哦，我没想到！我不确定。” 与其尝试确定业务并确定其业务，不如现在放弃BDD并尝试一些简单的方法以获得一些反馈并为业务提供一些可以迭代的方法，而不是试图确定业务。保持易于更改，并在对发生的事情有了更好的了解后编写方案。

BDD做得很好确实可以帮助发现不确定性的地方。由于每个项目值得做有它的某些方面，这是新的，从来没有做过的事情，还有就是在那里，地方一些不确定性。如果您专注于使用场景来帮助有意发现无知，那么您将学得更快，而学习通常是项目花费的大部分时间。

此外，我发现开发团队以这种方式进行协作的次数越多，企业就越有准备以不确定性信任他们，并且开始出现更多的创新。从本质上讲，创新型公司的项目存在很多不确定性。

不久前，我在Cynefin上写了一篇博客文章，我发现它确实可以帮助我了解对话在哪里最有效。如果您阅读并理解这四个领域，这是我使用的规则：

• 简单和复杂的东西（已知）通常是很容易理解的，您不需要详细讨论场景。

• 完全不了解高度复杂的内容（未知）。您可以通过讨论场景来发现这一点。缺乏确定性意味着BDD在这里不起作用，因此对容易更改的内容进行迭代并获得快速的反馈。在此领域，任何保留您的选择的练习，例如AB测试，也都很棒。

• BDD在（已知）之间的空间中作为传递知识并发现其他两个空间的机制，表现出色。这不是锤子，也不是万能的钉子。实际上，如果您可以将时间花在与任何事情进行对话上，那么这与您可以找到的示例无关。是关于找到您无法找到的示例。

会议的时间长度不是您的问题。这些会议可以进行很长时间。但是每个人都应该感到自信。他们没有是您的问题。

我建议召开一次简短会议，讨论一项要求。安排几天后的第二次会议，这样每个人都知道他们必须在那时做好准备。

然后，BA和测试人员应各自提出自己的方案，因为他们俩都以非常不同的方式看待软件。让他们将它们写在卡片上并将它们全部粘贴在板上的某个位置上，至少在第二次会议之前的一天，让每个人都在自己的时间中仔细检查并仔细考虑。丢弃所有重复项，坚持不考虑的任何方案。

不要丢弃您不同意的任何东西，而应将其标记为有争议的。如果与编写该文档的人进行简短的交谈会有所帮助，则可以这样做，但主要是保存下来。

然后举行您的计划/设计会议。为该会议制定稳固的议程（从一堆纸牌开始，将有争议的纸牌放在顶部），并且不要让它偏离轨道。确保您退出会议并解决所有争用点。

始终确保会议中的每个人都为该会议的主题做好准备！

永远不要使用会议来“头脑风暴”任何事情。浪费大家的时间。

有效会议的一般方法：

• 有人准备要讨论的项目
• 要求所有参与者研究（而不是仅仅阅读）这些项目
• 事先收集评论，并要求所有参与者研究（而不是阅读）它们
• 召开会议以做出决定

关于投诉...

让我们从这些开始：

一位开发人员觉得他浪费了时间，因为业务分析师习惯于直接向他给出方案并与她一起进行审查。

他在车间里正在做什么。所以这对我来说似乎是一个喜怒无常的借口。我怀疑这个开发人员只是不喜欢其中一个（或两者兼而有之）对车间及其计划约束的审查。

业务分析师对我们的方案覆盖范围没有信心（感觉我们可能错过了其他重要内容）

这与她有更多人在看它的事实相比，与她一边做并由开发人员进行审查有什么不同？我怀疑这只是研讨会的结果，可能有点混乱。通过实施和集成它们，您将确信自己有足够的测试。您永远无法确定自己找到了所有错误，而涉及到覆盖范围时，最好的方法就是在用户案例中绘制它们。

但更重要的是，这次研讨会也浪费了时间，因为她本可以在较短的时间内自己弄清所有这些情况。

是的，完全是她自己的，在她的围墙花园里，没有分享知识。鉴于此，将来的讲习班可能会更有成效，因为所有参与者都对如何处理这些事情有了一点了解。

也许这次会议很慢，但这并不意味着它将一直如此。作为一名外部人员，我将接受一些培训以使其正确无误，从而使我更有信心在一个研讨会上的报道会更好，该研讨会由3个具有不同心态的参与者和一个独裁者组成。

另外，如果开发人员已经需要与她一起审查这些情况，那么我可以肯定的是，在讲习班中来回操作要比使用“我自己做我的东西然后把东西给我您，您可以单独查看并返回给我，让我们再做一次。”

意见建议

• 保持积极，并强调，如果流程正确，您会做得更好。

• 尝试简化研讨会并保持进度。

• 通过与每个人自己设计一些方案（甚至在研讨会之前更好）来开始研讨会，然后为它们进行分类和合并，也许为“独狼”分析留出一些空间。

而且，如果您不认为需要进行集思广益，那很好：让广管局独自工作，但至少要在研讨会之前进行审查。在更多的眼球越好，引用埃里克雷蒙的林纳斯定律：

Given enough eyeballs, all bugs are shallow.

您已经在这里有了一些非常不错的答案，因此，我将专注于一个迄今为止被忽视的小方面。这三个朋友的角色应该能够发挥作用。他们每个人以不同的方式提供价值，他们每个人都理解不同的约束。

通常，BA应该能够为会议带来主要的成功途径，从业务的角度来看，他们也应该能够提供主要的失败情况。测试专家应该能够确定极端情况和其他必要情况，以证明系统在所有情况下都能正常工作。开发人员的工作并不是添加场景，尽管他们经常会遇到技术故障，但他们的工作也确保了他们对需求有充分的了解，因此他们可以传达影响并以最少的额外沟通来实现需求。