神话1：神话本身。
神话2：只要开发过程遵循敏捷的构建过程，就能够显著提高生产力和品质。
乍听上去，这句话逻辑非常正确。其实细想一下，这句话其实是倒果为因的，误把敏捷这个结果当成原因。打个比方说吧，等于说跑的快的人一定跑的迅速。敏捷方法论的名字起的太妙了，就相当于跑步运动员的名字叫飞速那么传神。敏捷专家们现在也越来越提倡tdd,scrum这些工具，似乎通往敏捷的路掌握在他们的手里。
其实，敏捷原本的意义是：
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
也就是
人和交互 重于过程和工具。
可以工作的软件 重于求全责备的文档。
客户协作 重于合同谈判。
随时应对变化 重于循规蹈矩。
其中第一句话就是“人和交互重于过程和工具”，这恰恰和现在所谓的敏捷专家们在敏捷中过分推崇构建过程矛盾。敏捷原本引入的意图是改变之前软件开发中过于强调僵化的流程的造成的，可没想到现在却被僵化的人给搞成僵化的过程了，令人深思啊。
神话3：可找到一种工具，能够把人解决不了的依赖问题，代码控制问题等交给它解决。
小时候大家喜欢看超人，每当自己碰到无法解决的问题，他就从茫茫人海中挺身而出，上天入地帮你解决所有的困扰。在软件开发过程中也是的，开发问题层出不穷，大家在过程，文档，代码中叫苦不迭，这时候“专家”会拿着一个公司的产品说，用了他，你们的烦恼就没有了。其实大家想想，软件是人写的按照一定的思路在一定的模型里解决问题的工具，如果人的思维不能解决的问题，那这个反应人的工具基本上是无能为力。任何工具都需要操作者按照一定的规则去配置它，给它正确的输入，它才会给你所需要的东西，感觉就像个机器狗，你摸它一下就摆尾巴。如果你非要按照不正确的方式操纵他，自然得不出正确的结果。它不会思考，只会解决问题模型里的问题，唯一的优势是什么呢，它算的特别快。可惜啊，算的快也是会思考的人赋予它的…
神话4：软件设计的好能够适应一切需求变化
有一阵子，大家兴起了设计模式的高潮，那时去面试必考设计模式。生平不识四人帮（GOF），十年开发也枉然。所有的书也过于强调适应需求变化的重要性，当时写软件必须是三层的，数据访问层，服务层，表现层，其实有些简单的需求根本没有服务逻辑，只是直接调用了数据访问层；有些接口根本不会有其他的实现。为了考虑扩展性，大家都将其扩展接口作到了极致。结果呢，软件规模膨胀的很快，代码维护量也大大增加，拔苗助长是要付出代价的。设计过分强调扩展性，软件的性能，可维护性都急剧下降。反过来说，为什么一个工作在特定环境中的软件要能够适应超出特定环境的需求呢？其实还是没有对用户的需求进行进一步思考造成的。作为一个用户，我当然希望买到跑的快，又不吃草，还便宜的马，那你作为售货员就非要给用户找这么一匹马？当然我不否认确实要往用户的需求靠，但是要仔细分析用户的需求，来给他找一个满足他的需求最便宜的马。真正对用户负责任其实是站在他的立场上思考他到底需要什么…
神话5：只要加强管理，软件开发过程缺了谁都行
曾经听到一个PM说，想着把流水线的方法引进到软件开发中来，觉得开发就相于流水线上的工人，每人按照软件开发流程组装成软件就可以了，稳定，高效。这个譬喻用在软件上是不恰当的，一条流水线上基本只能生产一种类型的产品，大家都对这个产品的组装，结构搞得非常清楚。而软件制品几乎每个都不同，如果真是完全一样的，那就不需要组装了，直接拷贝比流水线更高效。一个好的软件制品是在充分理解特定用户需求，经过设计，开发，测试环节形成的一个可演化的思想的痕迹，不同的人来做可能会有不同的风格。如果你只想做流水线一样的产品满足不同的客户，那你可以采用流水线的方式去管理人员，但提醒你的是，不需要流水线，只需要拷贝…