对敏捷开发(XP)实践的一些看法

敏捷开发(XP)的宗旨：“崇尚个人和交流而不是过程和工具；崇尚软件开发而不是文档；崇尚客户合作而不是合同条款；崇尚随需应变而不是简单计划”。如果我们把敏捷开发定式化成某种过程或者工具集合，实际就呆板了。
敏捷开发(XP)的表现：结对编程，代码共有，持续集成，代码复审，测试驱动开发，不断重构，保持简单。

先建立一个迭代开发和测试的流程，每个迭代周期在1-2周左右。以这种简单却又必要的敏捷过程来了解和熟悉敏捷过程。由于是试点新的方法，各种项目干系人对此报有希望，同时也会有怀疑。所以在试点过程中一定要做到项目的透明，包括进度、问题、解决的方案、下一次迭代的改进、本次迭代实现的目标。及时有效的沟通会减少很多干扰，增加很多支持。 清晨的例会、成果展示、迭代开发都是容易理解、容易做到的，那就坚持下来吧。一定要做好版本控制。

完全走敏捷开发，人力成本很高，对管理要求也很高，中国人想法很多，很难做到结对编程的好处，还需要一个摸索和实践的过程。敏捷开发，其实国内早就在推行，只不过推行的方式一直拿不上台面而已。至于推行的效率高低，于这个敏捷的团队成员的个人素质要求较高，3--5年经验的，只属于刚刚一只脚踏入软件开发的门槛，对设计架构似懂非懂，这种情况下，推进慢是必然的。首先我们要知道，敏捷模式不是全能的，也不是什么人都能的，一定先要有针对的人，然后再做针对的事。

没有文档的软件是一种灾难。代码不是传达系统原理和结构的理想媒介。团队更需要编制易于阅读的文档，来对系统及其设计决策的依据进行描述。
然而，过多的文档比过少的文档更糟。编制众多的文档需要花费大量的时间，并且要使这些文档和代码保持同步，就要花费更多的时间。如果文档和代码之间失去同步，那么文档就会变成庞大的、复杂的谎言，会造成重大的误导。
对于团队来说，编写并维护一份系统原理和结构方面的文档将总是一个好主意，但是那份文档应该是短小的（short）并且主题突出的（salient）。“短小的”意思是说，最多有一二十页。“主题突出的”意思是说，应该仅论述系统的高层结构和概括的设计原理。
至于如何来培训新的团队成员，使他们能够从事与系统相关的工作呢？我们会非常密切地和他们在一起工作。我们紧挨着他们坐下来帮助他们，把我们的知识传授给他们。我们通过近距离的培训和交互使他们成为团队的一部分。在给新的团队成员传授知识方面，最好的两份文档是代码和团队。代码真实地表达了它所做的事情。虽然从代码中提取系统的原理和结构信息可能是困难的，但是代码是惟一没有二义性的信息源。在团队成员的头脑中，保存着时常变化的系统的脉络图（road map）。人和人之间的交互是把这份脉络图传授给他人的最快、最有效的方式。
许多团队因为注重文档而非软件，导致进度拖延。这常常是一个致命的缺陷。有一个叫做“Martin文档第一定律（Martin’s first law of document）”的简单规则可以预防该缺陷的发生： 直到迫切需要并且意义重大时，才来编制文档。