软件开发管理流程的困惑——为什么最后开发的一堆东西都成了无用的代码堆积？
你没有说你从事的是产品型开发，还是项目型开发，我就产品型说点点自己的看法。1、关于需求变更。 开始写代码前，必须有需求文档，我建议这个文档由开发来写，需求的原始文档甚至可以不要，只要开发能懂
软件开发管理流程的困惑——为什么最后开发的一堆东西都成了无用的代码堆积？你没有说你从事的是产品型开发，还是项目型开发，我就产品型说点点自己的看法。
1、关于需求变更。
开始写代码前，必须有需求文档，我建议这个文档由开发来写，需求的原始文档甚至可以不要，只要开发能懂就行。开发处于需求和测试之间，只有开发写的文档，三方才能都看的懂。这个文档不要被各种格式所困扰，目的只有一个，三方认同。
有了文档，还是不要动代码。必须有一个三方确认的过程，请大家不要遗漏测试，测试在一开始就介入，对项目进程有莫大的好处。确认不应该只是个观看文档的过程，对一些重要的功能点，最好三方一起碰头讨论确定，否则，就文本层面，各人的理解差别可能很大。（就我个人习惯，会把各个功能点的复杂重要程度，以A、B、C、D来编号区分，方便之后的交流）如果是项目型的产品，文档还必须由客户签字确认，客户签字的文档尤其注意UI的描述。
最后，必须规定一个需求变更的流程。需求变更的原因应该附在原文档后面（不要改原始文档），我们一般是通过论坛回帖的方式在处理，需求、开发和测试都必须签字确认。进入测试阶段后，应该有一个Dead Date，超过这天，即使是错的，也坚决不能修改。正常一个项目下来，有20%的需求变更是正常的。
当然，最麻烦的是领导拍脑袋。作为技术负责人，必须要敢于说不，领导敢半路加东西，你们就要敢疯狂加时间，多弄几次他们就知难而退了。我见过很多傻乎乎的程序员，领导一说什么，他们就说简单啊，分分钟，也不征求需求和测试的意见，就开始乱改一气。其实这样做领导会更不重视技术，更会乱来。
2、开发的内部配合
如果有了上述了流程和文档，在开发之前，各个程序员的分工和大概的工作安排应该已经出来了。精确到每个工作日应该不成问题，建议Leader都先做个这个任务安排，不精确到每天，有时候进度不好控制，特别是需要协同的地方。
团队不要太大，超过5个开发的团队，就一定要拆分，国内开发的Leader一般都承担着重要的开发任务，不可能有精力管理超过5个人的团队。条件允许的话，最好空出几个人掠阵，不要分配太多任务给他们，他们专门做代码Review。
代码Review是很重要的，建议每个团队每周都有一次集体的Review，其实不用准备什么，弄个投影仪，把大家正在开发的代码投影出来就可以。代码Review有一定的套路，我建议只为了一个目的：降低代码复杂度。“复杂度”是个可以量化的指标，有兴趣的朋友可以找一下相关书籍看看。
A改的代码影响了B，这种情况很难避免，但应该控制在比较小的范围内。如果某些人经常出这种事情，那就把他贬去做很独立简单的东西，比如报表。加强开发的自测，可以制定相应的绩效考核，比如交给测试的产品质量标准，不能主要流程走不通，不能出英文提示等等，这时候不能手软，说多了没用，钱才是硬道理。
最近流行结对编程什么的，在国内应该实行不下去的，但是可以结对Review，弄些连带责任的绩效考核。至于单元测试，对代码的架构要求很高，做不动就算了。
3、关于测试
测试在国内软件行业的地位低下，这非常糟糕。建议一个测试团队起码能有个把两个白盒测试的，有个把两个精通各种测试工具的，有个把两个能做效率测试的。有些团队甚至连专职的测试都没有，这就非常堪忧了。
建议开发阶段，测试就要介入，完成一个功能能用，就应该马上交给测试，但开发阶段，主动权和话语权还在开发这边。进入测试阶段后，所有功能应该全部完成，这里应该也有个明确的日期，测试阶段应该由测试完全掌握主动权，有些错误开发可能会认为是测试吹毛求疵，那也必须尊重测试的工作。
其实不少错误开发改不动，或者不能重现，或者得不偿失，这些类型的错误可以延期不改，但也应该有一个严格的流程，起码不应该是随便一个开发人员都可以跟测试说什么什么不改。
想到哪里写到哪里，写不动了，也没有整理一下，见笑。好好学学软件工程，你这属于不合格的作坊式开发强烈推荐邹欣的软件工程书，很通俗易懂，看完你就没这些疑问了。你采用自底向上的开发就不会有垃圾代码了没有不会谢的花
没有不会退的浪
没有不会暗的光
你在烦恼什么啊
没有不会淡的疤
没有不会好的伤
没有不会停下来的绝望
你在犹豫什么啊
题主，来这里看看：
1 需求分析-软件产品的利益相关者
2 你的项目延期过吗
3 代码复审看什么
4 阿超的故事-第一辑
以上内容摘自 @李旭 的回答中推荐邹欣的软件工程书：构建之法，此为多看版。
我们先来看看这位朋友的体会：
在微软实习学到感触最深的事情是什么？ - 微软（Microsoft）
这位微软实习生颇有感触的事情是：
现在，国内一些高校中有远见的老师已经开始采用《构建之法》作为教材，来看看广州商学院这两位大三同学的阅读笔记：《构建之法》的笔记
在微软工作过的 @Andy Pan ，先后也在腾讯微信产品部门及如今相当hot的大疆公司担任团队leader，他读了《构建之法》，写了这样的书评：100倍速度前的慢动作 (评论: 构建之法)
什么意思呢？他说——
英雄所见略同。百度工程师牛尧在这篇题为相见恨晚-目前为止看过的最好的软件工程书籍 的书评中写道：
另推荐多篇来自不同IT公司的工程师或项目经理的书评_
水面下的冰山——读《构建之法》 (评论: 构建之法)/丁香园工程师
《构建之法》----迷你版的《代码大全》 (评论: 构建之法)/广州的一位工程师
构建软件工程的进阶之道 (评论: 构建之法)/清华同方资深项目经理
以独特的视角来看软件工程--读《构建之法：现代软件工程》/中兴通讯软件工程师
软件需要严肃对待，谨慎修改 (评论: 构建之法)/嵌入式开发工程师
===试读及更多介绍请参看这里。
邹欣在Build To Win - 构建之法 - 知乎专栏中说：
我把这段话发给七牛的许式伟，他果然对《构建之法》产生了兴趣，因为他也不提倡靠加拼命加班才能做好项目和产品，但他们团队又尚未摆脱不得不经常加班的困境。
邹欣最近在广州致远电子做了一次讲座，讲座文字实录汇总在此：
邹欣讲座：现代软件工程--构建之法
下面是去现场听过讲座的 @刘鑫 听了讲座之后写的专栏：
邹欣老师《构建之法》讲座广州（一）人才选拔 - 前路迢迢 - 知乎专栏
邹欣老师《构建之法》广州讲座（二）前夜 - 前路迢迢 - 知乎专栏
邹欣老师《构建之法》广州讲座（三）启动问题 - 前路迢迢 - 知乎专栏我对你提出的问题看法如下：
1、需求的问题不能光看表象，更不能听风就是雨，比方用户说要一个报表，那你至少要问清楚用户要这报表干什么？用户所关注的数据是哪些？如果这些都不清楚的话，那不是用户说报表太简单不实用，就是说报表太复杂操作不方便。在需求的收集中，如果涉及到专业的行业知识，则更需要请相关专业人士做好业务的指点，这点非常重要，因为这往往会影响到系统与系统的交互或后期功能的扩展。另外，需求必须经过严格的评审，因为很多研发人员认为很有用的功能，其实用户根本不用或极少使用，你所说的无用的代码堆砌应该就是类似这种情况。
2、关于开发的设计，我的建议是要极简，什么叫极简，就是以满足需求为根本目标，切忌过度设计和闭门造车，在设计过程中不要受到市场或同行的影响，因为需求是无止境的，如果需求的基线已经确认，那原则上应该尽快按需求定义出具产品原型请用户试用，尽快体现出自己产品的亮点和优势以引导客户，根据客户的意户和实际的情况，进行分析后再有计划的优化和完善产品。所谓的改改改，最大的问题是公司的开发设计及市场人员的思维局限。打个简单的比方，当年诺基亚盛行的时候，哪个手机制造商能按用户的需求设计出苹果手机？软件设计中有一个重要目标是如何创新和体现产品优势，要从服从客服变为引导客户，进而引导市场。在软件产品领域，要么你跟着别人的产品改改改，要么别人跟着你的产品改改改。当然这一点对于销售人员、实施人员的要求会比较高。
3、关于开发过程中程序员互改代码的问题，可以考虑每周进行组内人员的REVIEW，一个小组的人数建议在4到5人左右，负责1至2个产品的更新维护和一个新产品的开发。但代码的REVIEW受到参与人员编程水平及个人喜好、工作态度、情绪等主观因素的影响，所以代码REVIEW要有，但必要的测试也要做，数据的度量和收集更是必不可少，对于代码质量一直没有提高的人员，要考虑将其调至一个更适合他的技术或非技术岗位。另外，如果项目不是很庞大的话，尽量划分好模块或功能界线，尽量避免程序员之间相互修改代码的情况出现。
4、各项工作的组合及配合，关键在于是否有合适且明确的流程及审核，还有必须做好过程改进，比如某产品在需求阶段，一开始需求及设计人员的思路是明确的，产品的理念也是明确的，但等销售人员参与进来后，一会说张三的产品怎么好，一会说李四的产品怎么好。但是销售人员往往忽略了一个问题，就是张三或李四的产品是否解决了用户的问题，用户在使用这些产品时是否有不适的地方，或者说我们的产品能否能超越当前市场上的产品，这才是产品设计应该关注的点。一个手机制造商抄苹果抄的再象，也是不可能超越苹果的。所以上述的案例就是典型的非设计需求人员引导开发的案例。所以各项工作的组合及协作，在每个阶段都要明确参与的人员是否合适，排除不必要的干扰，由适合的人做适合的事，要抓好评审工作，简单点说，抓头抓尾，中间卡里程碑。
这种现象在日常的软件开发中很普遍，我把这种现象叫作葫瓢现象——“按下葫芦，起了瓢”。
目前软件工程、敏捷开发解决这个问题比较彻底的办法，主要是尽早发现，通过频繁的回归测试（包括自动与人工），以及建立和维护高覆盖率的测试安全网。这样一旦由于某些人修改某些代码，导致引入新的 bugs 或破坏原有的系统功能，可以在第一时间尽早发现和排除。
要尽量减少葫瓢现象的发生，自动回归测试与高质量的测试集是必不可少的。
这个问题的根源在于需求。什么东西决定了你们开发的软件、代码有用还是无用？这是由用户决定的。符合了用户、干系人（Stakeholders）的需求，具有业务价值（business value）的代码就是有用的，反之则无用。
软件开发过程中经常会出现需求变更、代码修改，这在一定范围和程度内是正常的，因为复杂的系统开发必然都存在着一定的不确定型（Uncertainty），正是因为许多内容（包括需求和设计）的不确定，才需要我们去研究（research）、探索（explore）和试错（trial and error），这正是软件研发（R&D）的本义。所以，由人类思考活动为主要活动的软件开发本质上不是一个高度确定的制造、生产过程，绝大多数软件开发不是汽车、服装、皮鞋业的生产过程，也不是程序员打字，这些过程基本都是线性、确定的。
那么，怎样才能避免最后开发出来的代码成为无用的东西，尽量减少开发过程中的浪费？
现代软件工程与敏捷开发有一个最佳实践与答案，就是迭代开发（Iterative development），也叫迭代递增式开发（IID）。
把软件开发项目分解成若干时间片，例如 2 周为 1 个迭代。每个迭代（每 2 周或每个月）都要对开发中的软件进行全面的测试，最关键的是获得反馈（feedbacks）：要对当前的开发成果进行质量评审（review）和运行演示（demo），尤其要让软件的最终用户或用户代表对系统的需求和设计进行确认，给出评价和意见，以便开发团队在随后的开发过程中及时进行调整和优化。让软件的用户来回答你们开发的东西是有用还是无用，这才是根本、彻底的办法。如果是领导、决策者拍脑门的想法，通过迭代开发的评审、运行和演示，就能尽早发现，避免无效的需求。
这种现代的迭代开发模式比传统的瀑布模式风险要小很多，能最大程度上避免软件开发过程中的浪费和差错。
。。。0. tech lead，架构师必须写代码
1. 结对编程
2. 测试驱动开发
3. code review
4. 功能测试
5. 持续集成
6. 自动化测试
认真在项目中引入以上实践并思考为什么需要这些实践。
但是最重要的是，你需要一个“懂行”的领导或客户
1、关于需求变更。
开始写代码前，必须有需求文档，我建议这个文档由开发来写，需求的原始文档甚至可以不要，只要开发能懂就行。开发处于需求和测试之间，只有开发写的文档，三方才能都看的懂。这个文档不要被各种格式所困扰，目的只有一个，三方认同。
有了文档，还是不要动代码。必须有一个三方确认的过程，请大家不要遗漏测试，测试在一开始就介入，对项目进程有莫大的好处。确认不应该只是个观看文档的过程，对一些重要的功能点，最好三方一起碰头讨论确定，否则，就文本层面，各人的理解差别可能很大。（就我个人习惯，会把各个功能点的复杂重要程度，以A、B、C、D来编号区分，方便之后的交流）如果是项目型的产品，文档还必须由客户签字确认，客户签字的文档尤其注意UI的描述。
最后，必须规定一个需求变更的流程。需求变更的原因应该附在原文档后面（不要改原始文档），我们一般是通过论坛回帖的方式在处理，需求、开发和测试都必须签字确认。进入测试阶段后，应该有一个Dead Date，超过这天，即使是错的，也坚决不能修改。正常一个项目下来，有20%的需求变更是正常的。
当然，最麻烦的是领导拍脑袋。作为技术负责人，必须要敢于说不，领导敢半路加东西，你们就要敢疯狂加时间，多弄几次他们就知难而退了。我见过很多傻乎乎的程序员，领导一说什么，他们就说简单啊，分分钟，也不征求需求和测试的意见，就开始乱改一气。其实这样做领导会更不重视技术，更会乱来。
2、开发的内部配合
如果有了上述了流程和文档，在开发之前，各个程序员的分工和大概的工作安排应该已经出来了。精确到每个工作日应该不成问题，建议Leader都先做个这个任务安排，不精确到每天，有时候进度不好控制，特别是需要协同的地方。
团队不要太大，超过5个开发的团队，就一定要拆分，国内开发的Leader一般都承担着重要的开发任务，不可能有精力管理超过5个人的团队。条件允许的话，最好空出几个人掠阵，不要分配太多任务给他们，他们专门做代码Review。
代码Review是很重要的，建议每个团队每周都有一次集体的Review，其实不用准备什么，弄个投影仪，把大家正在开发的代码投影出来就可以。代码Review有一定的套路，我建议只为了一个目的：降低代码复杂度。“复杂度”是个可以量化的指标，有兴趣的朋友可以找一下相关书籍看看。
A改的代码影响了B，这种情况很难避免，但应该控制在比较小的范围内。如果某些人经常出这种事情，那就把他贬去做很独立简单的东西，比如报表。加强开发的自测，可以制定相应的绩效考核，比如交给测试的产品质量标准，不能主要流程走不通，不能出英文提示等等，这时候不能手软，说多了没用，钱才是硬道理。
最近流行结对编程什么的，在国内应该实行不下去的，但是可以结对Review，弄些连带责任的绩效考核。至于单元测试，对代码的架构要求很高，做不动就算了。
3、关于测试
测试在国内软件行业的地位低下，这非常糟糕。建议一个测试团队起码能有个把两个白盒测试的，有个把两个精通各种测试工具的，有个把两个能做效率测试的。有些团队甚至连专职的测试都没有，这就非常堪忧了。
建议开发阶段，测试就要介入，完成一个功能能用，就应该马上交给测试，但开发阶段，主动权和话语权还在开发这边。进入测试阶段后，所有功能应该全部完成，这里应该也有个明确的日期，测试阶段应该由测试完全掌握主动权，有些错误开发可能会认为是测试吹毛求疵，那也必须尊重测试的工作。
其实不少错误开发改不动，或者不能重现，或者得不偿失，这些类型的错误可以延期不改，但也应该有一个严格的流程，起码不应该是随便一个开发人员都可以跟测试说什么什么不改。
想到哪里写到哪里，写不动了，也没有整理一下，见笑。好好学学软件工程，你这属于不合格的作坊式开发强烈推荐邹欣的软件工程书，很通俗易懂，看完你就没这些疑问了。你采用自底向上的开发就不会有垃圾代码了没有不会谢的花
没有不会退的浪
没有不会暗的光
你在烦恼什么啊
没有不会淡的疤
没有不会好的伤
没有不会停下来的绝望
你在犹豫什么啊
题主，来这里看看：
1 需求分析-软件产品的利益相关者
2 你的项目延期过吗
3 代码复审看什么
4 阿超的故事-第一辑
以上内容摘自 @李旭 的回答中推荐邹欣的软件工程书：构建之法，此为多看版。
我们先来看看这位朋友的体会：
在微软实习学到感触最深的事情是什么？ - 微软（Microsoft）
这位微软实习生颇有感触的事情是：
微软对coding的要求很高，入职第一天，实习生要首先阅读coding guideline，里面详细描述了coding要遵守的规范，从变量命名，tab几个空格，到最后code check in之前的review都很清楚。 我们开发的网站因为是内部使用的，所以没有这么严格遵守要求，但mentor一再嘱咐coding的要求，复用，层次化设计，类和接口的设计，都要认真细致的思考后进行，和上学时随便写有太大的区别。
现在，国内一些高校中有远见的老师已经开始采用《构建之法》作为教材，来看看广州商学院这两位大三同学的阅读笔记：《构建之法》的笔记
在读此书之前，我一直以为当一个团队确定了负责一个项目之后，他们的成员不会再有所修改，会对所负责的项目负责到底。但实际上，软件团队是会流动的。为什么要有人员的流动呢？是出现了现有团队解决不了的技术困难，需要新技术新知识的支持，还是现有团队身担多职，需要人手帮忙？另外，不止是软件程序会有bug，团队也会有bug。处理好bug是创造“足够好”的软件的基础，但在校园学习过程中，我们常常会忽视bug，甚至把它留在最后处理。
在微软工作过的 @Andy Pan ，先后也在腾讯微信产品部门及如今相当hot的大疆公司担任团队leader，他读了《构建之法》，写了这样的书评：100倍速度前的慢动作 (评论: 构建之法)
什么意思呢？他说——
看了邹老师的《构建之法》，往日在微软学习的扎实的方法学一幕一幕回来，里面也加入了很多邹老师在研发互联网产品对微软传统方法的反思和互联网方法的实战经验。我把几本书送给微信的几位核心开发，反馈也是，如果新同事有这样扎实的训练，更能够适应微信高灵活性的开发。
和曾经微软的一名开发同事现在小米公司的一名核心员工聊天，我问他，你在微软和小米都做了开发，两者的区别是什么？回答：把微软方法的速度提高一百倍就是小米的方法。
因此，对于学徒，在实战之前，先认真学习拆解动作，免得将来到实战场基础不行速度上不去被淘汰，或者速度上去了基础不扎实打成王八拳误伤了自己。
英雄所见略同。百度工程师牛尧在这篇题为相见恨晚-目前为止看过的最好的软件工程书籍 的书评中写道：
随着这本书及其授课模式在高校的推进，我相信再过 3-5 年，新生代的学生软件研发的整体水平一定会有大幅度提升。
按照这本书的模式训练新人和进行人才培养绝对可以事半功倍。若凑巧有位应聘的同学在大学经历过这样的授课模式，而且成绩优异，绝对值得直接收了，至少可以让你省掉半年的新人培养成本。
另推荐多篇来自不同IT公司的工程师或项目经理的书评_
水面下的冰山——读《构建之法》 (评论: 构建之法)/丁香园工程师
《构建之法》----迷你版的《代码大全》 (评论: 构建之法)/广州的一位工程师
构建软件工程的进阶之道 (评论: 构建之法)/清华同方资深项目经理
以独特的视角来看软件工程--读《构建之法：现代软件工程》/中兴通讯软件工程师
软件需要严肃对待，谨慎修改 (评论: 构建之法)/嵌入式开发工程师
===试读及更多介绍请参看这里。
邹欣在Build To Win - 构建之法 - 知乎专栏中说：
由鸡，猪，和鹦鹉组成的团队怎么赢？ 要创新，但创新有规律么？如何平衡种种矛盾，走出一条理性的，不要拼命加班的道路，还能得到合适的回报? 这是我看到的所有软件工程教科书没有讲的，也是我想在《构建之法》这本书里面探讨的。
我把这段话发给七牛的许式伟，他果然对《构建之法》产生了兴趣，因为他也不提倡靠加拼命加班才能做好项目和产品，但他们团队又尚未摆脱不得不经常加班的困境。
邹欣最近在广州致远电子做了一次讲座，讲座文字实录汇总在此：
邹欣讲座：现代软件工程--构建之法
下面是去现场听过讲座的 @刘鑫 听了讲座之后写的专栏：
邹欣老师《构建之法》讲座广州（一）人才选拔 - 前路迢迢 - 知乎专栏
邹欣老师《构建之法》广州讲座（二）前夜 - 前路迢迢 - 知乎专栏
邹欣老师《构建之法》广州讲座（三）启动问题 - 前路迢迢 - 知乎专栏我对你提出的问题看法如下：
1、需求的问题不能光看表象，更不能听风就是雨，比方用户说要一个报表，那你至少要问清楚用户要这报表干什么？用户所关注的数据是哪些？如果这些都不清楚的话，那不是用户说报表太简单不实用，就是说报表太复杂操作不方便。在需求的收集中，如果涉及到专业的行业知识，则更需要请相关专业人士做好业务的指点，这点非常重要，因为这往往会影响到系统与系统的交互或后期功能的扩展。另外，需求必须经过严格的评审，因为很多研发人员认为很有用的功能，其实用户根本不用或极少使用，你所说的无用的代码堆砌应该就是类似这种情况。
2、关于开发的设计，我的建议是要极简，什么叫极简，就是以满足需求为根本目标，切忌过度设计和闭门造车，在设计过程中不要受到市场或同行的影响，因为需求是无止境的，如果需求的基线已经确认，那原则上应该尽快按需求定义出具产品原型请用户试用，尽快体现出自己产品的亮点和优势以引导客户，根据客户的意户和实际的情况，进行分析后再有计划的优化和完善产品。所谓的改改改，最大的问题是公司的开发设计及市场人员的思维局限。打个简单的比方，当年诺基亚盛行的时候，哪个手机制造商能按用户的需求设计出苹果手机？软件设计中有一个重要目标是如何创新和体现产品优势，要从服从客服变为引导客户，进而引导市场。在软件产品领域，要么你跟着别人的产品改改改，要么别人跟着你的产品改改改。当然这一点对于销售人员、实施人员的要求会比较高。
3、关于开发过程中程序员互改代码的问题，可以考虑每周进行组内人员的REVIEW，一个小组的人数建议在4到5人左右，负责1至2个产品的更新维护和一个新产品的开发。但代码的REVIEW受到参与人员编程水平及个人喜好、工作态度、情绪等主观因素的影响，所以代码REVIEW要有，但必要的测试也要做，数据的度量和收集更是必不可少，对于代码质量一直没有提高的人员，要考虑将其调至一个更适合他的技术或非技术岗位。另外，如果项目不是很庞大的话，尽量划分好模块或功能界线，尽量避免程序员之间相互修改代码的情况出现。
4、各项工作的组合及配合，关键在于是否有合适且明确的流程及审核，还有必须做好过程改进，比如某产品在需求阶段，一开始需求及设计人员的思路是明确的，产品的理念也是明确的，但等销售人员参与进来后，一会说张三的产品怎么好，一会说李四的产品怎么好。但是销售人员往往忽略了一个问题，就是张三或李四的产品是否解决了用户的问题，用户在使用这些产品时是否有不适的地方，或者说我们的产品能否能超越当前市场上的产品，这才是产品设计应该关注的点。一个手机制造商抄苹果抄的再象，也是不可能超越苹果的。所以上述的案例就是典型的非设计需求人员引导开发的案例。所以各项工作的组合及协作，在每个阶段都要明确参与的人员是否合适，排除不必要的干扰，由适合的人做适合的事，要抓好评审工作，简单点说，抓头抓尾，中间卡里程碑。
3.在开发或者修改更新的时候总会遇到这样的问题，A修改的东西吧B的给改啦，或者很久之后A改的东西影响到了系统的其他功能，怎么避免这些问题；
这种现象在日常的软件开发中很普遍，我把这种现象叫作葫瓢现象——“按下葫芦，起了瓢”。
目前软件工程、敏捷开发解决这个问题比较彻底的办法，主要是尽早发现，通过频繁的回归测试（包括自动与人工），以及建立和维护高覆盖率的测试安全网。这样一旦由于某些人修改某些代码，导致引入新的 bugs 或破坏原有的系统功能，可以在第一时间尽早发现和排除。
要尽量减少葫瓢现象的发生，自动回归测试与高质量的测试集是必不可少的。
1.软件开发过程中总有时候是东西开发了再改，有的是上面的拍脑门的想法，怎么避免如此的问题，最后开发的一堆东西都成了无用的代码堆积；
这个问题的根源在于需求。什么东西决定了你们开发的软件、代码有用还是无用？这是由用户决定的。符合了用户、干系人（Stakeholders）的需求，具有业务价值（business value）的代码就是有用的，反之则无用。
软件开发过程中经常会出现需求变更、代码修改，这在一定范围和程度内是正常的，因为复杂的系统开发必然都存在着一定的不确定型（Uncertainty），正是因为许多内容（包括需求和设计）的不确定，才需要我们去研究（research）、探索（explore）和试错（trial and error），这正是软件研发（R&D）的本义。所以，由人类思考活动为主要活动的软件开发本质上不是一个高度确定的制造、生产过程，绝大多数软件开发不是汽车、服装、皮鞋业的生产过程，也不是程序员打字，这些过程基本都是线性、确定的。
那么，怎样才能避免最后开发出来的代码成为无用的东西，尽量减少开发过程中的浪费？
现代软件工程与敏捷开发有一个最佳实践与答案，就是迭代开发（Iterative development），也叫迭代递增式开发（IID）。
把软件开发项目分解成若干时间片，例如 2 周为 1 个迭代。每个迭代（每 2 周或每个月）都要对开发中的软件进行全面的测试，最关键的是获得反馈（feedbacks）：要对当前的开发成果进行质量评审（review）和运行演示（demo），尤其要让软件的最终用户或用户代表对系统的需求和设计进行确认，给出评价和意见，以便开发团队在随后的开发过程中及时进行调整和优化。让软件的用户来回答你们开发的东西是有用还是无用，这才是根本、彻底的办法。如果是领导、决策者拍脑门的想法，通过迭代开发的评审、运行和演示，就能尽早发现，避免无效的需求。
这种现代的迭代开发模式比传统的瀑布模式风险要小很多，能最大程度上避免软件开发过程中的浪费和差错。
。。。0. tech lead，架构师必须写代码
1. 结对编程
2. 测试驱动开发
3. code review
4. 功能测试
5. 持续集成
6. 自动化测试
认真在项目中引入以上实践并思考为什么需要这些实践。
但是最重要的是，你需要一个“懂行”的领导或客户
责任编辑：
