倒过来看的感觉——评解析极限编程
这篇书评可能有关键情节透露
我先是有了极限编程的经历之后再会过头来看这本书，原以为，Beck给出的是权威的测试指导这类肺腑和经验之谈，我好作出改进，但没有想到Beck介绍了12种极限手段和关系后，更多的是谈问题和解决问题的哲学思想。很意外，但也很有收获。
由于是倒过来看，所以很多事情就不会觉得一惊一乍。但还是被这12种手段的紧密联系这个体系所触动，以沟通这个原则来看，计划游戏、小版本、隐喻、简单设计、结对编程、集体所有权、现场客户、编码标准这些方法都跟沟通直接关联：
＊计划游戏：客户、开发人员通过故事卡功能卡进行沟通
＊小版本：获得来自生产环境的直接反馈（反馈是一种沟通）
＊隐喻：这个还不好说，不过根据意思是通过众所周知的故事指导开发，故事是沟通的一个很好载体
＊简单设计：当然，写复杂代码肯定不利于程序员间的沟通
＊结对编程：两个程序员坐在一个屏幕前直接就如何编写代码沟通
＊集体所有权：任何人任何时候对任何代码都有修改权，基于代码的沟通，当然，要求代码好读是必须的，简单设计起到了很好的作用
＊现场客户：客户回答程序员提出的问题，当然也是沟通
＊编码标准：对结对编程、集体所有权是绝好的支持，是一种开发团队遵循的沟通规则
Beck还谈到了怎么做计划、怎么用成本角度看待变更、看待决策，这些内容其实和编程没有很直接的联系，但是把这些思路从传统的管理者角度移入到程序员头脑中，算是一种不小的颠覆，这对程序员在做技术决策的时候会更为明智。
Beck总结了在哪种类型项目下不适合用xp，也指出用xp实施起来困难的原因，这对于实践有很好的借鉴意义。
如果看过Scrum的介绍，对这本书的理解会更全面，比如对计划游戏环节。由于我已经是实践过来的，这方面没有多少障碍，但是对于初次涉及xp的人未必如此。
Beck在书后所列的一堆书单也颇有价值，尤其是哲学部分，混沌理论可以看看，对于隐喻还不是很了解的话，参考这些书是很好的一个切入点。其实看了这些书单才发现为什么beck能够写出这么一本不是编程的编程书，很多哲理其实都来自于他多年编程的理解以及站在前人的肩膀，光是这串书目，大致就值回这本书的“票价”了。
（不到两百页的书，轻易就可以读完，希望很多方法论的书都这么易读好读）
由于是倒过来看，所以很多事情就不会觉得一惊一乍。但还是被这12种手段的紧密联系这个体系所触动，以沟通这个原则来看，计划游戏、小版本、隐喻、简单设计、结对编程、集体所有权、现场客户、编码标准这些方法都跟沟通直接关联：
＊计划游戏：客户、开发人员通过故事卡功能卡进行沟通
＊小版本：获得来自生产环境的直接反馈（反馈是一种沟通）
＊隐喻：这个还不好说，不过根据意思是通过众所周知的故事指导开发，故事是沟通的一个很好载体
＊简单设计：当然，写复杂代码肯定不利于程序员间的沟通
＊结对编程：两个程序员坐在一个屏幕前直接就如何编写代码沟通
＊集体所有权：任何人任何时候对任何代码都有修改权，基于代码的沟通，当然，要求代码好读是必须的，简单设计起到了很好的作用
＊现场客户：客户回答程序员提出的问题，当然也是沟通
＊编码标准：对结对编程、集体所有权是绝好的支持，是一种开发团队遵循的沟通规则
Beck还谈到了怎么做计划、怎么用成本角度看待变更、看待决策，这些内容其实和编程没有很直接的联系，但是把这些思路从传统的管理者角度移入到程序员头脑中，算是一种不小的颠覆，这对程序员在做技术决策的时候会更为明智。
Beck总结了在哪种类型项目下不适合用xp，也指出用xp实施起来困难的原因，这对于实践有很好的借鉴意义。
如果看过Scrum的介绍，对这本书的理解会更全面，比如对计划游戏环节。由于我已经是实践过来的，这方面没有多少障碍，但是对于初次涉及xp的人未必如此。
Beck在书后所列的一堆书单也颇有价值，尤其是哲学部分，混沌理论可以看看，对于隐喻还不是很了解的话，参考这些书是很好的一个切入点。其实看了这些书单才发现为什么beck能够写出这么一本不是编程的编程书，很多哲理其实都来自于他多年编程的理解以及站在前人的肩膀，光是这串书目，大致就值回这本书的“票价”了。
（不到两百页的书，轻易就可以读完，希望很多方法论的书都这么易读好读）
