“两打程序员，3年时间，4732个bugs，和对非凡软件的不懈追求”
《梦断代码》这本书，是我十几年前看的，一口气读完。当时我还在Cisco（思科）工作，感觉研发团队犯过的错误，在这本书中基本都能见到。
当年Lotus 1-2-3的设计者Mitchell Kapor，离开Lotus后成立了开源应用基金会(OSAF)，招募了一批很牛的程序员，开发号称革命性的下一代个人信息管理系统－－Chandler。这个团队似乎不缺钱、不缺技术、不缺经验，但偏偏不能发布一款看似简单的软件。6年过去了，Chandler 勉强挣扎着发布了0.7版，花掉几百万美元，但最终还是失败了，梦断代码。
在长达6年的马拉松里面，犯了一系列的错误，导致本来很有希望的项目半死不活。例如，Chandler项目成员决定用P2P架构来共享日历，但没有全力设计相关算法或协议，而是花大量时间去讨论Chandler的界面，这一拖就是几个月，最后P2P架构被彻底放弃，这是极大的浪费。像这种做了，然后被推翻了，在软件研发中也司空见惯。
上一篇讨论了 软件研发效能的负面清单：哪项是头号敌人？今天，讨论软件研发效能的另一面，即软件效能的反面，造成软件效能低下的 “浪费”。浪费可以分为：
-
直接浪费：不需要的开发成本或直接能感受到的浪费，如（没人使用的代码；被注释掉的代码，从未被使用过的功能、过度测试等；
-
间接浪费：不是直接能看到的开发成本，如低劣的质量、代码复杂度、沟通效率低等带来的额外成本。
这里不管它是直接成本，还是间接成本，不看它产生的原因，而是看它产生的结果，我把它总结为十大浪费。
第10大浪费：做的工作没有及时发挥效益
例如，写完的代码没有及时提交到代码库中去构建，还在开发人员本地机器中；通过测试的功能还没有交付给用户用，相当于在公司的库存中，没有产生效益。
第9大浪费：不同角色或不同任务之间的切换
例如，一个人参与多个项目，需要在不同的任务间切换，熟悉过多的业务和项目背景，经常切换思维、切换虚拟的工作空间，会造成比较多的时间浪费。
第8大浪费：软件中不必要的交接
软件中任务的交接，自然会增加学习成本，增加了沟通的成本，虽然在日常软件研发中不可避免存在交接，但不必要的交接或过度的交接，都会带来浪费，例如：
-
人员流动率比较大（如高于20%），老人和新人的工作交接
-
开发人员和测试人员间的交接，如开发、测试是两个相对独立的团队；
-
软件从开发到部署的交接（如果实施有效的DevOps，这种成本就很低）
第7大浪费：过度的工作（超出范围）
因为缺乏有效的流程、文档和一致性要求等，工作中没有准确了解项目或任务的范围，做了范围之外的工作，或者不能做到恰到好处，包括过度管理、过度测试、写了过多的文档、过度沟通（太多的会议）等。
第6大浪费：等待
许多人等待其他人的工作，例如团队的沟通协作不够主动，等待其他人找上门；开发测试配合不默契，测试等待开发提交新的版本；各个环节衔接不好，中间都会有等待。即使是一个团队或一项工作内都有等待，例如没做到持续测试，中间会有等待。有时测试环境没准备好，无法做测试，也会有等待。
第5大浪费：一而再再而三地重复犯错
没有做根因分析，头痛医头、脚痛医脚。团队中有些人不犯了，但另一些人再犯；某些团队不犯了，但其它团队再犯；犯的错误可能各种各样，包括糟糕的计划、错误的文档版本等。
第4大浪费：重复造轮子
市面上已有开源工具或成熟的商业工具，不是直接拿来用，或直接购买工具等，而是自己开发。
第3大浪费：返工
由于缺乏统一规范、系统复杂、人员能力弱，导致低劣的质量、产生很多缺陷，造成重新设计、重新写代码，都是返工。过度的代码重构、回归测试等都归为返工带来的浪费。
第2大浪费：无用的功能和代码
无用的功能和代码，类似“生产过剩”，根据一些数据统计的结果，在现有的软件应用程序中，多达2/3功能几乎或从未被使用过。包括没人使用的代码、被注释掉的代码等。
第1大浪费：整个产品方向性错误
对用户需求、业务理解的方向性错误，整个产品上线后失败，没人用。
参考：
软件研发的头号敌人是谁？
欢迎点击 问卷系统 参加问卷调查，非常感谢