小版本：用最少的代码工作量带来最大的业务价值。
这个原则是意思是为了高度迭代，与客户展现开发的进展，小版本发布是一个可交流的好办法，客户可以针对性提出反馈。但小版本把模块缩得很小，会影响软件的整体思路连贯，所以小版本也需要总体合理的规划。
这么一说，感觉这一原则对我们公司的产品是没有什么适用性的，我们不可能让运营商承受这样的高度迭代过程。然而，正如我一开始就提到的，我们学习敏捷开发、极限编程的目的不是为了解决所有的问题，而是开拓思路，防止我们的思维僵化。据我的观察，我们的测试部开发的自动化测试、调试软件就非常适合利用这个原则。客户是谁呢？就是负责生产调试的内部客户。
自动化测试、调试软件有个很大的特点就是：变化快，而对于这个特点，正是敏捷开发理论所特长解决的。目前对于这类软件的管理的强度远远要弱于那些产品软件，一方面是因为这些软件因为在使用过程中需求变化太快，如果按照公司的规范输出各类文档，并且按照常规流程管理的话，无法做出及时地响应，会影响工作。另外一方面，就是开发人员的主观因素，常常这类软件都是开发人员在生产线与负责生产调试的人员即时沟通即时修改的，这样的习惯也就导致了习惯成自然，我们的“客户”养成了习惯，开发人员也被迫养成了习惯：开始的时候开发人员往往想反正软件改起来也要比硬件来的容易，那就改吧，一来二往，突然有一天发现自己突然陷入了一个泥潭。
作为技术部的配置管理，我就多次发现这些自动化的测试、调试软件版本混乱的情况，而且从使用这些软件的人员反馈回来的声音中，我们也可以听到对于软件质量方面的抱怨。这就是我说到的“泥潭”：作为开发者，自己每天疲于修改，却无法得到“客户”的认同，这是一件多么让人郁闷的事情啊！
那么我们是不是可以考虑利用敏捷开发的方法来解决这些问题呢？或者，通过一种思维上的启发来“创造”一个适合我们实际情况的方法来解决这些问题呢？我想到了一些改善的方法：
n 增加小版本信息，在软件运行中就能够看到大、小版本信息。
n 增加在线更新功能，这样无论身在公司何处，只要能够连入内部网络，就可以及时、准确地更新程序。
n 增加版本检验功能，根据需要检测版本是否需要更新，以此来保证当需要时，保证所有的客户端都运行在一个基准之上。
n 增加错误反馈、日志功能，保证当错误发生时能够通过邮件将必要的信息反馈给开发者。这样可以防止在问题反馈时问题无法复现或者反馈人说不清楚的情况。
这些方法其实都是我们在很多软件中能够看到的功能，并不是什么新奇的技术，实现起来也很容易，而且我们可以将这些功能作为一个公用模块来保证不同的自动化测试、调试软件不用重复开发。这些功能的实现将会让你体会到更多的方便。
有了这些基础，我们就可以在软件开发的过程中将高迭代过程变得更容易控制、实施起来的效率也会更高，效率提高了，时间节省了，才能有条件去思考、去改进。就如同我们的胳膊自由了，呼吸顺畅了，才有可能将自己从泥潭中解救出来一样。
