没啥主题，想到哪写到哪，纯属闲谈。
1. 微软与敏捷
敏捷的形成是先有实践而后才有的理论，也就是说一帮人坐在一起分享各自的成功项目的经验，发现有一些相同的地方，相同的理念和思维方式，总结出来才有的敏捷宣言。既然是成功的经验，其他公司成功的经验多多少少也会有相同或相似的地方，只不过他们不叫敏捷而已。就好像市面上有那么多关于编程实践的书，从《程序设计实践》到《代码大全》再到《注重实效的程序员》，虽然名字不同，用的语言不同，里面的实践大体上还是那些东西，只不过是换了种说法而已。
2.劳动强度
我承认作pair以后强度增大了，但是我宁可强度增大也不愿意加班。从个人生活角度来看，人人都有自己的生活，工作不是生活的全部，下班以后我应该可以做自己想做的与工作无关的事。如果能够通过加大工作强度达到不加班的目的，我愿意。从事业的角度来看，工作强度加大其实是因为我把更多的时间和注意力放在了工作上，而不是浏览新闻或者聊天。这样我的一天8小时是一个高效的工作与思考的过程，我没有虚度光阴，我的技能和经验是增长的。而且由于不需要加班，我也会有更多的时间学习一些我感兴趣的东西。从兴趣的角度看，我喜欢写代码，喜欢做开发，喜欢解决问题，虽然一天很累，但是我乐在其中。从责任的角度来看，我获得的薪水是付给我每天工作8小时的，不管是不是pair我也应该好好工作8小时，因此pair没有增加强度，而是把你拉回了正常的强度。
3.敏捷的宣传
可以说敏捷说的东西比较虚，以至于一些人无法理解，另一些人唾弃。近些年来精益的流行其实是敏捷社区想要找一个易于理解的方式来解释敏捷。”价值驱动，避免浪费”是精益和敏捷共同的价值观。
4.程序员的水平
不可否认，有些软件只能由一些天才或者水平很高的人才能做出来，例如C#，Unix等等。可是这个世界上的多数应用的逻辑都没有这么复杂，外包公司的程序员水平相对技术水平较低确实是事实，但是作为一个软件开发者，技术水平并不是唯一的标准。敏捷中也强调一组中等水平但是能够很好合作的开发人员，要比一组水平很高但是不能很好合作的开发人员更有效率。一个人的沟通技能、合作技能也都是和技术水平一样重要的。在外包行业做得好的人，技术可能不如作产品的，但是他的沟通能力，对客户业务的熟悉程度却可能比做产品的要好。不能说哪个更好，只能说各有特点，各有适应的环境。技术大牛做好框架和基础构件，业务好地做好上层应用，这就行了，就好像说做C#的一定不如作C的技术好么？从我自己的经历来看，我的技术很不好，但是相对于很多技术好的人来说，我的大局观，对项目整体的考虑，对客户的理解都要比他们好，我不认为我就比他们差（虽然有的时候还是希望技术能好一点）。确实没有必要一味追求技术，难道项目经验还不能帮你工作到50么。工资有高低,职业无贵贱,软件行业需要的不只是技术.
另外，敏捷对技术是有促进作用的。要想达到拥抱变化，要想减少浪费，需要有技术的保证。通过良好的设计，自动化的测试等手段，提高程序的可维护性。
5.需求变化
敏捷宣言的一条是：拥抱变化。是的，对变化的处理和响应从RUP到CMMI都是一个被关注的问题，也是所有项目中需要管理的，处理的方法也不是出现一天两天了。但是敏捷的贡献不在于提供一种处理变化的方法（事实上没提供，因为迭代交付不是新概念），而是心态的改变。从防御、预见到拥抱；从讨厌、管理到接受；敏捷告诉我们，变化是不可避免的，是一定存在的，因此从心态上就要把它当成是水可以结冰一样的正常的事情，去接受他，想办法管理他，而不是想尽办法回避它。
6.敏捷是一种思维方式，是一种文化
敏捷到底是啥？实践？方法？流程？多数人愿意看成是一些实践，比如TDD,PP,CI,Refactor；一些人愿意看成是方法论或流程（如CMMI，RUP）。我更愿意把它看成是一种思维方式（作为个体）和文化（组织级），其主要的目的就是带给客户最大的价值，避免浪费。至于具体如何做，其实没有定式，所有的敏捷实践都只是一些成功手段的“最佳”实践。（最佳实践的意思其实就是：我不保证你用了之后一定管用）。如果你把它看作是一种思维方式的话，它就和所有的旧有的实践、方法没有冲突了，只是你看问题的方式变了，做事的方式变了，选择工具和使用工具的方式变了，工具还依然是那些。