我可以使用哪些论点将BDD概念“出售”给不愿意采用它的团队？

我有点支持“行为驱动开发”方法论（又名BDD）。我已经使用BDD已有两年了，并且在开发DotNet应用程序时采用StoryQ作为我的首选框架。即使我已经进行了多年的单元测试，并且以前已经转向测试优先的方法，但我发现使用BDD框架会带来更多的价值，因为我的测试抓住了相对而言需求的意图。在我的代码中清除英语，并且因为我的测试可以执行多个断言而无需在测试进行到一半时结束测试-这意味着我可以一目了然地查看哪些特定断言通过/失败，而无需进行调试即可证明。

对于我来说，这确实是冰山一角，因为我还注意到，我能够以更有针对性的方式调试测试和实现代码，从而提高了我的生产力，并且我可以如果由于输出进入构建日志而导致问题一直困扰到集成构建，则可以轻松确定发生故障的位置。此外，StoryQ api具有很好的流利语法，易于学习，并且可以以多种方式应用，不需要外部依赖就可以使用它。

因此，有了所有这些好处，您会认为很容易将概念引入团队其他成员。不幸的是，其他团队成员甚至都不愿看StoryStorQ来对其进行正确评估（更不用说应用BDD的想法了），并说服彼此尝试从我们自己的核心测试框架中删除许多StoryQ元素，甚至尽管他们最初支持使用StoryQ，但是即使他们希望删除的代码也不会影响我们测试系统的任何其他部分。这样做将最终导致整体上显着增加我的工作量，并且确实与实际情况背道而驰，因为我通过实践经验深信，这是在特定的工作环境中以“测试优先”的方式工作的更好方法，只会导致更大的工作量。鉴于以下情况，我们的软件质量得到了改善 我们发现更容易坚持使用BDD进行测试。为了进一步澄清，我们大多数的单元测试往往都很脆弱且难以维护，多年来由于应用程序测试不佳而导致的结果是，由于不愿坚持测试驱动的流程，开发人员退回到了旧习惯，在项目结束时进行所有测试（这些人声称自己是敏捷的！）。

因此，问题实际上归结为以下几点：

1. 我可以使用哪些论点来真正说明这个团队使用StoryQ或至少采用BDD方法会更好？
2. 您能否指出我能用来支持我的论点以采用BDD作为我们的标准选择方法的任何轶事证据？
3. 您能想到什么相反的论点，这可能表明我希望鼓励团队采用BDD的想法可能是错误的？是的，只要论据是合理的，我很高兴被证明是错误的。

注意：我并不是在主张我们全面重写测试，而只是为了以后的所有测试工作而以不同的方式开始工作，最好以与客户互动的方式开始。

对于希望进一步了解BDD的人来说，以下链接可能会有用：

• http://dannorth.net/introducing-bdd/
• http://en.wikipedia.org/wiki/Behaviour_driven_development
• http://behaviour-driven.org/简介

_{对于那些对更多细节感兴趣的人，我们是一个由4人组成的小型团队，致力于大约5个大型项目。BDD的“试验”最初进行了大约2个月，随后又进行了大约4个月。团队接受了我应该继续以这种方式工作并进行自己的尝试。自试验结束以来，我一直从事BDD工作约两年，而其他人则非常擅长回避问题。我不是在问题上施加“对抗”，而是在寻找一种方法来温和地说服团队摆脱集体的落后，并抽出时间来做好自己的工作。}

我可以使用哪些参数来真正说明最好使用StoryQ或至少应用BDD方法？

“客户想要它。”

IMO您希望至少将BDD出售给您的客户/领域专家，也出售给开发团队。

BDD是一个由外部参与的协作过程，其中涉及多个利益相关者。BDD的好处不仅是让开发人员从验收测试中自动推断出他们的测试代码，还在于技术人员和业务人员之间进行的创造性合作，以产生有价值的，定义明确的系统预期行为规范。

给予客户/业务分析员访问界面的权限，他们可以在其中运行每个可执行规范，控制其状态并查看其实现的进度，这一点通常也受到人们的赞赏。

Dan North做了一个关于如何将BDD出售给企业的演示：http : //skillsmatter.com/podcast/java-jee/how-to-sell-bdd-to-the-business

1. 在不愿采用BDD的团队中，可能没有“论据”可用于将同事“转换”为全面采用。
    
   我认为您最好的办法是说服他们尝试一下（“烟雾测试”，“空运行”，“试点项目”）-特别是如果您非常清楚地表示，如果测试结果合格，您将放弃这个想法是负面的。
2. 您寻找轶事证据的方法完全符合说服团队进行尝试的想法。为此，我只是在网上搜索“行为驱动开发成功案例”之类的内容，然后选择对我来说更容易使用的内容。
3. 我可以想到一些相反的论点，这可能表明您希望将团队的努力转换为BDD可能是错误的。
    
   这些都不是特别具有建设性的，尤其是从“变革倡导者”的角度来看，但是不幸的是，您可能必须处理这种言辞（BTDTGTTS）：
    
   • 您不能保证整个团队的生产力都会提高
   • 您不能保证在采用BDD方面投入的精力会带来可观的投资回报率
   • 团队在没有BDD的情况下表现良好，没有理由改变现有方法
   • Google（或Microsoft或IBM-只需填写任何“受人尊敬的”软件供应商的名称）就可以在没有BDD的情况下正常运行，这“证明”不需要BDD
   • 非BDD方法在比较测试中没有机会
   • BDD通常可能没问题，但是对于该模块和项目而言，它不适用

根据我的经验，解决上述类似问题的最痛苦的方法是对建议的更改执行有限的受控测试。

“有限测试”状态基本上是无效上述三四个参数，但有一个关于“尊敬的供应商”，它可以通过提供被反击传闻证据的成功故事（传闻会不会可能是一个“大爆炸的变化”，但工作有限的测试就足够了）。

如果确实值得进行更改，并且安排了适当的试运行，您会注意到团队和管理态度的积极转变，使向全面更改的过渡变得顺畅而轻松。

有限的测试运行的另一个好处是，它使您可以澄清和调整目标过程的详细信息，而不会造成太多麻烦，并且对想法产生“声誉损害”的风险较低。每当我参加这样的测试运行时，我惊讶地发现，转换为全面运行的过程非常顺利，并在测试运行中设定并澄清了最重要的细节。

可能是时候招聘管理人员了。如果您尝试过并且看到了可观的结果，但是团队却步履维艰，则管理层可能必须参与其中。

如果他们正在伤害公司中生产力最高的团队成员，则尤其如此。为反弹做好准备。您可以从与管理人员接触开始，并试图通过提取测试用例来使团队停止削弱您的利益。