当我们研究一个新的领域时，阅读相关的书籍往往是把握整体内容的最佳途径。因此，我在Amazon上搜索了和上面那些作者有关的书，得到的结果让我很吃惊。为了让你体会到我的感受，我把和那些作者所著的关于敏捷方法的书籍都列在下面，这些书主要是：
- 标题里包含“Agile”或者“Agility”的书
- 介绍了敏捷方法（Scrum，Extreme Programming,等等）的书
- 讲解了重构，测试，代码质量或者其他用来响应变化的技术手段的书
- 体现了实用主义思维并且不局限于某个特定语言(Java, Ruby等)的书
这些作者的书籍数量之庞大，让你感到吃惊吗？真的吗？为了能够广泛传播自己的观点，他们经常需要进行布道，而写书恰好是布道工作的一部分。还有一点让人很吃惊：这些书在Amazon上的评价都很高（至少是4星，5星满分）。这些书都是关于敏捷方法的很好的参考资料，并且这些家伙们在软件工程这个领域里做了大量的工作：我强烈建议每个开发者都去订阅他们的博客（他们大部分人都有写博客，你可以通过搜索引擎去查找）。
不过，看看相反的观点也是很有意思的。Steve Yegge(一个Google员工）在他的文章《Good Agile,bad agile》里这样批评方法论：
- 一般来说，任何自称为“方法论”的东西都是愚蠢的
- 任何东西，如果它需要布道者并且提供研讨班的话，那么它的存在只是为了赚钱
- 任何不提及竞争者和替代者的事物毫无疑问都是自私的
- 一般来说，任何没有重要细节的图表都是愚蠢的
我这里的“愚蠢”这个词语，是来形容用类似于杀鸡用牛刀的行为。
或许，这些观点并不是很客观，并且 Steve 文章的最主要观点是任何公司皆可复制 Google 的模型，但因不同的公司文化，使其观点一直不被认可。我也不同意他的这个观点，当你一味听从他人的意见时，你也是愚蠢的。不过我同意Steve的另一个观点，我们都注意到，当布道工作做的过火时，布道这事已被我们看到无可替代了。
敏捷方法并不适合于所有的项目
最近，我开始担心起“敏捷”这个词了，因为它似乎变成了一个流行词，并且我们大部分人都忘了其实有时候敏捷并不是最好的方法：
- 很难真正做到敏捷
- 敏捷并不一定是最合适的方式
当说到敏捷并非万能之时，我们通常会想到第一条，但也经常忘记第二条。Steve McConnell在畅销书《代码大全》里写道：
在软件行业，顾问经常让你只采取一种软件开发方法，而把其他的方法都排除在外。那样会让你的项目很不幸，因为如果你100%地只采用一种方法，那么你会用这种方法来看待所有的事物。在有些情况下，这会使得你错过一些更加适用于你当前项目的方案。
大部分（所有的？）敏捷宣言的作者都同意Steve关于软件方法的观点。所以，记住这一点就够了。
什么时候敏捷会比较合适呢？
Danc在他的文章《Managing game design risk: Part I》里给出了过程复杂度的分类：
- 简单过程：当需求和实施方案都比较清晰的时候，那么这个项目就可以通过比较简单的过程来控制。一般来说一个简单的checklist就能胜任。单独的一个工人在流水线上重复工作的过程就是简单过程的一个很好的例子。
- 复杂的：当需求和实施方案有时候会有变动的时候，你还是可以通过一个独特的checklist来完成项目。不过，为了完成项目，你需要添加很多规则和一些额外的步骤。桥梁建设是复杂任务的很好的例子。
- 更加复杂的：很多项目都处在一种需求和实施方案都大致确定，但是在很多程度上都存在着变动的危险境地。在这种情况下,敏捷方法能够帮助团队高效进行反馈，领导项目走向成功，并且避免高风险和不确定性。软件开发是更加复杂任务的一个最佳示例。
- 混乱的过程：当需求和实施方案的变数都非常高的时候，项目会陷入无法控制的混乱状态。从实际的过程来看，这种项目的成功与否取决于运气。
结论
首先，你自己不要成为一个布道者，多关注自己的项目，根据项目的实际情况决定哪个方法是最合适的。有时候，敏捷不一定是最好的方法，但是如果你发现项目的需求不是很稳定的时候，敏捷将会是一个很好的选择。
你是否会认为你自己有时候会成为一个布道者呢？
