严格的敏捷

我经常遇到一种抱怨，即敏捷方法没有严格的定义。抱怨者可能会谈论这如何意味着你无法判断一个特定的团队是否在使用敏捷方法。他们也可能会说这使得教人们如何使用敏捷方法变得困难——课程是什么？

在某种程度上，我确实感受到了这种抱怨的痛苦——但我接受没有治愈方法。这种缺乏严谨性是敏捷方法定义性质的一部分，是其核心哲学的一部分。

一般思维过程——特别是软件开发——的一个基本问题是环境的差异性。不同类型的系统有不同类型的压力和力量，这使得很难提出一个足够涵盖所有情况的关于该做什么的严格陈述。由于软件开发是如此以人为本的活动，而人们天生不一致且变化很大，这种影响被加剧了。敏捷主义者从中学到的结论是，试图将软件开发绑定到一个严格的流程中是无效的，因为这忽略了将执行该流程的主要（人类）组件的本质。

（这可能是因为我们的职业是与计算机打交道，这导致我们想要以与我们编程计算机相同的方式来编程人类系统——尽管它们如此不同。）

所有这一切的结果是，敏捷方法从根本上期望团队决定遵循什么流程，而且还期望团队积极主动地定期更改其流程。任何试图定义一个可以测试一致性的严格流程都与这种哲学背道而驰。

我不能否认这令人沮丧。当您无法首先获得Scrum的明确定义时，您如何进行调查以确定敏捷方法是否比其他方法更有效，或者极限编程是否比Scrum更有效？如果客户想要使用极限编程构建系统，他们如何判断它是否真的在执行？有一种“我看到它时就知道了”的感觉，但这需要经验丰富的从业者才能有这种感觉，即使这样，这些从业者之间也存在很多分歧的空间。

我对这个难题没有答案。事实上，我认为没有答案。这只是活动本身的必然结果，就像游泳的必然结果是弄湿一样。

2012年7月26日重新发布