敏捷

先讲一个很tricky的故事。在印度上课的时候，陶文有次问KP：能不能给我们讲个 ThoughtWorks的失败项目案例？KP沉吟一下说，这个取决于你怎么定义“失败项目”。这个 诡辩手法我很熟悉，再结合 非线性历史观，所谓“失败项目”可能从来就没有存在过。

不过实际上，对于项目的“成功”，确实有着不同的定义。大多数软件公司的定义是，按时、按预算完成项目合同所规定的工作，这就是一个成功项目。这是一种合同导向、交付导向的定义。使用这个定义，软件开发者真正重视的是项目本身：如何在规定时间内完成任务、如何控制成本。因此他们也倾向于减少变化、固定客户的需求，因为变化会增加成本和时间。虽然嘴上都说“为客户实现价值”，但这种定义让客户价值与软件公司的价值偏离，软件公司真正关心的是项目“成功”，而不是软件为客户带来多大价值。

另一种定义，即 ThoughtWorks对“成功”的定义是：为客户创造最大化的价值。项目可以超出预期时间，可以超出预算，可以变化甚至变得面目全非，唯一坚守的原则是每天都给客户带来最有价值的东西。所以，不要错误地理解“敏捷”就等于“速度快”，敏捷可能并不是最快的开发方式，它所坚持的实践例如持续集成、测试驱动、重构、结对等确实有可能让开发速度比“最快”略低；敏捷的目标是随时为客户提供最大的业务价值。如果最终的软件不能为客户创造价值，即便开发得再快、成本再低，我们仍然不认为那是一个成功的项目。

与之相关的另一个重要话题是“按时间收费”。留待以后再表。