敏捷开发对于中小型项目还是非常适用的，不过我在实践过程中遇到两个问题：

　　1、重构 = 返工？

　　（1）需求和设计角度。

　　我对敏捷的理解，是允许需求人员在开发过程中不断地更新需求，而开发人员靠版本迭代来实现。迭代过程中，对于无法满足新需求的模块、以及前面迭代周期里性能不良的模块进行重构。从另个角度来讲，重构 = 返工，浪费了时间和人力。

　　如果有可能的话：

　　a、还是要尽量让需求人员在项目初期把需求定清楚，尽量减少在开发进行中进行重大调整的次数。不能因为敏捷了放弃对需求制定的严格把关，想着反正迭代周期可以解决一切。

　　b、设计中留下一定的可扩展性。这是个度，不同产品团队得自己把握。完全不留扩展性，在需求变更的时候往往不得不重构；而留下过度的扩展性，可能在前期浪费了大量时间而后面不一定用得着。

　　（2）项目后期、维护阶段的重构

　　我发现一个很有趣的事情，程序员一般不喜欢给维护别人的代码，给别人“擦屁股”。因此项目后期加入团队的程序员、和维护代码的程序员一般都会骂前任留下的代码如何垃圾，“需要重构”。实际上这是一个冠冕堂皇的陷阱。

　　一方面，重构后会出多少BUG还是未知数， 而且重新开发和测试并不能使客户掏出更多的钱为这些工作买单；

　　另一方面，重构后只是重构者自己后期做维护和开发轻松了，因为他在自己的代码基础上修改。对团队其他人来说，效率提升并不明显，因为他们需要重新熟悉新的接口甚至框架。

　　而严重的问题是，敢提出重构的程序员会认为自己的设计是好的，前人留下的那是垃圾。因此即使他对代码重构过自己很满意了，一旦代码转手，这岗位上的下一任仍然会大骂垃圾并试图把这些代码再重构一遍， 然后只维护自己写的代码. 这会是项目进度控制和风险控制的无间地狱。

　　2、测试驱动开发

　　这里面有个很危险的陷阱。因为多数团队不可能把需求定得很细，需要在开发中让程序员和需求工程师边做边讨论细节，后定下来，这种模式用图来表示是

　　需求 -> 测试

　　　　 -> 开发

　　传统的V字型结构，但这里的箭号方向表示了产品需求理解的传递路线和方向。而如果测试驱动开发的话，结果是这样的：

　　需求 -> 测试 -> 开发

　　也是说，开发者并不直接去和需求打交道，其工作目的不是实现需求，而是让测试能跑通。这样要求测试团队，尤其是测试经理要对需求有很强的理解力，并且在需求制定者和开发团队之间承担沟通的责任。而国内的普遍情况是，重开发轻测试。体现在测试人员的学历要求和薪水普遍比开发人员低，有些草班子甚至在项目计划中不给集成测试和DEBUG留时间。所以在这种现状下，试图用测试驱动开发的方法，隔离开了开发团队对需求细节的直接把握，让能力较弱的测试团队来做这事，基本上是——找死。