Language agnostic 如何使团队相信软件开发的其他部分是重要的？

有时，当我向某些人介绍软件开发过程的一部分时，主管或经理会说他们没有经验，比如

自动化单元测试和集成测试与手动功能测试

使用代码生成器和脚本执行重复任务

我有时会遇到阻力。其中一些原因如下：

他们说这就是我们在这里做事的方式。我们的系统工作正常，无需在流程中添加

他们正忙着。他们说，他们的工作是为我们提供项目，我们的工作是让他们满意。如果是手动系统，重复但准时，他们会感到满意

他们对代码生成器非常保守。我给了他们一个估计，第一个项目需要花费大量的时间来使用它和时间来训练我的队友，因为这种方法对他们来说是比较新的。从长远来看，第一个项目的开销掩盖了它的好处，但我解释了它对我们开发人员的便利性，但他们总是坚持用老方法做事

你的策略是什么？

一个微笑和一把枪比一个微笑可以走得更远。
-卡彭

只是开玩笑，但我首先想到的是：）

---

枪是一个比喻（duh），就像是一个bug，有人花了几天时间才发现，有了一个好的流程，他就可以以更有趣的方式消费

我认为说服某人相信某事的唯一方法是揭示它所带来的好处。

等待问题出现，然后采取行动。

请求原谅比获得许可更容易

对于“改进”软件开发过程的投资风格度量，没有客观的回报。软件开发本质上是困难的——它是知识的获取——必须有未知因素。如果一切都知道，你就已经有了软件

因此，你永远无法事先说服经理

你只能证明你能做得更好、更便宜或更快。当他们问你工作效率的秘诀是什么时，你可以向他们展示你的工具、方法或方法

在他们问起之前，你没有足够的证据来改变任何人的想法。当他们最后问你时，你不需要改变他们的想法，你需要向他们展示你的解决方案

---

因为他们不想为了投资你的工具而破坏他们的“手工完成一切”计划，所以你必须分步构建你的工具，一次一个项目

一天下来，你必须成为一名推销员。你必须告诉人们为什么你的建议会让他们的生活更轻松

如果你能用一些花费的时间/节省的时间数据来支持你的主张，你就成功了。另一件事是通过同意分阶段实施变更，逐渐为自己赢得声誉。对项目的一小部分实施一个简单的更改，并证明它对他们产生了影响。然后再将其推出一点，然后进入下一步，如单元测试或代码生成。给点时间，它会自己解决的

我不相信你不能强迫人们读书，他们会把书放在书架上，认为你很讨厌。最好的办法是取得小的成果，并将其作为垫脚石，让人们能够瞄准更高的目标，因为人们意识到也许有更好的做事方式

---

如果你真的对它很感兴趣，你可以随时投入一点自己的时间，准备一个简短的演示（最多30分钟），向他们展示你可以多么快地创建一个没有代码生成的小应用程序，然后是一个代码生成数位的小应用程序。布丁的证据就在于吃东西。

我试过微笑部分，但没有试过枪的部分。JoelSpolsky说，要把一本好的软件开发书扔到Peopleware或务实程序员的脸上。也许这是一个好时机：）在这些时候，当心开这样的玩笑。你永远不知道联邦调查局藏在哪里Oo@Yoitfrancis引用CodingHorror的话，这只会让你的程序员或经理在书的弹跳处头部有一块瘀伤，并对你在那之前为什么没有搬过来大发雷霆。：）不如果你不能用简单的语言说服他们，那该怎么办：）你必须小心一点，不要被指责允许这种事情发生。此外，你需要避免做“我告诉过你的”。预防比治疗好，但更难说服人们，因为虽然预防很重要，但并不总是被认为是紧急的。“我告诉过你的”-不，我从来没有这样做过。我喜欢“提醒”这个词。提醒他们有经过测试的替代品。当他们遇到问题时，他们重新考虑你的解决方案的可能性很大。这是因为他们能够在某种程度上比较不同的做法。还有，我是谁来改变他们的“习惯”简言之，用你的方法给他们留下深刻印象。：）