果园春色

没人会喜欢这样的会议，把时间花在无休止的争论中。更不会有人喜欢这样的会议，别人征询了他们的意见，但很快将它置之不理。 回顾会议组织者（以及任何带领小组讨论的人）需要一些办法帮助让团队成员思考、讨论、并有效地作出决定。下面是5个小贴士，可以帮助你把绝大多数时间花在回顾会议上（以及任何其它的会议）。1. 把工作交给组员做一些组织者认为他们的工作就是站在房间的最前面，并做这些事儿就行了──写...

[注]：这是2008年底写的一篇关于即时验收（即常说的BA sign off）的文章，原文发表于《程序员》杂志。从去年刚开始加入ThoughtWorks，对敏捷懵懂了解，到现在随着经历的增多，对敏捷的了解也有了越来越多的体会。即时验收是敏捷中很小、很容易被人忽视的实践，甚至很多人都不知道。但我参加了几个项目之后，越来越体会到了即时验收的重要性：每当项目中的bug数量明显增多，我都会提醒自己以及团队...

敏捷中国大会已经结束，我9月12日参加了会议，下午与一些嘉宾在TDD workshop进行了结对编程活动，有一点感想。 我本来没打算参加TDD workshop，是临时被拉过去的。一坐下来就感觉非常尴尬──没提前熟悉题目就要跟别人pair，而且得以我为主，给别人讲解，而题目是个Mars Rover，足足有半页纸。我强迫自己冷静了一些，跟pair一块粗略看了题目，然后就从最简单的测试开始做了...

你能用一句话解释什么是敏捷吗？米高的一篇文章里，谈到了他去客户现场第一天，客户就问这个问题：他们觉得了解敏捷了，可是很难说清楚。尤其是向别人解释的时候，需要费很多口舌。于是请教能不能一句话就能解释什么是敏捷。读到这里，我下意识地想到，如果是自己，会怎样回答呢？之前向不少人介绍过敏捷，自己也感觉到颇为费劲：敏捷是软件开发的一种方法论...有很多相关的实践，比如...采用迭代式的开发方式，把最...

帮助客户实施敏捷，已经有一些开发人员在尝试使用TDD的方式进行开发。一再向他们强调：“写任何代码之前，先写一个会失败的测试”。这里说的写代码，不仅仅是指开发sotry或者修改bug，很多时候，当你有了一个新的想法，不妨先写一个测试：某位开发人员告诉我，他想在项目中Spring事务，但是不熟，所以想花时间预研一下。讨论完Spring事务相关的问题，我接下来问他，有没有写测试？有了一个失败的测试，...

相信每个团队对敏捷实践的应用都不尽相同，都会根据项目的具体情况进行调整。这是因为敏捷是一种“适应性”而非“预见性”的方法，这意味着，你很难预测哪些敏捷实践在你的项目中一定是好的，从而使用它们并且保持一成不变。那么如何做出合理的调整呢？通常情况下我们可以结合以前项目的成功经验、以及其他人改进的最佳实践，从而决定采用何种实践，或者对实践做出哪些改动。与此同时，敏捷自身也提供了一个很好的方法：回顾...

近日，国外的敏捷社区热闹非常，关于Scrum与Scrum+XP之争的讨论更是甚嚣尘上。大家不但在Yahoo敏捷讨论小组进行了激烈的辩论，战火也燃烧到了多位专家的博客上。对此专题，InfoQ曾进行了连续报道：《[url=http://www.infoq.com/cn/news/2008/11/decline-of-agile]James Shore：敏捷的衰落[/url]》、《[url=http:/...

刚在InfoQ上翻译了一篇文章，作者是Mark Levison，介绍了TDD初学者容易遇到哪些困难，为什么许多人浅尝之后就放弃了，最后他还介绍了一些方法，能够帮助开发者形成TDD的习惯。通过对采用TDD的开发人员调查，Mark发现主要有以下问题： * 由于经验不足，大家发现自己直接TDD比较困难。 * TDD培训的例子比实际应用简单得多。 ...

测试人员和开发人员的比例问题，是一个老生常谈的问题。不少人对这个问题都有研究，当然很多人都有自己的看法。1.测试与开发人员的比例多少才合适呢？《微软秘笈》中指出微软这一比例是1比1。而根据一些非正式的调查，这个比例通常是1：3，即一个测试人员对3个开发人员。不同的公司、不同的团队这个比例相差还是很多的。当然，有不少人提出，这个比例没什么意义。比如说，有的团队有自动构建负责人，这个负责人...

单元测试中，每个测试类，甚至测试方法最好没有依赖，这样有很多好处：1.每个测试类都可以单独运行并能成功；2.修改一个测试类不会对其它类造成影响。这也是为什么JUnit中提供setUp()和tearDown()的原因之一。一般情况下，大家喜欢在setUp()中创建环境，运行完测试，在tearDown()中清除环境，这样互相不依赖。我把这种情况叫做“利他”，即你相信别人，别人也相信你。这对很多单元...

团队实施敏捷，经常会遇到的一个问题是：“实施敏捷对个人能力要求高吗？”其实不止是正在实施的团队，国内各个敏捷社区、论坛上也充斥着这样的论调：“实施敏捷对能力要求太高了，如果团队成员的能力达不到一定的程度，还是不要实施敏捷的好”。为什么大家会有这样的问题？有些是实施中确实遇到的，更多的则是臆测推断出来的；在大家把问题统统归结为“个人能力”之前，我们还是先澄清一下能力的范围，是指在开发过程...