结果导向和测试驱动(转)

原文转自thoughtworks员工gigix：
http://gigix.thoughtworkers.org/2012/5/8/result-oriented-and-test-driven
“结果导向”是个职场里很流行的词。六年前我跟 夏姐姐 去校园招聘，她说如果是招销售的话就会更多要求结果导向。然而我现在发现，所谓结果导向，其实跟 测试驱动开发 是同一回事。所以像ThoughtWorks这样很认同TDD的环境，即使不是销售，做事同样要强调结果导向。

类似的话题其实我 之前也讲过 。我还可以再举一个最近的例子，读者们一起来做做思维练习：

你是一个项目经理。你带着另外两个兄弟漂洋过海来到A国，客户是A国数一数二的保险公司S。你要跟S公司的人一起工作一段时间，然后回到中国来形成离岸外包的局面继续工作。可是事情没那么简单。S公司这是第一次把核心系统研发工作离岸外包，公司上下没人知道这事情该怎么操作。倒是负责风险控制的部门知道哪些事情不能做，比如说把源代码弄到中国这事就不能行，更不用说信用卡数据了，那是压根就不能允许在中国的显示器上出现。客户的团队对你们也持怀疑眼光，连自己公司在A国的同事也有点搞不清你们到底需要什么帮助。
现在，作为这个焦头烂额的项目经理，显然你有很多事要做。噢对了，你们的签证只有六周⋯⋯

你会做哪些事？你会首先做哪些事？

这时候我给这个团队的建议就是：你们需要测试驱动。如果要为这六周的onsite工作写一个验收测试，这个测试应该是什么？这个spec应该写着“可以离岸外包”。如何测试可以离岸外包？你需要让至少一个人尽早开始以离岸外包的方式工作。当你们在A国的时候，这个人从中国开始以离岸外包的方式工作了，客户开始为他付钱了，这个测试就通过；反之，不管你在客户现场做得再high、客户对你再满意，当你回国以后一定会出问题。

这一个验收测试又会被细分为更多的功能测试，例如“可以访问源代码”、“数据安全通过检查”⋯⋯最终某些功能测试真的会被实现为自动化的测试代码，另一些将会是人为的检查点。重点在于，你在客户现场要做什么、要先做什么，不是由你预先设计的，也不是拍脑袋拍出来的，而是由验收测试驱动出来的。我应该动手解决数据安全问题吗？我应该建议客户增加一个迭代经理吗？我应该给客户做一个关于中国文化的session吗？答案都在于：你当前“红”的测试是什么？你做这件事将以何种方式使哪个测试变“绿”？

传统的管理者们会说这就叫“结果导向”。

类似的案例还有很多。比如说，如果你要为离岸外包交付这件事写一个测试，你会怎么测它呢？你应该很快发现，像“客户满意”这种虚无缥缈而又变幻莫测的东西，并不适合作为验收测试。一个既简单又明确的验收测试应该是“客户为我们的工作付钱”。那么当你用这样一个测试来驱动自己的工作，你就不那么容易犯下填错timesheet之类的低级错误，因为你会意识到：不管工作有多认真多高质量客户有多happy，如果你的timesheet里没有填那么客户是不会为你的时间付钱的，那么你的验收测试就“红”了。

所以，结论一：就像德鲁克说的，一切绩效都在企业之外。忘记什么角色定义啦工作流程啦职位分工啦绩效考核啦之类的bullshit吧，如果你用“客户买单”这样的外在成就来作为大多数事情的验收测试，你会把工作这件事看得清晰得多。结论二：好的程序员干别的事都比较有希望，因为我们会测试驱动。（潜台词：糟糕的程序员能转成好的项目经理这回事怎么听怎么不靠谱⋯⋯）

原文转自thoughtworks员工gigix：
http://gigix.thoughtworkers.org/2012/5/8/result-oriented-and-test-driven