《二十几个程序员，3年，4732个bug，对非凡软件的不懈追求》《梦断代码》这本书是我十多年前写的，读过，一口气读完。我当时还在思科（Cisco）工作，感觉研发团队犯的错误在这本书上基本都能看出来。Lotus1-2-3的设计者MitchellKapor在离开Lotus后创立了开源应用基金会（OSAF），并招募了一批优秀的程序员来开发所谓革命性的下一代个人信息管理系统——钱德勒。这个团队看似不缺钱、不缺技术、不缺经验，却无法发布一款看似简单的软件。六年后，Chandler艰难地发布了0.7版本，花费了数百万美元，但最终还是失败了，梦想着破解密码。6年的马拉松，一连串的失误，导致原本大有可为的项目半死不活。例如，Chandler项目的成员决定使用P2P架构共享日历，但他们没有设计相关算法或协议，而是花了大量时间讨论Chandler接口。就这样拖了好几个月，最后彻底放弃了P2P架构。大浪费。在软件开发中做这样的事情然后被推翻是司空见惯的事情。上一篇文章讨论了软件开发效能的负面清单：谁是头号敌人？今天我们讨论软件研发效率的另一面，即软件效率的反面，造成软件效率低下的“浪费”。浪费可分为：直接浪费：不必要的开发成本或可以直接感受到的浪费，如（无人使用的代码；注释掉的代码、从未使用过的功能、过度测试等；间接浪费：不直接可见的开发成本，比如因为质量不好、代码复杂、沟通效率低等原因导致的额外成本，这里是直接成本还是间接成本，不是看它的成因，而是看它结果我把它总结为十大浪费第十种浪费：所做的工作没有及时带来收益，比如写好的代码没有及时提交到代码库进行建设，还处于开发者本机；通过测试的功能还没有交付给用户，相当于在公司的库存中，没有产生效益。第九种浪费：在不同角色或不同任务之间切换。参加多个项目需要在不同的任务之间切换，熟悉太多的业务和项目背景，频繁切换思维和切换虚拟工作空间会造成大量的时间浪费。第八种浪费：软件中不必要的交接软件中任务的交接，自然会增加学习和交流的成本。虽然交接在日常的软件开发中是不可避免的，但不必要的交接或过度的交接，都会带来浪费，例如：人员流失率比较大（比如高于20%），新老人员之间的工作交接，开发人员和测试人员的交接，比如开发和测试是两个相对独立的团队；移交部署（如果实施有效的DevOps成本低）第7种浪费：由于缺乏有效的流程、文档和一致性要求等，在没有准确理解项目或工作的情况下工作过多（超出范围）任务范围，做范围外的工作，或者做的不对，包括过度管理，过度测试，写太多文档，过度沟通（开会太多）等。第六大浪费：等待多人等待别人的工作，比如团队的沟通和合作不够积极，等着别人上门；开发和测试不配合默契，测试等待开发提交新版本；有等待。即使在一个团队或一个工作内部有等待，比如不做持续测试，中间也会有等待。有时候测试环境没有准备好，测试做不出来，就会有等待。第五大浪费：一错再错，不分析根源，头痛医头，脚痛医脚。团队中有的人不做，有的人又做了；有些团队不做，但有些团队又做了；第四大浪费：重新发明轮子市面上有开源工具或成熟的商业工具，不是直接使用，也不是直接购买工具等，而是自己开发。第三大浪费：返工由于没有统一的标准，系统复杂，人员能力薄弱，导致质量差，缺陷多，导致重新设计，重写代码，都是返工。过多的代码重构、回归测试等都归为返工造成的浪费。第二大浪费：无用的功能和代码无用的功能和代码，类似于“生产过剩”，根据一些统计结果，在现有的软件应用中，有多达2/3的功能几乎或从未使用过。这包括没有人使用的代码，被注释掉的代码等等。第一种浪费：整个产品的方向错了。用户需求和业务理解的方向是错误的。整个产品上线后就失效了，没人用。
