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