据Gartner的资料表明，一众CIO现在有压力，需要支持快速发展的数字业务发展，而同时又遇上传统项目和开发方法不能与时俱进的难题。企业现在大量采用敏捷开发，以加快项目进度及更好地显示其价值。
Gartner应用架构、开发和整合峰会下个月在悉尼召开。Gartner公司研究总监NathanWilson在会议前夕表示，敏捷方法如果使用得当，是有能力改变IT业务关系以及对IT价值交付产生重大的正面影响。而CIO和整个IT管理团队必须悉心培养获得成功所需的变革文化，只有这样才能交付相应的价值。
Wilson表示，“敏捷开发做得好的话，是可以成为开发产品组合方法的有机组成部分，CIO可以利用此类方法来应付日益高涨的创新业务需求。但用得不得当的话，敏捷开发导致的问题会比其解决的问题更多。”
Gartner列出敏捷开发的10大指导原则如下：
1：敏捷开发不是单一的一件事
敏捷开发方法是一组软件开发方法，这些方法具有共同的理念，但在具体细节上又截然不同。因此，敏捷开发方法往往能适应不同类型的问题。那些老牌、成熟的组织大可以使用几个方法，但刚处起步阶段的组织则应该选择一个方法，掌握了一个方法后再尝试其他方法。
2：敏捷开发并非“拿来主义+混合”的方法
敏捷方法是个高度系统化的方法。其中的每一个构成元素对于最后的成功都是至关重要的。有些组织可能只采用敏捷方法的一些元素（如冲刺『Sprint』）却忽略或淡化其他元素（如“技术债务”（Technicaldebt）的管理。此为常见的错误。这些组织或许会享受来自快速发展和发布新代码的荣誉，但由于未能很好解决技术债务，他们收藏起来的问题终会带来麻烦。
3：拥抱敏捷开发是一项业务与IT之间的联合活动
要充分实现敏捷开发的益处就离不开商界领袖、管理层和用户社区的参与。如果一个企业里有些部门不喜欢新的工作方式，那就有必要精心地计划、将不同的管理者社区和用户社区组织到一起进行沟通。
4：敏捷开发需稳打稳扎，不能急于求成
有经验的敏捷开发实践者可以应付大规模的开发——颇像攀登珠珠穆朗玛峰。但承担大型软件项目所需要的必要技能来自许多年的积累。在踏上敏捷开发征途的初始阶段，任何组织都需要在山脚下起步，在发展中建立信心、提高承担更大的任务的能力。
5：采用敏捷开发需要不断地学习
敏捷开发实践者必须不断努力提高质量和成本效益，即是说，要对每一个开发项目进行分析，吸取经验教训，以期改善以后的决策和工作方法。此类分析和学习不仅仅是少数资深实践者的责任，所有敏捷开发实践者的工作负载基本组成部分里涵括了分析和学习。此外，学习对于直接参与软件开发的程序员无疑是适宜的；学习所有的相关技能也至关重要，如项目管理、架构、质量保证和IT预算管理等。
6：敏捷开发事关团队及由团队组成的团队的事
在敏捷开发中，交付的的基本组织单位是一个小团队，典型的人数常为“七加或减二”——含开发人员和质量保证。从人力资源的角度来看，管理敏捷开发团队是一件有些飘忽的事，一方面要保持团队的相对稳定以保持工作效率，另一方面又需要将各个团队的人员进行交换和糅合以鼓励相互之间的思想交流。如果人员交换过于频繁，团队则不能成为高效的小组；而如果团队之间的人员交换不够的话，每个团队会变成孤立的小组，会背离其他团队。要注意的是，采用敏捷开发方法时，团队彼此之间的相对物理位置比传统开发方法中的物理位置要重要得多。
7：归档、管理和消除技术债务是所有敏捷开发方法的一个核心概念
技术债务是一个软件两个状态之间的差异，一方为今天的状态，另一方是为满足诸如可靠性、性能效率、便携性、易用性、可维护性和安全性等必要的质量属性要求所处的状态。所有的开发都有技术债务。敏捷开发方法与其他方法的区别在于，敏捷开发会认明技术债务并将其列入需要处理的事务之列，而不是藏起来不理不睬。希望采用敏捷开发方法的组织必须选择所用方法的元素，大刀阔斧地处理重构和消除技术债务。
8：采用敏捷开发要慎重处理和对待第三方开发服务提供商
很多IT组织很长时间以来都是将应用程序的开发外包给专业服务提供商。虽然服务提供商在敏捷开发中也有自己的角色，但商业模式和参与模式都是非常不同。对于敏捷开发方法来说，托管业务用户是不言而喻的，因此，将大量工作送到别处的机会比较有限，其结果是，以某种形式雇佣附加人力极有可能是一个更有效的模式。
9：敏捷开发影响的不只是软件开发团队
“持续交付”概念是敏捷开发方法的一个有机组成部分。敏捷开发方法是以企业管理者和使用者的持续参与为前提的，并由此出发将不断交付新的、修改过的软件的过程引导到营运环境里。所有这些都要求在企业治理和关系管理以及基础设施和运营团队的两个工作实践方面做出显著的改变。
10：其他软件开发方法在产品组合开发中仍然有用得到的地方
在大多数商业和公共部门组织里，应用组合会出现许多不同类型的开发问题，有些适合敏捷开发，而有些可能更适合那些增量、迭代式开发，有些则适合改良型瀑布模型。敏捷开发不是“更好”，只是更适合一些问题，但也会更不适合另一些问题。