观者自酌，这篇文章目的在于煽动大家热爱混乱模式，如果你喜欢其他模式诸如瀑布或者敏捷且鄙夷混乱模式的话，请勿拍砖。
先描述下实践环境，拉拢下支持者。
- 你有没有体验过，你的Dev Lead，你的QA Lead还有你的PM同时给你提出任务需求，但其中有几条竟然是互斥的？
- 你有没有体验过，后天就Release了，今天还有新需求？
- 你有没有体验过，说好了10月份release，结果拖到11月都没有发布，而且就当你绝望的觉得遥遥无期的时候，客户忽然拍板说Release？
- 你有没有体验过，很多enhancement的内容被修改成了defect(bug)，然后还告诉你是hotfix？
如果你都体验过，且每次都备受煎熬的话，那你很不幸的处于“混乱开发模式”中，另外也恭喜你，因为你幸运的看到了我写的这篇文章，其中一些规范将指导你如何应对混乱模式，并从中使整个team受益。
首先声明我对这个研究不是很深，只是把我所了解到的知识进行归纳总结，以供参考。说的不对的地方还请大家指出。
混乱模式（混乱开发模式，英文Crunch Mode/Chaos mode），在百度上没怎么找到定义，维基上也没有。
我暂且这么定义吧：混乱开发模式是一种以不同角色利益为核心、迭代、跳跃的开发方法。在混乱开发中，软件项目的构建被切分成多个阶段，各个子阶段的成果都不怎么经过测试，有时具备集成和可运行的特征。在此过程中软件一直处于可演示（Demo）状态。它的特征是：快，利益驱动，*，多bug，无设计文档，以及随机Release。
下面一一解释，附带宝贵应对经验：
快
这个好说，混乱模式之所以混乱就是因为各种因素都要求快，也难怪要快，这个快餐社会大家都浮躁的急着歘(chua一声，形容快速贪婪的赚钱)钱，你的客户要求快速提交可运行的软件，好部署实施后捞金，你的老板要求你快速完成需求，好更快的把你投入新项目，你的部门经理要求你快速完成任务，好在老板面前表述自己的管理得体高效。所以到了你这里，你只好逼自己快速开发，放弃好的编码标准，放弃好的设计模式，放弃code review，甚至放弃单元测试或者测试。Oh, my god! 这时有人会气冲冲的说，你带上这些东西，开发也应该快！实际上他以自己的开发环境，自己的公司实力，自己的经验来说的，他经受过重重考验，种种苦楚，才练就了高级的技巧，他十分希望你也体验一下，好显示出自己的不凡。在这里，我告诉你，在混乱模式中，你不仅不需要这样做，事实上更不推荐你这么做。我得承认，那位批评了你慢的高人说的对，更好的设计模式和代码重构是十分必要的，但不适用于混乱模式。既然这个社会不允许冷静，那么我们就浮躁，并且在浮躁中找到行之有效的进取方式和平衡。对于“快”这点的应对方式，建议先完成最重要最基础的部分，然后使用客观理由让项目天然delay。这里的技巧不厚道，不过项目本就该使用那么多开发时间的，客户既然不给，那么我们也只好采取天然delay来申请时间啦。
利益驱动
你身在软件公司的每一分每一秒都是利益驱动的，老板要剥削你的剩余价值，你要赚钱养家还房贷。如果老板是慈善机构且你也是主动奉献，那世界太和谐了，大家也就不要开发什么软件来让社会进步了，干脆原始社会不也挺好。所以，你的客户让你做的每一种行为都是利益驱动的，都是为了他能更多的赚钱。哪里能赚钱，哪个feature能赚钱，就让你做哪个。而不管项目人员有没有承载能力，或者时间够不够。这个时候，你要冷静下来，就算让你做windows，你也得说yes，但是得给我时间，仔细列出你所需要的人力物力，细到不能再细，每天上厕所和打饭都算进去，这样一来，客户看到你的预估，基本也会答应你延长开发时间或者干脆放弃无理要求。
*
不知道大家在开发过程遇到不统一的思想时候怎么决策，一般是开会吧，然后大多数同意即通过。混乱模式中，这一点是个优势，一个客户老板拍板就OK了，讨论个P啊。节省时间和人力，所以应对这种特征，我们要节省每次的会议时间，直接让客户老板拍板。并附上会议minutes以便拍板人忘记的时候拿出来show一下。
多bug
这是当然的啦：）不测试，不好的代码风格，以及胡乱改变开发方向及进度，自然导致了bug多。可是bug多有时候不是坏事儿，bug多我们就有更多的活儿干，bug多说明我们QA能力强，bug多我们才有官方时间进行项目修补。瞧，利益在这一点儿上找到了平衡，你又想雇JuJuJunior的people，又想提交高质量的code，又想节约开发时间，嘿~~太好了，最终结果就是得到更多的bug。不过客户眼里看不到这些，只要按时交付，bug多少无所谓。编写航空软件的人都不怎么坐飞机，编写银行网银的人基本不在线支付，你自己写的计算器恐怕你都不敢用吧？为了应对bug多的challenge我们可以借用千行bug率，或者借用人不是机器等诡辩来搪塞。总之bug多是必然，既然发生了，就得面对，老板不愿意面对，我们不能强迫，只好说以上词汇来潜移默化啦。
无设计文档
这条通常也可以理解为需求老变。没有设计文档？那你让我做什么啊！对，客户往往就这样，应对这种情况我们就要面向demo开发，先画出UI，或者写出接口。让客户反复讨论，并且不断的修改demo，甚至不惜使用项目开发时间的80%，你要明白，整个过程都是要不断改动的，所以demo很多时候是好事儿，帮你节省不必要的实现。其他开发模式指出，demo不能当开发范本继续使用，在混乱模式中，demo的地位非同小可，demo完了后，马上就是改bug！今天小张刚刚连线美国，给客户做了demo，demo包含一个主界面和一些菜单，以及一个表格，一些增删改查的button。转天晚上，客户就用不熟练的汉语说：小张啊，为什么我点增加按钮，没有增加一行数据啊？为什漠啊？小张表示压力很大。。。于是用熟练的汉语解释：这只是个demo啊，还没有实现。客户又慢慢说：啊？你说什么，我还以为能用啊，难道不是完成了吗？你们的bug太多啦！我点了好几个按钮都没有反应。这个时候小张无法压抑自己的感情，毕竟年轻人，工作没几年，不懂得客户就是上帝的道理，他终于爆发了，用不熟练的英文说：That is just a f*cking demo, understand? You suppose to believe that works, fine, You think we get it done, fine. How about you think you can poo with only a touch of the bathroom door. Scr*w your damn bugs! 从此之后，小张再没有来上班，老板在每次的混乱会议上拿小张当反面教材，说：看，这就是不懂混乱开发模式的下场！
随机Release
客户告诉你年底release，你可别真信，在混乱开发中，Release毫无时间概念，不是你说了算，也不是QA说了算，更不是bug少于某个阀值说了算，只要真正客户逼到头上了，不得不上线了，你的老板一声令下：Release！！！声音比电视剧里面的皇上驾到还洪亮，那么项目就Release啦！应对这种情况，要告诉自己Release不是任何因素能决定了，项目Delay也不会死人，bug多点儿更不是大事儿，安慰自己，安静的等待那声洪亮的声音就好了。
写的小小的总结吧，混乱模式实际上是一种应用各种因素平衡的开发模式，任何开发模式都没有好坏，只是偏重点不同，比如敏捷可能偏重随时交付和节省成本，瀑布模式偏向管理方便等。混乱模式更偏向于让所有人都过得去，不能光让客户省钱，老板发难是不？也得让底层人员得以喘息。这是混乱模式横空出世的原因，亦是我们为什么要研究它的价值所在。
这是一个开端，今后有更多的经验会发到其他的帖子，希望有同感的人也不吝惜的分享下经验哦。
大部分开发都是混乱开发，只是他们自己不知道或者不承认，既然无法逃避，我们就得想办法让混乱模式work，并且得到正面的结果，同时又不能伤害我们可怜又可爱的底层程序员们。
让我们继续努力让混乱模式越走越好！