OOPAA

    前一段时间读了Matt Stephens 与 Doug Rosenberg 合著的《Extreme Programming Refactored: The Case Against XP》（以下简称《Refactored》）。该书虽然是针对 Kent Beck 的《Extreme Programming Explained: Embracing Changes》（以下简称《Explained》）第一版进行阐发，然后 Kent Beck 在《Explained》第二版里面也修正了一些 XP 的理念和态度，但是《Refactored》书中提到的一些见解和看法现在读来还是挺有意思的。
   
    比如作者一开始就讲了个“皇帝的代码”的故事新编，把皇帝比喻成迷信开发方法的客户，然后 XP 者就是两个骗子，利用不具体的过程标准来欺骗现场客户以及审查的其他人，并赢得最后的release，却最终被小孩子揭露出来的故事。不可否认的是作者在其中做了过多的假设和有失偏颇的类比，最终使得故事显得过于荒诞和不切实际，但 XP 在那个急于推广自己的年代用一些过激的宣传词，从而引起这样那样的误解，也是正常的。这也是 Kent Beck 在《Explained》第二版里面修正的主要方面，使得 XP 更具可操作性，概念不显得那么的突兀而容易误解了。
   
    撇开这些不谈，觉得特别有意思的是作者在书中把 XP 和马克思主义来做对比，得出一些共同点，也颇让人若有所思。这里闲话不多讲，直接贴上书中几处 XP 和马克思主义进行对比的地方。
   
    1. XP 里面的代码共有与马克思主义提倡的集体所有制
    Just for fun, we did a little research on the subject of collectivism, outside of an XP context. It came from Marxist “power to the proletariat” sociopolitical theory (more on Marxism later). Here are a couple of interesting quotes that we found:
    Karl Marx -- “Since the supreme aim of collectivism is the abolition of that capitalistic regime which enables one man or one corporation arbitrarily to exploit the labour and the necessities of many men, it obviously does not—in theory at least—imply equal compensation for all individuals, nor the destruction of individual initiative, nor the establishment of a bureaucratic despotism.”
    然后引用 Robert C. Martin 的话就是：
    “The only constraint that XP puts on you is that any production code has be [sic] written by a pair. Your preferences and comfort do not supercede the delivery of quality to the project, or your parcitipation [sic] in the team.”
   
    2. XP 里面自组织团队与马克思主义提倡的人民专政
    Karl Mars -- Power to the Peeps
   
I was recently interviewing a programmer for a potential contract, and he happened to mention that he had worked on a project in which his team had attempted XP (but found it too difficult for various-reasons—in particular, that management wouldn’t buy in to the new way of working. Eventually they abandoned the “experiment” [which it quickly became known as], keeping unit tests but not much else).

I asked him what he most liked about XP, and he immediately perked up with, “It empowers the programmers! Puts us on an equal footing with the management. . . .”

    可以看到的是，这里面有些确实是 XP 没有解决好的问题，或者 XP 没有明示的东西。万幸的是，XP 不是一个固步自封的软件开发方法学，而是更注重它所强调的价值和原则，比如简单、沟通、勇气和反馈。所以，在实际开发过程中，不同的项目组在不同的项目环境下会裁剪出合适项目、合适组织的方法学。所以，前面两个问题其实在 XP 的框架内也都是可以解决的。
   
    我们来看第一个问题：代码共有导致个人失去成就感和幸福感。其实这个问题的更深层次是：
    1. 敏捷团队如何评价个人performance？
    2. 敏捷团队如何激励个人创造？
   
    其实这个问题也是我们在做培训的时候，学员们问得最多的问题。在传统的文档式开发过程中，开发人员的工作量被量化成代码行数或者 bug 修正数，虽然大家都知道这其实并不能反映真正的工作量，但毕竟可以作为他们衡量开发团队成员的 performance 的一个参考值。而 XP 一方面宣扬 pair programming 以及代码共有，另一方面又宣扬增进设计和重构，这样统计个人的代码行数或者修改的 bug 数对于绩效考核就没有任何帮助。那么，在敏捷里面是怎么解决这个问题的呢？
   
    我想，在检查个人performance在项目组内部通常都会有自己的办法，符合公司文化和价值的评审方法。以我们公司为例，通常是由每个人找4－5个项目同事来给他写 feedback，提供对这个人在项目里面表现的反馈。因为 XP 提倡勇气和反馈，所以，每个人也是会基于一个比较客观的态度来对同事进行评价。这样，从项目同事的反馈里面，就能得到比较全面的个人 performance 信息了。
   
    如何激励个人创造？对，因为 XP 提倡简单设计，通过重构来增进设计，所以在设计里面考虑更多的是设计是不是满足当前的业务需求，是不是容易让项目组其他成员所理解。但是，这并不意味着敏捷就不允许引入新技术，不允许进行大范围设计。这里不举我们公司的实践，在《透析敏捷编程》一书中提到了在项目组中使用“金卡”实践来激励个人创造，就是允许项目成员申请金卡来进行新技术研究或者大范围设计。因为 XP 提倡沟通和勇气，所以只要开发人员有具体理由，并且项目组同意个人在某方面花费时间精力，那就是应该尊重和允许的。

    所以，从上面来看，XP 并不会导致个人失去成就感，重点在于项目组是否足够 XP，足够敏捷来让每个人都达到自己的幸福感和成就感。如果没有，建议通过团队 retropective 来找出有效的改进方法。
   
    我们再来看第二个问题：在项目组内，程序人员地位不比项目管理人员差。其实这个问题的更深层次问题是：
    1. 程序人员应该听从管理人员的指挥，怎么能提出异议呢？
    2. 如果程序人员有自己的想法，那管理还能进行下去么？
   
    那么，我想大部分拥有这个疑虑的人应该是传统的项目经理。但是自从在 javaeye 里面看了一篇把开发团队比喻成正规军的比喻之后，我发现有些开发人员也倾向于接收管理人员的命令，而不是更积极主动地提供自己的建议，去和管理人员进行更有效的沟通。其实，我们在做培训的时候，和一些项目经理也谈过这方面的问题。开发人员不善于与他们沟通，导致他们对开发团队的真实状态不清楚，他们觉得非常不放心，于是反过来进一步要求开发团队提交更多的文档来反映他们的状态。这样，开发团队文档任务增重了，怨声载道，项目经理就更得不到项目团队的真实状态了。于是，恶性循环就形成了。

    在开发过程中，随时都有可能会发生影响项目交付的问题，比如原来估算的工作量有偏差、客户对某一处需求提出了修改等等。很多事情项目经理是不可能事无巨细都会察觉的。这些问题在传统软件方法学里面都是作为风险来管理的，于是项目经理在预防各种各样的风险中忙得焦头烂额，“兵马未动，粮草先行”，不到最后一刻不敢让开发人员进行开发。因为一旦进行开发，而开发人员不积极主动反馈项目状态的话，项目经理对于项目就是完全失控了。这是项目经理无论如何不敢面对的。可是，“防民之口，甚于防川”，项目开发过程的风险，是能完全堵死的么？如果开发人员可以有机会，也无风险地发表自己的看法，项目管理就可以是更轻松了的。而且，一个人的智慧总是有限的，当客户逼着你做决定的时候，你不希望项目团队的人能站出来，助你一臂之力么？把全部责任都一肩扛，只会对项目不利，而谈不上有益。从另一个方面讲，每个人都是希望有一个上升的职业生涯，希望能不断提升自己。软件组织也是希望能不断涌现表现优秀的员工，从而有利于组织的成长。那为什么要打压开发人员积极参与管理的兴趣和付出，最终影响组织的成长呢？
   
    在培训中，大多数项目经理也能认识到项目团队沟通的重要性，但对怎么建设这样的团队仍然显得方法不多。XP 作为充分照顾了人性的方法学，也是提出很多原则允许或者鼓励开发人员积极沟通，表达自己的想法。所以，运用 XP，建设好简单、勇气、沟通和反馈的良好氛围的团队，不仅对于每个团队成员，对于项目经理，对于其他管理人员都是有百益而无一害的。为什么不尝试一下呢？
   
    马克思主义说过“集体所有制”、“人民专政”，毛泽东思想也说过“实事求是”，邓小平理论更是说“不管白猫黑猫，抓到耗子就是好猫”。在《Refactored》提到的一些误解，其实都不能作为反对实施敏捷的理由。我想，如果果真是阻力重重，或者不知道如何开头，或许可以考虑请求于一些专门提供敏捷咨询的第三方组织了。