通过高频招募与解职 组建最好的团队
昨晚我出席了在圣地亚哥的一个极限编程的研讨会（实际上这个会议应该叫做敏捷编程研讨会，但我猜测这个会议组织诞生于XP之初，早于极限问世）。 我的一个读者知道我到圣地亚哥去访友，就推荐我参加这个会议。 我本意只是想走马观花，看看编程运动在我上次做了研究之后有没有出现有趣的新情况。 特别是近来，敏捷开发有更多的关注到人的问题上的趋势，在这点上，我一直很迷茫。 阅读这个条目剩下部分 »
企业主与代管人(职业经理人)
Tim Bray 最近的一篇博客文章， Doing it Wrong，在最近几天受到了广泛的关注和议论。 在这篇博客里，Bray 对两种软件开发过程进行了比较，一种是那些面向Web开发的创业公司使用的（大概意义上的）轻量级的敏捷开发方式，一种是受大企业采用的相对正规的、重量级的开发过程，观察到了如下的现象： 阅读这个条目剩下部分 »
Do do XP
agile software development
在文章 Don’t do XP 里, Tobias Mayer 建议人们不要去搞极限编程(XP)。 我和Tobias相知已久，我想他这个问题上错了。 我不知道他在跟谁争论，但他们的有些争论就是“嚼舌根”。我想如果他曾经试过一次XP，那他的言论会更有说服力。 XP并不是一个万能的解决方案，但它确实是一种方案，而且我们知道如何使用它。
作为一个临时的XP支持者，我并不抱怨 “在软件工业中Scrum没有提供很好的开发原则”，我只抱怨这个产业。 如果我们能在这个产业里有效率的工作，那我们也就不会有这场关于方法论的战争了，因为我们的目地就是出产品。 如今当人们把Scrum概念应用到这个产业时，Scrum也不幸被人们使用的混乱不堪。 另一方面，责备XP阻碍了实施方法的进步显然有些牵强。
Don’t do XP
Steve Freeman 写了一篇 blog Do do XP 来反驳我的这篇文章。
我开始厌倦了和那些坚持认为Scrum离开了极限编程就不再有价值的人的无休止的论战。 Scrum 很好用 — 但前提是实施者必须从基础上理解它的价值所在和实施原则。 你应用Scrum所处的环境条件决定了你在实施过程中应该采取哪些措施。 比如，在教堂里实施Scrum和在软件开发中实施Scrum有着不同的一套实施策略。而这两种情况下的实施措施又和传统的Scrum有不同之处。
极限编程的拥护者动不动就抱怨在软件工业中Scrum没有提供很好的开发原则。 但就目前极限编程被业界采纳的缓慢进度来看，真正应该受责备应是XP的缺少实践措施的问题，XP应该为这种状况负责。