过往往也是很难实践的。
就我个人来说，我就不喜欢两个人一起编程，我觉得每个人的思考其实很难同步的，每个人都需要静下心来一个人思考问题，思考后才适合与别人讨论，如果思考过程也与别人在一起，很难想象这个思考能有好的效果。
我们曾经将两位编码新手放在一起，让他们结对编程，尝试了这个实践，似乎有一点效果，但我们后期就没有再推行过。
3）代码共有：每个人写的代码都是属于全体的，每个人可以去改别人的代码。
这里强调共享与进步精神，欢迎互相研究代码，欢迎写出更好的代码，只要能通过测试就可以了！这个实践是依赖于测试驱动开发以及自动化测试这两个实践的，如果不能做到那两个实践，就不应该随便改动别人的代码。
4）强调编码标准
对于这点大家应该没啥异议了，现在有不少开发工具支持编码标准检查呢！
项目管理方面的最佳实践：
1.持续集成
持续集成与微软的“每日构建”是一样道理的，强调我们的软件要随时处在可以编译通过可以发布的状态，持续集成让软件的问题提早暴露更快解决。持续集成需要一定的工具和管理措施支持，我有这样的一些实践建议：
1）代码的签入与签出要定下严格的规矩，如：每天工作前先获取最新代码，每次签入前必须先保证编译通过。
2）如果能做到测试驱动测试和自动化测试，那么还应该规定必须通过所有测试才能签入代码。
3）一般来说我们没有条件做到每日构建，也没有这么多工具支持，那么至少一周要编译一次内部版本，检查软件各部分的协调情况。
2.站立会议
每天早上项目组全体开5-10分钟会议，所有人站立讲话，简单讲述昨天工作概要、今天计划、需要别人协调或解决的问题。站立的目的就是让大家言简意赅，提高会议效率。每天开这个会，是保证大家有足够的及时的口头沟通。极限编程认为，口头沟通才是最有效直接的沟通。
在我们的项目中，我也会推行站立会议，但不一定是早上，当然也不一定非要站立，但是会议一定必须是高效的！口头沟通很有效，但必要的记录还是应该有的。一些公司推行站立会议，往往是没有会议记录的。而我的做法是会议中如果有决定、有代办工作，我会要求记录下来。口头沟通算然来得直接，但容易理解错、容易忘记等缺点是避免不了的，应该辅以适当的书面记录。
3.小版本发布
分小版本多次发布，最符合客户的利益，客户可以先使用部分功能，可以在此基础上更好地思考后续应该做什么。
小版本到底应该有多小呢？国外很多书会建议3个月，不过3个月对于国内的项目来说，太长了！我们经常要在很短的时间内做出一个大系统！
我们公司每个版本的发布周期以前大概是一个月，现在已经缩小到2-3周了。
4.每周工作40小时
加班是我们IT人的家常便饭，极限编程反对加班！那么是不是我们只要工作时间到了，哪怕很多事情没有做完，就直接下班呢？
这条实践的真正意思是我们应该充分利用好工作的40小时，少做最好不做无用功，少返工。实际上我们很多加班是因为我们做了很多无用功、返工导致的。
人的脑袋每天能高速运转8小时其实已经很了不起了，如果还要加班，那么只能带来更多的bug，得不偿失！不过我们很多公司的老板喜欢看到我们这些打工仔忙，看到我们加班，而不管实际的效果，这真是悲哀啊。
极限编程的各条实践是有关系的，我觉得最基础的最重要的是测试驱动与自动化测试，这两条做不能做好，重构、代码共用等实践就难以实施。
极限编程很多东西很讲究灵活，但测试驱动这条是最死的要求最严格的，整个灵活的体系其实就是靠这一条来保证质量的。很多公司实践极限编程时，不能做到测试驱动，就简单设计，就随便改代码，随便因应需求变化而变动代码，这些工作都没有了质量保障的基础。
极限编程我们需要整体来理解各条最佳实践，并根据实际情况加以调整，为我所用！
下面将会稍微简单一点介绍另外了两个比较常见的敏捷开发。
特别声明：
如需转载此文，请给出指向本网站的连接，如下：
作者：张传波
摘自：http://www.umlonline.cn
如不能按此要求，请不要转载此文。