“极限程序”解决问题的基础反映出TRIZ理论提供了很多发明问题解决方案。本文是将功能强大的软件开发方法作为发明问题解决方法的第一步。 
        首先对比了根里奇阿奇舒勒的著作：《发明问题解决理论》（TRIZ）和“极限程序”（XP）的软件开发/处理办法。两种方法都可以在一个问题得到解决之前，生成一个解决方案。使用“极限程序”这种方法是在说明一种新颖独创的软件系统正在开发中。使用TRIZ方法则是说明有一个问题需要解决，而解决的方案正在通过某些发明问题解决的形式，在不断的生成。

　　 在本文的以下内容中，我们概述了XP的基本规则，并描述它与传统的瀑布型软件开发有何不同。在第三部分，我们提供了一些阿奇舒勒和TRIZ的背景资料。第四部分则对XP提供的方法和TRIZ提供的方法进行了对比。第五部分指出了该课题的进一步的研究方向。

　　极限程序

　　      瀑布型软件开发方法最初是由温斯顿罗伊斯在1970年提出来的。这项传统的软件开发方法的步骤包括：

　　      1．需求规格说明

　　      2．设计

　　      3．编码

　　      4．一体化

　　      5．测试和调试工作

　　      6．安装

　　      7．维修

　　       每个阶段完成之后才能进入下一个阶段。从某种意义上说，某个可以传送的阶段“降落”到它的下一个阶段上，就像瀑布一样，这是此方法名称的来历。它也被称为线性时序模型的软件开发方法，而它失败的原因是：软件项目很少按照顺序流来完成；变更处理方法不是瀑布型方法的固有体系；所有的要求不会引起优先的编码和测试；另外，一个项目的工作版本在发展进程完成之前是无效的。

　　       瀑布型方法经常被称作：重量级方法。因为它为软件开发提供了一个十分规范并受严格控制的围观管理策略。XP是由肯特贝克发明的，他了解所有软件开发小组所要使用的方法都需要根据他们的自身情况进行量身定做。XP在程序和文化上与瀑布型模式主要有12个不同的关键做法：

　　      1．规划过程：XP的规划过程让XP的顾客得以界定业务的价值，这被称作用户要求。

　　      2．微型施放：XP小组在早期的生产过程中嵌入一个简单的系统，然后在一个很短的周期内进行频繁的升级。

　　      3．隐喻：XP的团队使用一个共同制度的名称和说明，以帮助指导发展和通讯。

　　      4．简单设计：所有的程序设计都必须符合但不能超过有关规定。代码在不符合规定是不可编写。

　　      5．测试：程序员在编写需要测试的编码之前，要先编写测试单元（白箱测试）。顾客直接验收测试（黑箱测试），以决定所需要的功能已经提供。

　　      6．重构：重复和不良代码在出现的时候立刻移除或者合并。

　　      7．结对编程：XP的程序员需要成对的编写程序。一个程序员“驱动”而其他的“编写”，程序员的角色需要经常转换以保证他们精力充沛。

　　      8．集体代码所有权：所有的程序员都拥有该项目中所有代码的所有权，任何一个程序员都可以在必要的情况下更改另一个程序员所编制的代码，这种做法可以加快编程的过程。

　　      9．持续集成：XP的团队每天都多次将编码集成到主系统中。这种做法有利于消除集成问题。

　　      10．40小时工作周：为了不使程序员犯更多的错误，XP工作小组不允许每周工作40小时以上。这种做法是为了让程序员保持活力，健康和有效的工作情绪。

　　      11．现场客户：一个XP项目必须掌握在一个专门的且有能力制定规定的个人手上，他必须制定优先次序，并作为编程者回答问题。提高沟通能力和减少硬拷贝文件往往是一个软件项目中最昂贵的部分。

　　      12．编码标准: 为使团队可以有效的展开工作，一套严格的规则必须得到严格的执行。所有的程序员都必须以同一种模型编写程序。