http://blackwhite.blogdriver.com/blackwhite/330506.html
其中提到关于IPMP（戏称“爱拍马屁”）的一些感觉，和我的猜想相同，虽然我只是从同事朋友的一些说法中知道什么是PMP,但我本能的觉得那不是我所喜欢和值得投入的东西。
常常有种说法“软件工程的名称来自建筑行业”，我想，总该是让软件工程超越按部就班的建筑行业哲学的时候了，没有敏捷思维，软件会失去其生命本身的活跃性和艺术性。
教条主义是我尤其痛恨并敬而远之的东西
重温一下敏捷宣言：
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
人和交互重于过程和工具。
可以工作的软件重于求全责备的文档。
客户合作重于合同谈判。
随时应对变化重于循规蹈矩。
在网上溜了一圈，发现另外一篇文章（敏捷软件开发：关于反馈和革新）对敏捷宣言的翻译如下：
1．进程和工具的个性化和相互作用
2．在完善的文档指挥下运行软件
3．在签署契约下的客户协作
4．在计划指挥下的反应
和第一个翻译所不同的是，第二个翻译更着眼于两个概念之间的共存性，协作性，更具有包容性和平衡感。而第一个翻译倾向性更强，旗帜更鲜明，价值观更执着。我个人从观感上跟欣赏第一种，但从实际出发，更认同第二种，在现实工作中，妥协，平衡常常比执着要更有建设性，当两个观念能有共存和共生的可能时，我想“6:4原则”会显得更厚道一些：既兼顾了两方面的考虑，又有一定的原则性和偏向性。比如，我现在倾向于在工作采用6的敏捷方法（如XP）来完成工作，4的重型方法（如ISO,CMM)来对付流程--当然，精力和时间的分配是一种艺术，在某些细节阶段，采用73原则或82原则，也未尝不可。但10:0是应该尽量避免的。
