每个人都在抱怨软件中的bug。有些是可以容忍的，但许多不仅令人讨厌，还会导致工作效率下降。如果使用有bug的软件很糟糕，那么想想在软件供应商负责质量保证会是什么感觉。然而，总部位于澳大利亚悉尼的软件开发公司Citect的质量经理Bernie Beaudoin说:“我每天早上去上班都很兴奋。这很有趣。”
他有什么问题吗?不。让他有这种感觉的是一种名为极限编程(XP)的软件开发和管理工具的应用。软件用户具有不同级别的编程专业知识，从基本的到熟练的，但是极限编程背后的思想可以使所有级别的用户受益。XP应用了一些简单的规则，比如倾听客户的意见，不要把事情弄得过于复杂，以及团队合作，这些都可以带来很大的不同。
博杜安花了很多时间为美国海军开发软件，对军事标准非常熟悉。他喜欢他们要求的严格，但不喜欢那些必须附加的文件和要求的沉重重量。他在担任1998年悉尼奥运会的流程经理时接触到了敏捷编程方法。
奥运会任务结束后，他回到了美国的一家使用XP的公司，那里开发的软件质量让他兴奋不已。他说，看到这个过程很有趣。这一过程包括:
•开发轻量级规格
•在开发实际代码之前使用测试用例
•在开发人员编码时，围绕整个过程进行系统测试，以便构建更好的代码
•在整个过程中融入客户。
质量保证
产品开发和制造需要一个正式的过程，以确保满足质量参数。这些要求通常通过质量保证(QA)和质量控制(QC)程序来实现。然而，两者之间有很大的区别。QA从项目地图上的零点开始。它涉及预先规划质量，需要预先投资。QC是在产品开发后进行的。构建功能和系统测试，并在产品基本完成后对其进行测试。
在软件开发中，质量控制可能看起来比质量保证要快，因为代码可以“完成”并进行测试。然而，问题是开发测试来预见软件将面临的每一个条件是不可能的。这意味着不能保证软件产品将是无bug的。程序员可能会这样说，“我已经开发并测试了我的每个函数。让我们把它们都扔到一起，看看会发生什么。”也许一个函数会占用大量的内存。在独立的测试中可能不会注意到这一点，但是当作为更大的功能测试程序的一部分使用时，它会导致问题。
如果从一开始就考虑到质量，那么前期开发成本可能会更高，但通过减少后市场支持和提高客户满意度，这些成本会转化为更高的利润。Beaudoin指出，当QA方法与敏捷方法相辅相成时，结果是“显著的”。
XP方法在下面的“12步程序”框中概述。在Citect成功的应用包括:用户故事;常数测试;与客户互动讨论;并频繁更新变化。
用户定义的软件
用户故事开始这个过程。与功能规范类似，这些描述描述了客户希望用产品实现什么，以及如何使用产品。故事在整个开发过程中不断被完善。这种方法相对于编码的一个元素是，开发是在可以频繁查看的模块中完成的。在每次查看时，客户将模块与他们的故事进行比较，并根据需要进行改进，在项目接近完成时消除意外。
将此与典型的产品开发过程进行对比。客户将一个巨大的功能规格文档倾倒在项目经理的桌子上。开发人员进入休眠状态并开始编写代码。随着完工日期的临近，这个项目进入了疯狂的状态。在软件发布日期之前，没有足够的时间来完成所有的功能测试。现在，客户被带回到系统中进行最终检查。经过这么长时间，最初的假设被遗忘了，预期也发生了变化。结果是客户感到惊讶和沮丧。
这可以通过频繁的客户交互和开发阶段的定期测试来避免。这保证了更好的质量，更少的最终系统测试和更短的项目时间。
软件项目需要两种类型的测试:代码段的功能测试和系统测试。XP认为这两种测试都应该经常进行，如果可能的话每天都进行，并且应该包括开发人员和质量保证测试人员。开发人员首先为他们正在处理的对象开发功能测试，编写代码并运行测试。如果测试成功，对象将进入代码库。测试代码可能只是暂时的并在此时被删除，或者它可能被保存并合并到类似对象的测试中。
质量工程师在项目开始时开发系统测试。功能测试用例和代码被包装到系统测试中，因此随着日常测试的进行，整个测试基础不断增长。从人的角度来说，这需要测试人员和开发人员之间不断的沟通。他们作为团队的一部分一起工作，而不是作为对手。测试人员参与到编码阶段，因此他们熟悉代码以及代码是如何开发的。在软件方面，不断地进行系统测试，根据需要对测试进行修改，以反映新的实际情况，快速地纳入客户输入，并且比使用其他方法更快地生成好的代码。
Beaudoin认为，传统编程方法的一个弱点是程序员和测试人员之间产生的敌对关系。每个程序员都相信自己正在编写完美的代码。然而，测试人员发现了所有这些错误。在XP过程中，测试人员是程序员的伙伴，以合作而不是竞争的关系在同一个键盘上工作。与传统方法相比，XP方法还需要更少的产品测试工程师。Beaudoin只使用4对(共8人)进行所有产品测试。他指出，由于采用了XP方法，这个相对较小的测试团队可以完成大量高质量的测试。“将过程集成到团队中是我们XP工作中不可分割的一部分，”他说。“这真的让程序员对测试和质量充满热情。这是一种新的做事方式，但它不是一种宗教。 It’s a philosophy that is constantly evolving. We’re probably one of the few real-time environments using XP.”
站立会议
XP的另一个方面是每日站立会议。团队开会，真的是站着，每个成员轮流有几分钟的时间讨论一个问题或一个成功。整个过程需要10到20分钟，但它可以让每个人都了解进展。经理们经常注意保持动态。
博杜安说:“这很有趣。我们先开一个管理层站立会议，然后我和我的团队开会。这既快捷又有效。如果我从管理层那里得到了方向上的改变，我就会回去告诉他们，我们的工作重心有了一点变化。我们能做些什么来帮助他们?他们通常会说，当前的工作可以用更少的人完成，所以我们把他们释放出来做新任务。
“最终，我们发现强有力的测试减少了客户投诉电话。事实上，许多打电话来的人会说我们做得很好，而不是质量部门通常会接到的批评电话。”
Citect自称是最大的工业自动化软件独立供应商，拥有超过30年的开发人机界面、监控和数据采集(HMI/SCADA)软件和工业信息管理系统的经验
CitectSCADA的最新版本(版本5.42)是第一个使用XP方法开发的版本。该版本包括自动诊断工具，可捕获客户系统信息进行分析，加快解决客户问题的速度。
12步计划
极限编程方法提倡采用12步程序来最小化软件错误。该组织的网站www.extremeprogramming.org详细讨论了这些问题。
1.开发用户故事。这些为发布计划会议创建时间估计，并代替大型需求文档使用。它们是由客户编写的，作为系统需要为他们做的事情。
2.召开发布计划会议。在这个会议上创建了一个发布计划，它列出了整个项目。然后，发布计划用于为每个软件版本创建迭代计划。
3.创建发布计划。这精确地指定了每个系统版本将实现哪些用户描述，并指定了这些版本的日期。
4.经常向客户发布系统的小部分。这对于及时获得对系统开发有影响的有价值的反馈至关重要。
5.使用迭代开发。在每次迭代开始时召开计划会议，计划要做什么。
6.调动人员以避免严重的知识丢失和编码瓶颈。如果团队中只有一个人可以在一个特定的区域工作，而这个人离开了，或者该区域需要完成更多的工作，那么项目的进展就会变得缓慢。
7.首先进行单元测试。创建单元测试可以帮助开发人员真正考虑需要做什么。要求通过测试被牢牢地确定下来。
8.配对程序员。产品版本中包含的所有代码都是由两个人在一台计算机上一起工作创建的。结对编程在不影响交付时间的情况下提高了软件质量。这是违反直觉的，但两个人在一台电脑上工作，增加的功能与两个人单独工作一样多，只是质量要高得多。
9.每天召开一次站立会议。整个团队之间的沟通是站立会议的目的。每天早上的站立会议是用来交流问题和解决方案，并提高团队的专注力。
10.为棘手的技术或设计问题找出解决方案。尖刺解决方案是一个探索潜在解决方案的非常简单的程序。
11.保持客户的可用性，不仅可以帮助开发团队，还可以成为开发团队的一部分。
12.经常集成。开发人员应该在任何可能的情况下，每隔几小时就将代码集成并发布到代码存储库中。
12步计划
极限编程方法提倡开发好的软件产品的12步计划。这些都是:
•开发用户故事
•召开发布计划会议
•制定发布计划
•经常发布小片段
•使用迭代开发
•让人们四处走动
•先进行单元测试
•配对程序员
•每天召开一次站立会议
•创建钉钉解决方案
•保持客户的可用性
•经常集成。
有关极限编程的更多信息，请参见Kent Beck的《极限编程解释:拥抱变化》一书。
