对规则的要求越高 例如敏捷开发经常被人批评为是过于随意的这是不符合事实的沟通交流和规则是敏捷开发的两个基本组成局部。敏捷最大的驱动原则是定期提交可工作的软件。提交周期越短。每次迭代都必需以可工作软件形式提供具体的可以度量的商业价值。但真正在项目中采用敏捷开发的却很少。这里分析敏捷开发的优点，敏捷开发的种种优点时常被项目经理提及。将告诉您采用敏捷的项目如何从成本到收益得到好处。

正在寻求各种方式变得更加灵活和多变以适应不时变化的市场需求。高效地开发出有品质的软件对各个行业的企业都是至关重要的对最终用户尤为重要。软件企业不再能忍受18个月的产品周期。

但目前多数的开发项目仍然在进行中并且按传统的模式要求事先定义下所有的需求，尽管我需要一个高效的软件开发计划。同时这些需求在日后几乎不允许改变。问题是按这种方式多数客户都不能准确定义出它需求。夹杂着技术进步带来的变化，结果是令人气馁的美国的一家研究公司StandishGroup发现百分之九十的软件项目延期，百分之六十六的可以认为失败，以及百分之三十的完全报废。

其目标是有效及时地生产出高质量的软件。敏捷开发是一个使公司能够更快速地提交软件产品的开发过程方法。一个渐进的协作的方法。适用于较小的范围和相对简单的商业应用项目。如今，敏捷开发的初期。局面已发生了显著变化。当公司想要把敏捷开发应用在更广泛的项目上，那么敏捷开发就需要处置当前软件开发组织所面临的大量业务、结构、和技术的复杂问题。必需权衡利弊，正确的分析出转向敏捷的代价。同时开了开发风险的减少。例如，实施敏捷方法需要改变工程师花费时间的方式和他如何完成所有的软件开发活动。这里强调一些进行转换应该关注的要点。

个人和交互（针对流程和工具）；工作软件（针对全面文档）；客户的合作（针对合同谈判）；响应变化（针对遵循计划），经理们必需考虑他扮演的角色。多数敏捷精益开发经理使用更加放手的方式。让队员在特定的方向作先锋从而培育出胜利转向敏捷精益开发的环境所需要的

从而转化为客户满意度和收益。效率可以消除在特定活动上的浪费，敏捷增加了团结的软件交付效率。可能也许不能对大的目标发生影响。但是效率不会告诉你正在做的事情是否正确，或者告诉你正确的做事顺序。效率更重要的协助你实现目标。

如同前面提到过的继续的团队协作。相关人员关于可工作代码的反馈和测试驱动开发对胜利推出一个项目至关重要。相关人员包括业务相关者、软件使用人、客户支持、和其它企业IT部门人员，和其它重要的敏捷开发原则一样的一条是开发阶段的客户介入。需要他尽早的多多介入到敏捷项目整个开发周期中，积极参与建模和测试，有时甚至是参与开发。这一层次的介入使得他能够看到软件开发的内部工作。这样促使开发人员关注于客户的优先级上而不是个人的优先级，这样可以提高产品的可用性。一个使企业知道如何快速响应并准备好应对需求变化的基础。例如使用Scrum混战：一个敏捷开发借用橄榄球运动中的术语）一个每天举行的混战”也就是会议）邀请所有项目相关人员。每天开发人员回答三个问题：这些敏捷开发指导方针为企业提供了一个基础。

◆从昨天到今天你完成了什么？

◆从今天到明天你打算做什么？

◆你遇到什么问题使你无法完成计划的目标？

这样其它队员可以在转为灾难之前指出错误和不兼容。也可以确保在紧急情况出现时有人可以作出及时弥补。这个每日例会要求每个人清楚说明他所做的事情。