极限编程的应用现状
敏捷开发在中国的实践面临怎样的挑战？
敏捷开发作为互联网时代的“产物”，在商业模式的运作下被迅速推广，它的确解决了一部分传统开发模式遇到的问题，如对需求的变化能快速做出反应，但同时也引发了许多问题，敏捷开发提倡的许多环节如结对编程、用户故事、评审会议等都有着较大的争议。
本文的最新版在：
http://www.zhangxun.com/?taijialliance/challenges
挑战的一种解释就是问题（issuesor
problems）。敏捷实践在中国遇到了哪些问题？十多年来积累的问题其实很多。以下是几个典型敏捷方法在中国实践遇到的问题与挑战。
Scrum的主要缺点是过于理想化（美式理想），而且从一开始就不是为中国的软件江湖量身定做的。如何改变原有的考核激励机制和办法，取消针对开发团队每个个人的绩效考核，取而代之的是针对团队整体的考核？如何在此基础上进行公平、有效、合理地奖惩？如何去除国人积习已久的技术官僚体制和命令控制式（command
and
control）管理，推行并建立真正的自组织、服务型领导（Leader-Servant）、管理者教练（Manager-as-Teacher
or
Coach）等新型团队管理文化？如何改变管理结构，取消传统的项目经理和产品经理岗位，建立Scrum
Master、Product
Owner等新的岗位？如何有效地选拔出胜任这些新式岗位的领导，主要依靠员工民主投票？如何解决安排好老领导的去留，平稳地解除他们的职位，而尽量避免公司内部的政治与权利斗争？如何让一个极简的Scrum管理框架与公司现有的软件研发管理流程、方法、技术和工具等各方面很好地契合、集成，真正可持续地发挥出提高效率、进度和质量，减少开发成本的总体效益？如何让回顾会议（Retrospective）发挥真正的价值，让所有人（包括领导）敢于在会上作真诚的批评与自我批评，承认自己的错误？如何减少江湖习气，建立一个真话多于假话，好人得到重用不受排挤的团队文化氛围和环境？请大家补充。。。以上这几个难点没几个国内企业能全部或真正做到吧，真正能做到恐怕只有少数一流领导企业。真Scrum是很难的。绝不是像某些Scrum认证培训所教的那样，整一个十几个人的团队，每个迭代像模像样地开几次meetings就可以解决，获得Super
Productivity的。
Scrum其实是一种后现代管理（Post-Modern
Management），它的实质内容带有革命性或者叫管理创新。而国内大部分的二三流软件企业连现代管理都还未成熟，还做得不够好呢。所以，我估计国内至少九成以上（99%?）是伪Scrum（Pseudo
Scrum）。XP实践在国内遇到了哪些问题？首先，这十多年来，我本人在国内没有见到过一家真正符合极限精神、全面做到XP的公司，除了拥趸心中的XP伟大旗舰，不过这也只是我听说并非亲眼所见。据我观察，绝 大部分的公司只是采用了XP的个别或一部分实践（如用户故事、CI、TDD等），而他们的总体开发流程和指导框架则是其他，如Scrum、ISO
9001、CMMI、UP或自研的。这说明了什么？2010年以后，随着Scrum认证的大热，大家都忙着开班捞钱或快速镀金、抢个上位，这几年下来好像已经很少见到有人在媒体和社区里把XP作为一套独特、整体的方法论来谈论了。而且国内外还有一个现象，自从Kent
Beck发表了他的极为重要的极限编程2.0（XP2）名著后，（恕我孤陋寡闻）怎么这么多年我们好像没看到过什么有广泛影响力的XP2书评和深入研究的文章，而XP2新添的这么多实践也几乎无人问津？大家讨论来讨论去、有印象的依然只是XP1的那几个特色实践（CI、TDD和PP）。CI持续集成（CI，Continuous
Integration）是国内外接受度比较高、可谓已基本普及的一个XP实践，最主要是因为CI开源工具经过充分竞争后已趋于成熟。不过，CI在国内还是存在一些应用上的误解和误区。很多人误以为CI就是最佳、最适合、唯一的敏捷代码集成方式，不知道Daily
Build or Nightly
Build等集成方式也是可选的敏捷实践，而国内许多中小团队其实并不需要CI，因为团队规模小，在一天之内他们的主干代码变化不大，或CI带来的效益并不显著，没必要在一天之内多次集成、测试主干，而且CI并不是国内许多中小团队敏捷改进优先级最高的那块最短板，CI的价值有被夸大之嫌。其实CI更适合大型团队。TDD测试驱动开发（TDD，Test
Driven
Development）是一个争议较大的XP实践，尽管有不少坚定的支持者，十多年来在国内外却也一直遭到不少专家的批评。受到媒体和运动式跟风的影响（在伟大运动中，你不紧跟，就可能成为遭鄙视的异类），许多人都声称他们在用TDD。然而，自动单元测试与TDD其实是两个不同的概念（尽管TDD中包含了自动单元测试）。国内许多码农、菜鸟由于未系统地学过（或不熟悉）软件工程方法论，所以常常有误解，以为：只要做了单元测试，就是TDD；只要用了JUnit，就是TDD——把两者混为一谈，然而事实上他们并没有在做TDD。TDD包含了几个明确的步骤和技术，有一个规范的执行流程，它的最大的缺点和问题在于test-first（尤其是单元测试驱动）。在我看来TDD并不是什么完美、成熟、全面的开发方法，虽然它有局部价值，但只是一种片面、不成熟、部分有效的半截技术。据我观察，国内真正严格坚持采用TDD的开发者和团队其实是很少的，许多项目和产品的开发不需要、没必要、也很难都从编写单元测试开始。于是乎，国外后来出现了改进版的ATDD（验收测试驱动开发）、BDD（行为驱动开发），但国内用的、研讨的人不多，相关的技术和工具也均未成熟。另一方面，JUnit类的自动单元测试工具确实是一项优秀、伟大的发明，目前基本普及了，但用了JUnit未必要用TDD，务实的敏捷开发者完全可以根据需要来决定编写单元测试的最佳时机，无论先后。事实上这些自动测试工具比TDD方法论本身更具有价值，在日常的敏捷开发中是必不可少的。PP结对编程（PP，Pair
Programming）也是一个争议较大的实践。据我所知，国内严格坚持一贯采用PP的团队也是很少的，反正我是没见到过。每一个功能都必须由两名程序员结对在一台电脑前合作完成（Wikipedia:
All code is produced by two people programming on one task on one
workstation）？这似乎又是一种一刀切的极端想法。没错，PP在某些方面确实有一些好处，例如高手与低手结对，进行肩并肩地指导、教学，对低手的帮助提携往往是很大的，而且两人结对后，写代码时始终有一个人在帮边盯着帮着review，不知道怎么做了两人还可以一起研讨好于一人苦思冥想，理论上这么做确实可以提高开发质量和（局部的）效率。然而，质量是上去了，团队的整体开发效率呢，是否为此要花费更多的总体开发时间？另外，两个都已是高水平的程序员有必要结对吗，是否是浪费时间？如果某人对独立实现某个功能已有很大把握，这时旁边再坐着一个人，要么指指点点，要么一声不吭、冷眼旁观，是否还有必要，不是浪费么？如果让两个低水平或者没啥经验、不懂配合的程序员结对，恐怕质量和效率都难以保证吧。PP似乎更适合对进度要求不紧、时间较为宽松的项目。PP的替代方案之一是偶尔（或按需）结对，后者没有PP那么极限，即让一部分代码通过结对完成，而另一部分代码由单人完成，可以有时候结对，有时候不结对，要不要结对完全根据临时需要和具体情况而定。问题是，自始至终、时时刻刻严格执行的PP，对于团队开发的整体效果是否就一定优于偶尔/按需结对？对此，国际上目前尚无定论，缺乏靠谱、足够的科研比较数据和论证。不同于PP，按需结对并非什么全新的实践，其起源可能远早于1990年代吧。这恐怕也是国内外大部分团队一直沿用至今的编程方式。遇到难题不会做了，或者新手缺经验，两人临时结对互相帮助、指点下，做好了又分开，各自归位继续独立开发，这样做有什么不可以、不好的呢？
国内采用PP还有一个现实问题，一个功能的代码全部是由两个人共同完成的，那这代码做好了、做坏了算谁的？在此基础上，如何公平、合理、有效地进行个人考核？再加上XP的另一个实践“集体代码所有制”（CCO）以及PP的轮转效应，导致每一块代码都没有一个固定的负责人，任何人都可以修改任何一块代码，这更是与国内普遍流行的个人绩效考核制相矛盾，可见PP施行起来绝非易事。而国内大多数团队没有盲目地采用PP，看来是个聪明的决定。用户故事。。。重构
。。。