【IT168 评论】以前看到过有一个关于Yahoo Scrum开发组验证测试过程列表价值的讨论，例如Nokia测试，Joel测试等。有人将这些视为一个成熟敏捷模式的起点，而另外一些人也担心这将会使得敏捷变得过于教条，从而在整个过程中完全失去自我调整的成分。

　　Bas Vodde由于创建了后来被Jeff Sutherland命名为“Nokia测试”的敏捷评估清单而普遍为人所信服。Bas将这段历程描述为：

　　“你已经逐渐开始不敏捷”的幻灯片4 年前被Nokia Network(现为Nokia Siements Network)所创建，其目的是为了帮助敏捷教练快速评估一个产品开发是否已经严格引入Scrum理论。这仅仅是最基本的门槛，如果你的产品还没有通过这些(例如我们在做敏捷，但是我们的迭代周期持续2个多月)，那也许这个产品的开发就还不值得引入敏捷教练。

　　……

　　当我结束了关于Nokia Networks的一个公开演讲后，我所提到的“简单的清单”，被Jeff认为是一个很有效的清单，并且命名为“Nokia测试”(简单来说就是“当….时，你们并不是在做迭代式开发”)。

　　虽然加班已经“改善”为其他的一些形式，但是实质上没有改变。”

　　Peter Stevens分享了自己在调整Joel 测试中的一些实践经验：

　　“使Joel策划更加现代化的目标是因为在开始指导一个项目团队奋力走向敏捷时，我通常需要一个工具来帮我，但我很快发现这些问题并不是很有帮助。在观察团队做sprint回顾和sprint规划时，我发现问题变得尤为明显，我深刻意识到我所看到的比那些学术上教条式评估更加重要。”

　　Tathagat Varma建议，不要只是问：“我们正在做实践吗?”而是应核查实践的效果，如：员工的积极性、团队的工作效率和客户满意度等。在这一点上Ron Jeffries加入了讨论，并指出研究结果不会告诉你是否有一个特定的方法就是敏捷：

　　“我的意思是并非所有的方法尝试之后，结果都能符合敏捷价值观。敏捷的价值观和原则可以从敏捷宣言中找到。这里面很多差异很大的方法都是好的，只是它们不会被称为敏捷。”

　　大家都很关心的一个问题是，“什么是测试点? ” ，或更具体地说， “你希望从这个过程中得到什么?”，Bas，“Nokia测试”的创始人分享了自己的想法：

　　“想想最初的那些问题，这些测试项有效果吗?这在很大程度上取决于你使用他们干什么，并确保使用它的人实际了理解这是什么(因为它只有5个问题……).总的来说，我并不觉得“敏捷成熟度模型”，“敏捷评估模型”或“敏捷测试”是有益的，因为它们往往趋向于片面看待复杂的问题。”

　　我们可以这么认为，“Nokia测试”的最初目的是帮助敏捷教练确定Nokia的哪些团队可能会受益于这些引导。但还能否达到其他目的?虽然这个答案几乎可以肯定是的，但是许多时候都违背了在采用过程中需要仔细审查的原则，并且它们往往是遵循了适应为先的原则。Jim Brosseau早在2007年12月就有这些认识：

　　“首先，我认为，如果您不是Nokia公司，同时你已决定将这些测试项作为您的绝对标准，您已经失去了敏捷的精髓。绝对没有哪个单一的方法论是理想化的，并适合你们团队的所有项目。”

　　Jim接着解析了Nokia测试，他从一些并不适合于其他场景中的某些特殊案例中，抽取了那些更有价值的通用性理论。

　　最后，我们能从这些讨论里得到什么呢?简单的清单(Checklist)能够提供一个简单、粗糙和快速的评估。他们永远不会告诉你这些实践是否带来了什么效果。因此可以说，一份清单无法取代对敏捷理论和实践的理解，以及深入了解它们在某些特定情况下如何有效地运用。所以实际上，加上需要应对的文化所带来的一些适应和调整，这些可能才是实施高效敏捷真正的关键。