国内工控软件开发行业正处于发展阶段，工控软件开发大多都具有研发性质。而国内软件行业也处于发展阶段，缺少成熟的软件开发团队，缺少高素质的软件开发人员和管理人员。在这种背景下，使得国内工控软件的开发具有如下特点：

1、开发团队规模小。国内工控软件开发行业的软件多数都是具有研发性质的长周期中小型软件，如盲目投入大量的人力，往往无谓提高成本。另外国内软件行业缺少具有大规模团队管理经验的人才，团队规模大了往往管理跟不上，反而使开发效率降低，产品质量也很难保证，所以国内工控软件的团队多是十人甚至更少的规模。

2、需求模糊导致前期工作不充分。国内工控软件开发行业多数软件项目是对国外已有技术的研制，往往功能需求模糊。开发团队在进行需求分析和概要设计时，很难做出充分准备并制定出完善的体系结构。这类项目在开发中后期还经常发生需求的变化。

3、团队的角色不完整。国内工控软件开发团队往往缺乏称职的项目经理，也很少在项目中专门安插一个领域专家，测试员往往由软件开发人员兼任，客户即使存在也很难做到良好的沟通和反馈。角色的缺乏和混淆使得管理难上加难，大大降低了工作效率。

4、软件开发人员观念陈旧，缺乏团队合作精神。到现在为止，国内很多软件开发人员仍然信奉着“个人英雄”主义。他们工作上个人能力很强，但是长期的独立工作，往往导致与他人的沟通与交流出现问题。这些显然已经不符合现代软件开发的需求了。

5、“格子”式工作环境——把一间大办公室用隔断分隔成多个小格子，每个人都在自己的格子里工作。这种工作环境很不适合进行研究开发：较高的隔断使得人们交流变得困难，狭窄的格子很难同时坐进2到3个人，也很难放下较大的开发设备。

经过国外近几年的实践证明，XP的确是一种优秀的开发方法，但是因为实际情况的不同，在国内工控软件的开发上全套照搬极限编程的模式是不现实的，这里面即存在着传统观念的阻力，也有着人员素质的问题。要改变人们长期以来习惯了的工作方式，必须循序渐进的逐步更改。针对国内工控软件开发的上述特点，可以考虑先在项目过程中引入XP的几个较容易见到效果并被开发人员接受的实践，待团队中的成员在进行这些实践中自己逐渐意识到问题所在后，再将XP的内容进一步引入，并根据实际情况进行适当调整。

第一是计划实践，通常情况下，开发团队的管理人员倾向于根据客户的需要制定时间表，却不去切实了解实现需求的过程细节，此时所制定的时间表往往是不切实际的。而客户的需求很少去考虑实际开发过程或者功能范围的调整，只是期望在预期的时间拿到预期的成果。这样所制定的计划一旦实行，伴随而来的会是大量的中期协商和观点折衷，而最终产品很难按期交付。XP的计划实践要求客户和开发团队的所有人员参与计划的制定，首先要由客户和开发人员一起确定项目要完成的所有任务及其优先级，然后由开发人员对这些任务进行估计并制定时间表和给每个开发人员分配工作。在项目开发过程中对时间表的任何调整都要在问题出现的时候立即完成。

第二是结对编程，习惯上是反对两个人一起开发代码的。管理人员认为开发代码所需人数加倍是浪费资源，软件开发人员认为编程在传统上是作为一种孤立活动进行的。但定量的证据表明结对编程使设计的结果更好，生成的代码更简单，更易于扩展，老练的结对软件开发人员认为结对工作的速度要比单独工作的速度快2倍以上。

第三是测试自动化，一个全面的测试程序是一个项目成功的关键。一个项目的测试在刚刚开始的时候不可能有全面的测试，但必须先制定一个柔性测试框架。在每个单元的开发过程中产生相应的样本数据、单元测试和功能测试，然后集成到测试框架中，最后达到一个完整的测试覆盖率。

第四是集成和发布，团队可考虑设置一台专门的集成工作站，所有当前代码库和测试程序都集中在该工作站上，每个开发人员都将自己的代码与集成工作站的代码库进行集成，并运行所有的测试程序。在测试程序覆盖率不足的时候，可将未测试部分罗列成表，每个人根据该表补充不足部分，并定期检查更新该表。

第五是工作环境，XP的沟通是非常重要的。一个良好的工作环境可以改善人与人之间的沟通氛围，提高人们交流的积极性。一个标准的XP团队工作环境应该是一个大的通透空间，中间（公共区域）集中了所有的工作设备，每台计算机前至少有够坐下两个人的空间，椅子是一定要方便移动的。四壁要有大面积的白板，人们需要讨论时可随时随地进行。四周可以安排些小房间用作休息和处理私人事务。项目负责人可以有自己的办公室，但在进行开发时一定要进入公共区域——这里没有等级。

以上提到的都是基础性的实践，随着这些实践为团队所接受，每个成员会逐渐意识到XP的真髓。这个时候再一一引入其它实践并检验这些实践的效果，适当予以扬弃，从而最终形成自己的软件工程方法和一个成熟的团队。