敏捷过程是针对复杂项目内外部条件的不确定性而提出的自适应性软件开发过程，但是，目前敏捷方法遇到的一些矛盾限制了过程主动适应变化的能力和适用项目的规模。
1) 满足需求与控制变化的矛盾
变化与不可预测性是长期困扰软件项目管理的难题，传统的软件项目管理存在一个难以成立的假设，即：客户需求总是能在开始时确定。在项目开始时定义所有的需求，在项目收尾阶段试用完成的产品以确认各项功能与需求一致，期间所有的需求变更都对项目管理过程产生负面影响。理论与实践证明，在软件开发之前准确地把握当时的需求及其之后的走势是不可能的。
敏捷方法的提出反映了对软件项目管理思想的根本性变化，管理者必须承认软件过程是由变化中的业务需求驱动的，而且，敏捷项目管理的目的就是快速适应需求的变化而尽早提供客户满意的产品，对变化的态度不应该是排斥而应该是欢迎。但是，理念的转变使项目管理陷入另一个困境，即：承认需求的不确定性很容易造成项目目标的不确定，在目标不确定的假设下项目管理的很多计划、控制方法因为失去了原有的一些必要前提而失灵。
目前的敏捷方法大都以现场的、近视的、短迭代的方式保证项目以持续的步伐向客户满意的目标逼近，过程的结果依赖于反馈的速度的对系统的作用，项目过程的多种假设都是极端的：客户在见到交付的产品前不会知道产品应该是什么；开发者只能犯错然后改正它；对未来产品的长远估计没有什么意义，YAGNI（你将不会需要它）……。处理项目的确定性与不确定性不只是预测和评估那么简单，既要注意到软件项目中大量不可预测和不可控因素的存在，正视其对实现项目目标的威胁；也要正确识别项目中稳定和规律性的特性，不能简单地将软件项目作为一个纯粹的探索过程，重要的是在对确定性和不确定性的控制上求得一个平衡。项目管理者很难在项目目标的确定性和不确定性问题上有一个明确的界定方法和简单的决策策略，这是目前多数敏捷软件项目实践效果不理想的主要原因。
2)项目目标与组织战略的矛盾
目前基于敏捷方法的项目管理一直面对一个难以跨越的问题，即项目的规模。大多敏捷方法将其应用范围限定在一个小型项目的环境下（几人或至多十几人的小团队、不超过一年的开发周期等）。一般的解释是敏捷项目的过程以最少的文档和面对面的沟通为必要的基础，沟通方式和过程重量无法支撑大型项目的沟通量和时间要求。事实是，敏捷方法的精益思想与项目的规模并不存在相互制约的关系，规模的扩大也不会必然造成沟通的困难和需求或设计信息传递质量的下降。根本的问题在于，敏捷方法始终把解决问题的思路限制在项目的范围内，甚至是单个客户的某个项目范围内来考虑，而不愿依靠整个组织的力量来解决问题。当反馈的、演进的思想被局限于一个具有临时性、一次性等基本特征的“项目”概念下时，项目的目标就变得扑朔迷离，开发过程成为一个探索过程。
项目的目标与组织的战略必须统一才能有利于组织的发展，进而提高完成项目的能力。把软件过程作为一个软件产品的建构过程是近视的，而每一个项目和项目中的每一个迭代周期应该是对组织的产品平台建构的过程。从项目目标角度看，组织的产品平台是项目开发过程的副产品，而从组织战略的角度上看，每个项目的交付物都只是产品平台的衍生物。项目的目标不能仅仅限于在项目结束时为客户提供了满意的产品，而且要为企业产品平台的建构有所贡献。因此企业产品平台对企业的生存发展起着至关重要的作用，有成熟的产品平台能大规模的敏捷过程提供基础，进而推动组织过程的成熟，提高敏捷过程的质量。
建构和迁移过程
传统的软件过程把软件产品的开发过程描述为一个客观的对客户现实需求的传递过程，强调产品是对客户需求的客观反映，产品需求一旦形成定论（即需求得到确认），产品开发就成为一个简单的标准的唯一的过程。只看到过程的客观反映需求的特性，而对产品开发过程的能动性、建构性、中介性没有予以足够的重视。
客户的需求必须经过开发者自身的建构，在现有产品结构的基础上，转化为最终的产品。产品的开发过程可以表示为根据需求分析成果进行建构和迁移形成产品的过程。开发者内部建构的成果是接受和实现未来需求的中介。
|