增量迭代开发(敏捷实践之一，它意味着每次迭代的产出只是本次迭代范围内的需求)真的不利于产生好的设计吗?Scrum真的提倡“忽视架构问题”吗?如果没有敏捷技术实践的话，架构设计能有效的演化吗?测试先行式的开发真会产生优雅的设计吗?在红绿条提示下的重构循环只在局部小范围内有效吗?

　　来自Net Objectives的Alan Shalloway就利用Scrum构建应用的经验向ScrumDevelopment yahoo group的成员提出一些问题，问题之一就是“他们是否找到代码质量是依靠什么来保证的?”

　　当我在课程中或在那些讨论“向已建系统中追加新特性”的会议中提出这个问题时，每个人都认为这属于集成成本。我想，这是因为大多数人不会编写那些融入了很多设计模式的具有良好的扩展性、足够灵活并且易维护的代码。这些人中，大部分也没有使用过Scrum。

　　Shalloway随后详细解释了他的观点：

　　……正如Scrum所告诉我们的，他们(指在Scrum团队中的开发者)根据客户价值一次只开发系统的一小部分，如果团队中有高级架构师的话，就会组织得更好。很多开发者有一种很好的意识，即他们会回头看一下是否应该做一些改动，使架构更合理。但更多的人并不知道，假如代码是通过拷贝、粘贴并修改(甚至改得面目全非)得来的，那么这会带来很多冗余。此时，Template Method可能是一个比较好的解决方案。

　　也许我悲观了一些，但我的感觉是，假如你没有注意熵的话，就意味着它们会达到你不期望的地步。在你的案例中，你正在使用Scrum来改善很多团队忽视的东西。所以，我的问题是：

　　大家忽视它了吗?

　　如果真是这样，它会引来问题吗?

　　到目前为止，这些反应都表明很多使用Scrum的团队有这个问题，甚至那些坚持写测试和进行重构的团队也有同样的问题。那些没有使用多少有些变化的敏捷技术实践的团队，可能会有更大的麻烦。(请记住：Scrum 与开发技术没有必然的联系，你可以使用传统方法开发软件，也可以用XP，或者其它技术实践，只要你在Scrum的框架之内使用就可以了)

　　接下来，让我们讨论一下现实中，Red-Green-Refactor loop是如何发挥作用的?一个团队在写测试和重构方面深有心得，就会有一个好的设计吗?Paul Jones 的blog中有一篇关于TDD如何创建了混沌代码(Ravioli Code)，宣称用TDD开发出来的代码是低耦合的代码：

　　我想，很多TDD和测试先行的理想主义者和宣传者写出了的确经过充分测试的代码，但还是很难理解。

　　Jones并不想撼动TDD，因为与其测试目的相比，TDD实际上更关注于设计。但这还是会带来一个有趣的事情。在使用这些实践的敏捷社区中，好在哪里呢?随着社区的成长，这些实践带来的麻烦比其带来的好处还多吗?与传统开发技术相比，这些工具被不正确的使用是否更危险?

　　最后，让我们假设：我们正在恰当地使用Scrum和TDD。毕竟，象Ron Jeffries 在《We Tried Baseball and It Didn’t Work》一文中所呈现的，我们不能因为自己没有正确地使用它而将不好的结果强加给它。TDD会产生好的设计吗?对于使用Red-Green-Refactor loop的做法，重构可以说是一种局部优化技术。我们优化局部的设计。本质上，这等同于steepest descent algorithm，也就意味着重构几乎总是会带来次优设计，就象使用TDD来做“数独游戏”一样。

　　现在是我们用批判的眼光来重新审视我们的这些实践的时候了吗?