本文转自敏捷开发。

雪鸟会议

雪鸟会议前夕，James Grenning 在 Object Mentor 与 Robert C. Martin 一同工作，彼时组织雪鸟会议的 Bob 大叔盛情邀请 James，告知他会议的地点。James 听到地点后毫不犹豫地答应，并在脑海中踊跃欢呼“我要去滑雪！”毕竟，“雪鸟是世界上最好的滑雪场之一”，没有人会拒绝雪鸟的诱惑。当然，除了滑雪这个最直观的念头，James 也曾与 Kent Beck、Ron Jeffries、Martin Fowler、Ward Cunningham 共事、合作，有这样的机会同这些人一起聊聊关于软件开发的事，这也是另一个非常吸引他的原因。

不过他对参加雪鸟会议是否会对自己的工作产生有利影响没有丝毫期待，在会议现场也只是进行些小组交流，他从未预料到这会对软件开发行业产生如此巨大而深远的影响。“我们很确定没有人会在乎，但至少我们做了一些事情： 找出我们有什么共同点，以及共同点在哪里。”

估算扑克

在一定程度上，《敏捷宣言》是在大家聚在一起找出分歧，再找到共同点的过程中产生的。James 认为，这与估算扑克相似，二者的共同点是： 一个团队需要在哪一部分达成共识。

估算扑克的灵感来源于 James 作为敏捷教练参加的一次失败的计划会议。那一次，团队八个人围坐在桌子旁，两位高级工程师主持此次会议，在会议中，二人不断反复讨论如何构建用户故事。当时在场的 James 极为混乱，他用了半小时甚至一小时的时间才意识到，他们在会议开始时谈论的工时数与在会议结束时谈论的工时数完全一致，整个会议所做的事情只是在争论用什么方法去做。而此时其他参会的六个人都已经昏昏欲睡，这是因为争论的这二人“垄断”了整场会议谈话，而没有参与讨论、估算的人已经近乎脱离会议了。当时的 James 手上正好有索引卡片，于是在这场会议中场休息结束后，他给每个人都发了卡片，并要求提出某项工作后，所有人只能出牌，不能讲话，来达成一致同意。

James 在 Object Mentor 网站上写下了这个故事，提出估算扑克。随后，Mike Cohn 发现了这一方法，并根据自己的经验对估算扑克的设计 进行了完善和增强，同时决定将估算扑克在大范围内推广使用。发布后，这副特殊的扑克在程序员中广受欢迎。

当然，估算并不只依赖于这一副扑克牌，James 自己在被 Lowell Lindstrom 展示过亲和图优先级估算的想法后，已经多年未使用估算扑克。但估算扑克确实能通过以牌面朝下的方式隐藏数字，让团队避免“锚定”的认知偏差，提高估算效率。这是一种既能起到群策群力效果又有效避免众口难调造成混乱的好方法，所以 James 的客户们应用推广，由此产生了 风险扑克、 价值扑克等类型。虽然这两种扑克并未推向市场，但团队想要借鉴的话，实现起来并不困难。

测试驱动开发

1999年，James 开始学习极限编程，从事嵌入式咨询工作。当时一直在为客户编写用例并搭建体系架构的 James 在 Object Mentor 进行了第一次极限编程沉浸式学习，也开始接触一些此前未了解过的事。当他看到当时名为“测试优先于开发”（现在的测试驱动开发）的演示时，他发出惊叹：“哇！我们可以打破对我们没有的东西的依赖。”因此，如果需要构建某个系统，并且处于无法与硬件交互的情况下，仍然可以创建软件，并 通过存根和模拟对象等来开发尚不存在的事物。

激动兴奋之余，受到启发的他产生了为做嵌入式开发的程序员介绍测试驱动开发的念头，也将敏捷介绍给嵌入式开发的群体。他开始在嵌入式系统会议上做关于将敏捷应用于嵌入式软件的演讲。也有了专门写作测试驱动开发的主题的书的念头，这个念头后来成型，就是《测试驱动的嵌入式 C 语言开发》。

从这颗被点燃的火花开始，再到他把敏捷、测试驱动开发的火花带给更多的嵌入式开发工程师，他意识到语言通常是不同的，不仅仅是编程语言，人们相互交流的方式本质上是不同的，因为他们谈论的是不同的东西。不同的整体拥有不同的世界，所以游走于不同的群体间就可以学到不同群体的知识，比如他通过与 Bob 的合作了解到了许多非嵌入式的知识。从面向对象、极限编程到测试驱动开发，他愿意把这些不同世界的知识带给其他世界的程序员。

敏捷本身不是目标，而是寻找诚实而高效的方法来交付有价值的产品，这是 James 一直强调的观点。在2011年敏捷宣言十周年的访谈中，他认为自己与十年前在雪鸟会议的自己相比并没有变化，但他一直拥有自我学习和进步的主人翁意识，在尝试不同的想法并不断完善。所以，敏捷更多是一种前进的方式，而不是可以在此停滞的目的地。回首往事，他不会从《敏捷宣言》中删除任何东西，但会补充一些关于持续改进、适应和学习的内容。如今又是新的十年走过，通过他不断更新的网站和活跃的动态，我们相信他一直在前进，从未停滞。