多年来，我们在很多不同的团队、不同的公司工作过，构建过很多类型各异的项目。我们一直在写书、写文章、在博客上发帖子，阐述如何才能更好地运作项目。在写作的过程中，有一个问题始终困扰着我们。我们的工作似乎就是不断提出一些规范的、“最好”的项目运作方法：如何制定项目计划，如何构建软件，怎样才能使项目不会中断。但是我们写的东西越多，访谈的人越多，对这种想法就越怀疑。
我们编写的第一本书可以看作是一套成功运作软件项目的实用指南，之后我们顺着那个思路继续进行着写作。我们在那些年做了很多研究、实验，做了很多实际项目，目的是找出可行的实践方法：制定软件项目计划的方式、开发人员编写更好软件的技术和测试软件的方法。我们把能够找到的、对自己最有用的方法都集中起来，放到那本薄薄的书中。多年来我们收到很多很好的、非常正面的反馈。很多人告诉我们，他们每天都在使用这本书。
但是事情从那时开始就有些不对头了。
我们掉进了在书中提到的一种陷阱，视野慢慢地变狭窄了，这真是有些讽刺的意味。我们把那套特定的实践方法看作是“成功”的实践。我们从未说过制定项目计划、估算项目、评审代码或测试软件的方式只有一种。但在接触实际项目并与越来越多的软件开发人员交谈之后，我们发现人们很主观地把我们归到了某一类人中。他们会说：“哦，Stellman和Greene—你们就是搞宽带Delphi法的人吧？我一直在使用这种估算法！”（这是真事，确实有人跟我们这么说过。）或者，更糟糕的是，他们会跟我们说：
“你们在书里讲到了需求规格说明，我从来不用那套东西，但是我开发的软件也不错。你们的观点肯定有问题！”
方法是客观存在的。方法是一些理论上的东西。你可以坐在那里谈论各种做法的优点，可以假想这些做法在不同的场合下是否会起作用。我们自己也有过这样的争论，对于何时收集需求、如何在项目中采用更多或更少的敏捷方法等问题上，大家争论得面红耳赤，最后也没有得出什么结论。这些确实是人们存在争议的地方。
但是说实话，工作的主要内容不应当是这些。当然，你做出决定的方式会影响项目，有时候影响还很大。但相比之下，团队中包含哪些成员却更为重要：他们的技能如何，他们在一起工作的融洽程度如何。那时我们认识到，为了构建更好的软件，实践方法只是其中一个方面。虽然我们把大部分时间都用在了这方面的研究与处理上，但是直到很久之后我们才认识到这个方面通常都不是最重要的。
于是我们开始设法让人们无拘无束地谈一谈他们自己的项目，听听他们学到了什么经验。
我们整理了一份关于最佳实践的访谈录并做成讲座的形式（最佳实践是我们平时写作的内容，也是我们最熟悉的），并且尽可能使用能够想到的、通用且不很正式的术语解释如何利用这些最佳实践方法更好地使项目运作起来。这是我们在写书和做项目时得到的经验，我们天真地认为人们在听到这些内容时会非常激动。我们谈到了应当避免什么样的陷阱，并且向他们提供了避开陷阱的工具。（“瞧，按照这种方式就可以有效地进行估算了！”）
但那个讲座彻底失败了。我们记得有一次讲座尤其糟糕（虽然与我们所做的其他讲座相比也不是很差）。我们应邀到一家大型网络公司在纽约的办公室，参加了一次外聘顾问系列研讨会。我们开始讲课，逐个讲解软件团队遇到的各种典型问题，总结了我们认为有助于防止这些问题的各种实践方法。我们从开发人员的面部表情看出他们越来越不耐烦，甚至很失望。他们大都很年轻，不到30岁。讲座进行到一半的时候，大多数人都在低头摆弄他们的PDA或笔记本电脑，有些人干脆起身离开了。到了最后的提问环节，我们终于知道他们的想法了。在我们提到敏捷项目计划时，一位身材高大、留着长长的灰白胡须的程序员提出了质疑：“敏捷的意思就是什么文档都不写，马上开始编程！”现场的每个人都点头称是。我们努力想改变那位程序员的思路—“不，敏捷并不是这么回事！”，但是没有用。我们没有办法说服他们，显然，我们是在浪费大家的时间。
我们本来是不应该对这种冷遇（对于那种情形，说是冷遇已经算是很好的了）感到吃惊的。毕竟，我们也曾有过耐着性子参加各种交流会议（项目管理组会议、架构师特殊兴趣小组会议、软件过程交流会议等）的经历。在一个让人印象深刻的讲座或讨论之后，必定会跟着十几个非常乏味的讲座或讨论，归根结底只不过是在为咨询公司、图书、某种专业产品或服务做广告。
所以我们反思了在那次讲座中受到的关于敏捷的批评。令人惊奇的是，虽然我们不赞成那个人的话，但他对我们的批评是有道理的。确实，这种批评乍听起来让人难以接受。
我们花了不少时间来分析那次讲座为什么会搞成那样。但是他的批评最终让我们认识到我们的方法有问题。“最佳”实践是不存在的—至少，没有哪一种已知的实践方法能够确保每次都取得成功。一种特定的工具或技术是否能够起作用取决于不同的场合：项目、人员，以及各种说不清道不明的、含糊杂乱的东西。我们并不是说不关心过程。我们没有远离我们使用和编写的实践方法。恰恰相反，我们仍旧每天都在使用，我们还在继续编写相关的内容，我们仍旧在为其他人提供培训，因为如果是合适的场合、合适的项目和合适的人，那么这些实践方法仍旧会起作用。但是有些时候，为了完成工作，是不能够按照“正确”的方法去做的。有时候什么方法都得用。
我们的收获是认识到了运作项目的方法其实有很多种。即使有一些用得非常好的实践方法，有时候也会发现有不适用的地方。多年来，在构建软件的时候，我们都需要采取更灵活的实践方法，更灵活地与团队一起工作。我们这样做是因为有些项目失败了。失败的项目不多，但确实是有一些。在项目失败的时候，也是我们学到经验最多的时候。
这为我们开辟了一条新的道路。我们努力想要搞清楚是什么因素造就了成功的项目，又是什么因素导致项目失败。起初很难找出一个特定的原因，而我们也怀疑答案不止一个。
当我们开始和周围的人以及我们认识的人交谈时，我们一次又一次地听到相同的内容：
人们在谈到他们真正用心投入的项目时总是充满感情；他们要告诉别人他们和糟糕的经理之间那些“难忘的故事”、曾经遇到的困难场合、克服过的问题等。事实上，只要问问人们他们曾经工作过的团队，他们就会情不自禁地回顾自己的职业生涯，回顾他们自己对其他人的影响。令人惊奇的是，和我们谈话的每个人，不管层次如何，刚走出校门一两年的初级程序员也好，从初级程序员一直晋升到CTO的人也好，都是这样。
我们坦诚地让人们讲述他们的经历，我们不想把我们自己的方法和观点强加给他们，我们越是采取这种态度，得到的意见也就越统一。随着我们自己进行的交谈以及与其他人进行的交谈越来越多，我们越发认为这些谈话都可以纳入4个不同的“桶”（因为想不出有什么其他更好的表达方式，所以用了“桶”字）中：人员（团队中有哪些人）、目标（人们走到一起是为了什么）、实践方法（软件是如何构建的）和障碍（什么因素制约了团队）。本书各部分内容正是按照这种思路组织的。书的最后一部分讲述的是一组音乐人的事，因为他们可以帮助我们更深刻地认识到促进团队工作的因素。
> 我来回应