需求真的在一直变化吗？

　　不一定是这样，例如对传统行业的信息化，由于有相对稳定的工作流程，需求变化不会很大。并不是所有的软件项目的需求都是变幻莫测的。如果在项目初期没有对需求进行全面的捕获和确认，那项目进行过程中出现反复修改，以至于返工，都是很可能的事。
这就对需求捕获人员提出了很高的要求，需求不但要全面，准确，还要考虑到实施中的每一个细节，如果某个细节出现不符合客户实际的要求，到项目实施完成之后，可能要进行一个工作量很大的修改，还会牵扯到其他的功能，在修改的过程中又会引入新的问题，这就象所说的牵一发而动全身一样。
 
　　不同的软件开发过程对于需求变化的解决办法是不同的。
 
　　统一软件开发过程（UP、RUP）的解决办法是预防和控制需求的变化。
 
　　敏捷的方法如XP，则倡导拥抱变化。

　　一、统一的方法
　　统一软件开发过程是通过在项目的前期尽可能准确，全面地捕获需求，然后对需求的变化加以控制和管理，来避免范围的蔓延，并通过迭代和递增的开发方式，来应对变化。
 
　　从软件工程发展的历史，我们说在项目前期全面地捕获需求一直是一个做好软件的不二法则。
 
　　对业务逻辑相对稳定的项目，在项目实施之前做好需求的捕获绝对是受益匪浅的，因为软件的问题在生命周期的后期发现需要的成本要比在初期发现高得多。
 
　　迭代和递增式开发也降低了项目的风险，他允许在项目进行过程中对需求进行校正，它通过递增的版本发布使得客户能在软件开发生命周期过程中就对软件有了更全面的认识，因此也能及时的提出改进意见。
 
　　从团队的角度看，迭代的开发更符合人类学习的曲线－一个渐进的过程。在项目开发的初期，开发人员对业务逻辑和技术的掌握可能并不全面，随着项目的进展，认识会不断加深，这对于后期的迭代周期的成功是很好的保障。
 
　　然而，某些项目确实存在很多不确定因素，还有某些大型项目，历时时间很长，在那么长的时间里需求会变化是很自然得事情。
对这些项目迭代和递增的开发方法会比在项目早期就尽可能地捕获需求更有意义。

　　一、敏捷方法（XP）
　　以XP为例，他提出以拥抱变化来应对需求的变化，他并没有强调在项目的初期确定能确定的需求的重要意义。这与传统的软件工程观点和统一软件开发过程有差异，他不主张预防需求变化，因此也就没有强调尽可能在早期确定需求。
拥抱变化与其说是一种方法，不如说是一种心态的调整，XP方法希望开发人员能有良好的面对变化的心态，不讨厌变化，积极面对变化。
 
　　心理因素对于软件行业是非常重要的，软件的本质决定了软件的成败更多的依靠人的因素。软件的可见性差，生产率的衡量也是需要考虑相当多的因素，需要相当高的学问的，一般的管理人员懂管理未必懂软件，懂软件呢又未必精通管理，因此XP的发明者觉得与其费力去度量和评估，不如发挥人的积极主动精神。如果一个软件开发组织的人员能拥有积极向上的心态，那会比实施任何一种软件开发过程，采用任何业绩评估方法都更有效。
 
　　拥抱变化的确是一种非常优良的品质，这不仅仅对于软件需求如此，对于日新月异的软件行业不也如此吗，不跟上技术潮流就会被淘汰，作技术的人员都是深有体会的。同样，面对飞速发展的社会，如果没有积极的心态来应对各种变化，改变固有的观念，也一样会被时代所抛弃。
 
　　但是，我们如果既能拥抱变化，又能未雨绸缪，不是对事情的进展有更好的把握吗？这不等于又多了一层保障吗？就像很多人说疯狂英语是失败的，因为很少有人能一直保持着疯狂的学习态度，的确是这样，即便我们有拥抱变化的准备，和积极的心态，如果连续为变化而加班数月的话，相信一样会有挫败感，如果那时你还能以积极的心态来应对变化的话，我相信你将来一定能成就一番大事业。
当然XP的拥护者会说，XP不提倡加班，我们每周只工作４０小时，这当然是一个好的主意，如果能够实施，又能满足交付期限的话，那我们应该为你祝贺。
 
　　XP同样采用迭代的开发方法，小版本交付，来使得客户对软件尽早有更多的认识和了解，这和统一软件过程是相同的。

　　二、结论
　　纵观统一软件开发过程和敏捷方法对于需求变化的解决方法，我们可以得出结论：

　　预防变化，做到在软件开发的初期就尽可能确定可以确定的需求；

　　控制需求变更，避免范围蔓延；

　　以积极的心态来拥抱变化；

　　采用迭代和递增的开发方法，

　　是解决需求变化的最佳方法。