# 22 黑衣团队

如果你曾经在有凝聚力的团队中待过，那么这种团队对你的价值是显而易见的。如果没有，就让我们在这一章来告诉你这样的经历究竟怎样。下文描述了一个在 20 世纪 60 年代富有传奇色彩的团队。团队的一些事迹被夸大了，但还算合情合理，至少大部分都是真实的。

### 传奇团队的人员组成

话说在 IT 行业的曙光时期（大致而言），在纽约州北部有这么一家生产大型蓝色电脑的小公司，同时，这家公司还要开发运行在这些电脑上的软件。公司客户很友善，但说实话，公司交付的软件实在不怎么样，总是缺陷不断。在一段时间里，公司花了不少精力去培训他们的客户，期望他们更能够容忍软件的缺陷。这个方法没有奏效，因此，他们不得不下定决心消除这些缺陷。

简单明了的方法是让程序员在交付前消除所有的缺陷。因为一些原因，这种方法未能行之有效。似乎程序员们（至少是那个年代的）都信心满满地认为自己写的程序是最好的。他们尝试去寻找缺陷，却找不到，然后通常在还存在很多缺陷的情况下，宣称软件已经完成了。

要找到最后的缺陷很难，但一些测试人员能够做得更好：于是公司集合了一些才华卓越的测试人员，分配给他们任务，要求在关键软件交付给客户之前做最后的测试。于是，具有传奇色彩的黑衣团队( Black Team)诞生了：

一开始，黑衣团队仅仅是一群证明自己测试能力更优秀的人。他们的动力更强一点儿。他们也会测试别人写的代码，因而可以避免开发人员测试自己程序时先人为主的偏见。归根到底，对于组建这样一支团队的人来说，他们期望至少能适当地提高产品质量。然而，他们的收获比预期更多。

黑衣团队最让人吃惊的不是他们在一开始有多好，而是在接下来的一年时间里他们改进了多少。一些神奇的事情发生了：团队形成了自己的个性。在测试的对抗哲学影响下，这一个性在团队成员中形成，它让大家积极主动地去发现缺陷。他们并不完全是为开发人员提供支持，恰恰相反，他们乐于提交一个程序（包括程序员）去接受一系列测试，更像是一种考验。提交你的程序去接受黑衣团队测试，就像去经受冷血魔王的考验一样。

### 可怜的地球生物，谁能能拯救你们呢？

一开始，只是简单地开玩笑，说他们的测试刁钻刻薄，团队成员最爱的就是把你的程序搞挂掉。一段时间盾，就不是开玩笑了。团队开始树立起毁灭者的形象。他们毁灭的不仅仅是你的代码，而是你这一整天。他们使用各种惨无人道的手段来造成程序失败，比如缓冲区过载、空文件比较或者输入无理的长字符串。看着自己的程序被如此邪恶的方式给践踏，无论男女，都要忍不住落泪了：可你越感到难过，他们就越开心。

为了加强邪恶形象的效果，团队开始身着黑衣（此乃黑衣团队得名的由来）。一个程序失败，他们会高声发出可怕的怪笑。一些团队成员蓄起了长胡子，卷曲着像凶残的工头 j 他们聚在一起搞出诸多狠毒的测试方法。程序员们开始抱怨黑衣团队这种病态的折磨。

不用说，公司自然乐见于此。团队找到的每一个缺陷都不是客户发现的：团队获得了巨大的成功。作为一个测试组织，它成功了，但更重要的，就咱们这里谈论的话题来说，团队作为一个社会单元成功了。团队里的成员共同取得如此成就，以至于团队外的同事都开始善意地嫉妒了。黑色的着装以及刻意的夸张表现是乐趣的一部分，但这里有更基础的东西。团队内部的化学反应本身成了目标。

### 小结

随着时间推移，团队成员逐渐转移到其他事情上。由于团队担负了如此重要的任务，每离开一位就会有新人加入，这样一直到全部原班人马都离开了团队。但黑衣团队仍然存在，团队失去了原来的所有人，但团队昀动力和个性依然存在。


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://doc.shiker.tech/ren-jian/di-si-bu-fen-gao-xiao-tuan-dui-yang-cheng/22-hei-yi-tuan-dui.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.