软件开发过程的浪费.pdfVIP

第一节 软件开发过程的浪费 我们把没有对最终客户产生价值的活动都称为浪费，有些间接产生价值的活动则不在此 列。 和汽车工业一样，我们将软件开发过程中的浪费也分为三类：人工浪费(MUDA)、精神 折磨(MURA)和勉为其难(MURI) 。 人工的浪费是指对人工上的浪费，生产出来没有价值的东西，或者用了几倍的人工才生 产了一倍的价值。 精神折磨是指降低团队士气、分散团队凝聚力、或者在团队成员精神状态不佳的时候工 作。这都导致团队的生产力下降，效率降低，甚至产生致命错误。 勉为其难是指去做那些并不胜任、不擅长的工作。这导致产生错误和埋入隐患。 重复劳动、等待、返工、破坏、无效果劳动和低效率劳动都会造成浪费。如何识别这些 浪费并且消除它们将是软件企业在竞争中获取竞争优势的一个重要武器。 CRUD 中的浪费 很多系统中都有Create/Retrieve/Update/Delete 功能。比如，一个销售系统中的产品类 型维护功能就包括了产品类型检索，产品类型新增，产品类型编辑和产品类型删除功能。而 同样的产品的维护功能也有检索、新增、编辑和删除四个，类似的还有品牌维护、分组管理 等。 戴维的组在制作这个功能的时候沿用了用了十多年的经验，他安排了四个人，甲来书写 一个范例，乙丙丁仿写，这样所花费的时间是一个例子的时间加上三份仿写的时间。他认为 从时间长度和工时消耗上都要比一个人写四个节省。于是他们四个人写成了这样的一组功能。 但是，在这个功能完成不久，南希就要求他们增加分页功能。戴维召集了这四个人开 了个短暂的会议，说明了客户的要求，并提出了统一的修改要求，每个人都要在自己的方法 上增加一个int pageNo 参数。于是四个人分头去改写自己的函数。 测试还没有开始呢，南希再次要求变更，增加每页显示行数功能。 戴维和往常一样，再次召集短暂会议，告诉大家应该增加一个int linePerPage 参数， 然后大家又去修改了。这次增加了参数后的形式变成了这样， 同样的要求在杰克身上也发生过，杰克并没有要求用四个人来做一组类似的功能，他 只安排了一个人，汤姆。汤姆将这四个功能写成如下形式。 其中各个子类的retrieve 方法只是将自身的名称和参数传入BaseAction 中的retrieve 方 法。 当需求变更的时候汤姆增加了一个类，用来存放翻页相关的功能参数。 并且，修改的时候只需要修改BaseAction 就很快达到了南希的要求。 通过对比，就不难发现，杰克组花费的总成本远远低于戴维组。 戴维组用了四个人，每次变更的时候都需要召开会议统一认识，而杰克组只用了一个人， 变更的时候不需要说服很多人。——要知道对于变更多数人是持抵触态度的。而且，如果沟 通不畅，将会导致四个人做出四种结果。戴维组要在这件事情上花额外的沟通成本。 戴维组在修改的时候需要修改四份，每一份都要单独进行测试，而杰克组只修改了一份， 只要测试一份即可。而且对于测试用例的修改也相对简单得多。