最近有一个关于 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）能够提供一个简单、粗糙和快速的评估。他们永远不会告诉你这些实践是否带来了什么效果。因此可以说，一份清单无法取代对敏捷理论和实践的理解，以及深入了解它们在某些特定情况下如何有效地运用。所以实际上，加上需要应对的文化所带来的一些适应和调整，这些可能才是实施高效敏捷真正的关键。
查看英文原文： What is the value of the Nokia Test? - - - - - -
译者简介：王速瑜，毕业于华中科技大学，就职于腾讯科技（深圳）有限公司，担任R&D 研发总监，现负责腾讯敏捷产品开发技术的实践和推广及研发基础平台的管理工作。熟悉Java、Microsoft.net、Lamp 等技术。对互联网大规模应用技术、高性能网格技术，SOA 等有非常浓厚的兴趣和深入的实践，喜欢Open Source，关注Ruby、Erlang 的发展并积极实践，愿意为技术而挥洒激情，为让更多人了解精彩技术而付出努力！志愿参与InfoQ 中文站内容建设，请邮件至 editors@cn.infoq.com 。也欢迎大家到 InfoQ 中文站用户讨论组参与我们的线上讨论。
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论