James Shore 谈保持真正的敏捷

InfoQ 首先向 Jim 询问关于由他和 Shane Warden 一起写的《

敏捷开发艺术》一书，特别是为什么该书不错，读者能从中获得些什么。Jim 解释说很多早期的综合性著作，比如

极限编程系列里面的书，主要的目标读者是那些“创新者和早期接受者”（Jeffrey Moore 在《跨越鸿沟》一文中的术语），而他的书能给那批现在想尝试敏捷的“早期从众”更多有实效的内容。Jim 还继续描述了这些内容的出处：

这本书是我和团队一起工作所获得经验的结晶：一开始采用 XP，随后又因为很多跟我一起工作的团队都以 Scrum 作为起步，也就结合了部分 Scrum，最后是把精益的概念也融入了进来。所有这一切都采用了类似精益的 Eli Goldratt 的约束理论模型。书中的最后一部分内容是 Brian Marick 的敏捷测试指南。

更多关于 Jim 这本书的信息可以参阅在敏捷 2007 大会上的

这个访谈。

InfoQ 接着和 Jim 谈了他关于敏捷应用正在越来越水的观点，因为他写了 2 篇著名的文章 Stumbling Through Mediocrity和敏捷的衰落。综合了他所观察到的，他说道：

人们在说：“我们想要变得敏捷。”于是他们找了最简单的、最便宜的方式“变得敏捷”了，但结果呢，他们的生活并没有变得更好。很多情况下，实际上，他们的生活越来越糟。
…
我 所看到的是敏捷已经变成了一个流行词语，敏捷变成了一个目标。但是如果敏捷是目标，你大可以做各种“无厘头”的事情，随后贴上“敏捷”的标签并宣称你成功 了，但实际上你没有让任何人过得更好。敏捷的目标不是“变得敏捷”，而是要做出一个有价值的，满足能高效工作、扩展性好、人性化这些目标的伟大的软件。

当被问到敏捷社区又能做些什么来改善现在这种情况时，Jim 给出了如下的意见：

我们需要不再宣称敏捷很简单。我们需要宣称敏捷是有效的、强大的，敏捷可以带来价值，但并不简单。事实上，要想敏捷很难。【敏捷是一种组织级别的改变，任何】组织级别的改变都是很难的。

当谈到现在日益增长的一种趋势：用敏捷但不真正地用完整的方法学的时候，关于看板的话题就被提了出来。Jim 解释说，他认为看板是很好的工具，但也很担心大家太过关注看板本身而忽略了精益所包含的更多的内容：

我认为看板真的是一个有意思的想法，一个非常棒的工具…但是，源自于丰田生产方式的精益软件开发的想法【由 Mary 和 Tom Poppendieck 提出】相比看板有着更多的内容，而不是像看板那样主要讨论怎么计划工作。别的还包括连续流，改进方式【一种“学习文化”】以及消除 浪费等等。看板虽然是唯一用来创造连续流环境的工具，但它不是所有。就像采用 XP 和 Scrum，但仅仅在白板前讨论下一步做什么。 很多看板的支持者们会说：“不，看板是一套完整的体系。”而我会回复说：“为什么不说精益是完整的体系呢？”因为我们已经有了一个精益的体系，它很好地和敏捷融为一体了。

如果我们准备用看板，让我们不要仅仅只使用它。让我们拥抱、运用整个精益体系，因为它能完美地和敏捷结合一起。

当被进一步问到关于精益他有什么不同寻常的发现的时候，Jim 用了下面这段话来结束了我们的访谈:

当我第一次读 Poppendieck 的书的时候，我想“终于，这里解释了为什么我们做了敏捷中的一切”。敏捷宣言中有些原则是跟它有关的，但在我看来精益原则更好。比如为什么我们要考虑各种可能的选择，我们为什么要频繁交付。精益对这些给出了很多很好的解释。

如果你对 Jim 对敏捷的理解和看法感兴趣，你可以考虑去听听他和 Diana Larsen 将在 6 月 8 日到 6 月 12 日举行的敏捷计划和交付的艺术这一公开课。