4、敏捷的适用范围

　　敏捷的是在充分了解项目的基础上进行的一种类似于手工作坊的开发模式。因此在所有的项目中都可以使用敏捷的思想，但是如果完全使用敏捷的开发模式，个人觉得以下类型的项目比较适用：

　　对实践型需求变更较频繁的项目比较适用：对于那些需要严格按照PRD进行开发的项目不合适，比如微软需要开发一个win9的系统是不可能采用这种敏捷模式的。

　　对逻辑简单的项目比较适用：对项目逻辑复杂，关键性高，可靠性安全性等方面有较高的要求的项目需要在开发的每个过程中，都需要多方认证，适用敏捷模式不合适。比如需要淘宝的登陆系统，不可能使用敏捷的模式。

　　对团队成员少而精的项目比较适用：如果一个项目中，人数越多，面对面的沟通的代价呈几何级往上增加。

　　对模块独立的项目比较适用：如果项目中，模块和模块之间的耦合度较高，相互之间依赖严重，整个项目只有很少的UserStory，使用敏捷模式会造成项目敏而不捷。

　　5、敏捷实践的经验和教训

　　避免无计划性：在以往的开发模式中，测试计划是时间，而敏捷模式中，测试计划是相对时间。以往的开发模式在某段时间中，任务比较明确，而在敏捷模式中，容易造成无计划没目标。对于这种情况，除了有任务计划之外，能够自己指定一份计划，给任务计划确定具体的完成时间点。

　　避免无纪律性：敏捷的模式是支持需求变更的，但是我们不能够无谓的变更。所有的开发和测试同学都不希望自己的项目中存在不确定因素，但是使用敏捷模式，我们需要接受这种变更；

　　任务划分思考不足：从下面的图中（开始并行上升段）我们可以看到，预计的总的开发时间（蓝色的线）是上升的，表示项目的考虑不够充分！在实际开发的过程中发现了不足之处，然后进行改进，导致整个工作量的增加，例如我们项目使用的是WEBX3，结果hecla不支持webx3，目前仅支持从webx2升级到webx3的兼容模式。