TDD恐惧、不确定性和沮丧的扩散

Code-Dog：早上好，Pop。你早到了。现在才10点。

Vpop: 是的。我一直在听这个播客，想尝试一下其中的一些想法。

Code-Dog: 哇！你在做什么？考试课？

VPop: 嗯, 当我构建代码的时候，我正在构建一些微测试，并且-

Code-Dog: 你什么？你是说写测试*当你构建代码的时候？您的意思是在构建代码之后，并且只有在Sprint结束之前还有一些时间。

VPop: 不，我是说在那之前我在写测试，它叫TDD和-

Code-Dog: 伙计，我听说过测试驱动的开发，这是一些糟糕的东西！

VPop: 我有一本叫做TDD的书，我正在试一试。

Code-Dog: 你还记得即时掘金吗？会计？他的老板告诉整个团队他们必须开始做这件事。他们都不知道.所以他们后来写了测试，我想他们做的还不够，因为他们还没有部署他们的应用程序。

VPop: 嗯那个项目是一堆臭虫。所以是的。我试一试，以防我们的经理逼我们这么做。

Code-Dog: 嗯，不可能。在那之后，公司里所有的其他经理都太害怕了。

VPop: 当队里没有人知道怎么做的时候，他们会期望什么呢？

Code-Dog: 就是这样啊？你现在正在学习，所以他们可以让我们以后再做。伙计我不知道.。也许你最好不要这样，这样我们就能让工作还是一件美差！

VPop: 你知道吗，上一次Sprint，我花了大部分时间来追踪生产中的一个问题？一定是代码合并改变了处理程序的级别

Code-Dog: 是啊，真的是太烂了。但是大家都知道你需要解决这个问题。

VPop: 但我们不需要有这个问题。如果我们对所有新的代码更改执行了TDD，我们将致力于添加新的功能，因为我们不会有bug了

Code-Dog: 算了吧，没有虫子？你见过这种事吗？永远没有bugs？

VPop: 我听到了，但是的，我在其他公司的一些朋友每天都在发送新功能， 他们只是不发送一些自动测试失败的东西。如果你做很多测试，那么你就不会有错误。

Code-Dog: 有理有据。但是，编写大量的自动化测试需要大量时间，不是吗？我的意思是说这个早上你花了多久时间？我打赌你现在应该已经完成了.

VPop: 是啊，我在学.嘿，失去一个人冲刺修复错误已经减慢了我们的速度。作者和这个敏捷思想播客都说，许多开发人员在编写代码时花费了50%或更多的时间在调试器上跟踪问题。

Code-Dog: 你猜对了！确认电脑才是用正确的方式运行的。

VPop: 完全正确！您正在手动对代码进行单元测试，您所做的确认将永远不会再运行。但是…

Code-Dog: lay it on me Socrates

VPop: 但是，如果我们在编写代码时添加测试，就会捕获开发人员的意图。这些微测试将被检入并执行，以此永远防止代码倒退。

Code-Dog: 嗯。坚持住，勇往直前。奖金时间快到了。你会在这个TDD上拿你的奖金冒险吗？得了吧，TDD是不是花了你更长的时间来完成这个故事？

VPop: 好吧.。是啊，我确实觉得慢了点。这让我觉得困难多了。

Code-Dog: 如果你搞清楚了，你可以教我。至于我，我得去工作了。

Narrator:一个早期的采用者，VanillaPop，已经发现了TDD，并且正在尝试应用它。Code-Dog只是一个恐惧，不确定性和沮丧的来源。这种常见的开发人员习惯，害怕走向不确定的道路，来自于坚持承诺的条件，有时甚至失败。因此，当一个团队面对创新时，可能会迫使其成员避免创新并坚持下去。作为团队成员或经理，你的工作是鼓励这一创新朝着正确的方向前行。作为一名经理，你需要小心谨慎，不要像前面提到的经理那样指挥和控制他的团队到错误的情况，因为他们不具备成功的因素。

一个好的策略是提升那些有新想法的人，并给他们在FUD面前进行实验的空间：恐惧、不确定性和沮丧。衡量他们的实验成功，然后，如果战略显示出成功的迹象，有创新者配对计划与其他人，直到整个团队有新的能力。

下一集我们将看到vinillapop恐惧不确定性和沮丧的表现。