最近写的两篇关于XP的blog

XP应该是老板的最爱，而不是程序员的首选

　　我们现在这个公司的大老板，平时在三楼办公。但是，每天都会有几次，他会在我们的办公室里走来走去——“进行着聊胜于无的监督工作”。

　　我想，他大概没有听说过“XP”、“结对编程”这样的名词。

　　4月15日，周六，我参加了BEA上海User Group的一次活动。北京来的Charls，做了一次非常精彩的演讲。名字叫做《一个Xper的心路历程》。全场笑声不断，Charls的感染力征服了每一个人。

　　演讲最后提出的一个观点是：“成为一个Xper，就是成为一个合格的程序员”。要勇于暴露自己的不足，要善于沟通，要谦虚，要有计划，要……做到了这些，我们才算是“刚刚够格”。

　　我基本上已经被说服了……在Charls演讲结束的时候，我只想问一个小问题。因为他说，在项目组里，如果有人遇到问题，不要自己偷偷摸摸的Google搞定，而是应该马上“举手”，看看小组里有没有人能够马上告诉你答案。这才是“勇于暴露自己的不足”。而我还想从另外一个角度问一下。

　　（以下对话是一个大概的回忆）

　　“我一直以来的工作方式是这样的，遇到问题的时候，首先Google一下，这样我不但可以找到当前这个问题的答案，还能够了解很多周边的知识，触类旁通。如果直接问人的话，问题解决，我也就不再深入了。这样是不是对于个人能力成长不太有利呀。”
　　Charls：“项目进度在那里，当然是马上解决问题最好。”
　　我：“那么我们是不是可以这么理解，XP对于项目开发的目标很有效，而对于程序员个人能力的成长目标，不是很有效？”
　　Charls：“我一直这么说，XP更加高级的剥削方式……”

　　顿时，我豁然开朗。XP的好处，从老板的角度来看，应该更多：

　　结对编程——最有效的相互监督机制
　　结对编程——最有效的内部培训机制
　　测试驱动开发——最有效的质量保证体系
　　User Story＋客户现场办公——最低成本的需求收集、分析机制
　　每日集成——有效降低集成、测试成本
　　…….
　　从程序员的角度来说，这些“与我何干”呢？

　　所以，一个追求利润最大化的老板，就应该选择XP，而一个聪明的老板，不但要运用XP，还要保证8小时工作制，甚至给员工20%的On Beach时间(来源于Gigix对于ThroughWorks的介绍)。这样才能保持员工的可持续编程能力。如果我是老板的话，我就会这么干！
　　那天讨论的话题中，还有一些XP没能够很好回答的问题：
　　比如文档。在我以前的开发实践中，我们都建立了一个Wiki，并且强制程序员每人每天就Wiki几次，以分散写文档的压力。
　　比如对于人员的高要求的疑问。我的理解是，XP对人员提出了很高的要求，但是同时也提供了最有效的人员培训机制（结对编程），所以，对于入职人员的要求，并不需要很高，更多的是考察一个人的沟通能力、学习能力，而不是开发的能力。

代码质量与文档质量

　　几段在脑子里盘旋了很久的话：

　　带一个项目，要保证项目的质量，当然要靠Team Leader的水平。那么，什么才是最重要的项目质量呢？当然是代码质量！一个软件项目，最重要的产品当然是代码！

　　如果这个Leader看不懂项目的代码，他只能通过要求文档的质量，来间接的控制代码的质量。一个能够看得懂代码的Leader，他就能够直接控制代码质量。而能够直接控制代码质量的Leader，对于文档的要求，会合理很多。

　　直接控制与间接控制，哪一个更加有效，是不言而喻的。当然，那些没有代码阅读能力的Leader，他们会更加强调文档的重要性，甚至舍本逐末，认为文档质量才是项目质量的体现。进而变态地追求文档完美，以至于浪费了程序员写代码的时间。这样的Leader，根本就不可能管好项目的。

　　公司往往会出于恐慌，向员工要求很多详尽的文档，主要是为了防止员工离职带来的损失。而问题在于，公司的主要努力，应该用于留住员工，而不是用于加强“善后能力”。更不是为了增强善后能力，搞得员工越发想离开这家公司。

btw:

补记一段交锋对话：
《软件开发项目中的成本比例》是我以前写的一篇blog，有一个GHawk有这么一段留言：

UP和Agile都是工程过程实践的总结，林德彰先生说过“UP是正楷，XP是草书。先学好了UP，才能学好XP；先学XP再学UP就会乱套。”
Agile强调的是“代码是真正有价值的东西。”这同样也是实践的结果。二位对于过程有不同的看法并不能说明孰是孰非，这只是在不同的实践内容和阶段上的总结。在过程的选用问题上，只有不断地实践才是前进的方向。

另外还有一篇blog，专门讨论这句话。

我的回答是：

林德彰的说法，是一个在校教师，典型的和稀泥的说法，我不同意。

没想到今天有一个朋友WANG回了一帖：

老林是在校教师？你应该去看一下人家在美国打拼的经验~~ 

我的回复是：

他在美国打拼怎么了？还有好多土生土长的美国人，也不鸟那什么UP呢？
我为什么要听一个海龟来上课呢？
这年头，海龟还不够多吗？

另外对GHawk多说一句话：让组员快速磨合的最好办法，是结对编程，而不是大家埋头写文档。

嗯

假定 设计 代码 文档 测试 维护 销售都由一个人来完成 他会最关心什么.

我想他肯定不会去研究xp

说服老板使用结对编程很难。。。
毕竟2个人的钱，1个人的活，尽管质量有所提高。

同时结对编程大大提高了工作强度，时间长了累啊。。。
呵呵，有点类似玩游戏的时候，是和人pk累，还是和电脑pk累，:-)

我大二时上过林老师的课~~~狠好的老师，狠难得。观点上大家可以互不相同，不过我必须说这样的老师在大学里讲课是非常难得的

同感同感。虽然没有正式P过，但是有几次和同事一起讨论设计一边编写代码，感觉时间过的可是真快，讨论结束了也觉得有点累。也许是还不习惯吧。

剥削于无形之中...

我也不同意林的说法，比喻不恰当。

就实践来讲，我感觉中国目前普遍接受的可能实践是迭代开发，测试驱动开发，持续集成等。结对编程不太现实，感觉距离是那么遥远。

我觉得不同的人是不是也适合不同的编程方式呀？

人品好关点不一定正确。。
关点不一定一辈子不会变