• 识别浪费与软件开发 - [Lean]

    2008-03-16

    识别浪费

    在参观Yazaki天津工厂(Toyota的供应商,应用丰田生产方式多年)的过程中,负责质量改进的工作人员对我们说,培养“发现浪费的眼光”是他们的重要技能。识别浪费是持续改善的重要一环。从现象上观察,浪费常常伴随着相似的表现,这些表现则可以帮助我们识别浪费。浪费的表现如下:

    • 库存

    生 产企业为避免供应不足建立库存,却同时增加了成本,减弱了企业对市场的敏感性,隐藏了企业内部各种各样的问题。在市场稍有风吹草动的时候,库存商品就变为 滞销品,同时还造成了供应不足的尴尬局面。广义上讲,库存还包括那些不可见的、还没有产生结果就已经停滞了的工作,它们表明价值流已经发生了停滞。库存在 我们的生活和工作中可谓无处不在,比如书架中不知道何时才会被翻阅的书、Jira上数不清的任务还有目前的高等教育体制等等。

    • 批量和排队

    批 量和排队的同时会有等待,会减弱价值流的流动性。有的银行规定在每月的固定几天内处理企业发放工资,此时批量和排队就产生了,由此引发的排队现象以及企业 和银行间周期性的工作负荷不均衡现象会带来浪费。在瀑布式开发中,工作在部门间以批量和排队的方式被传递,针对某一功能的工作在流向下一部门前要等很久。 这种现象配合文档的暗示作用和部门内考核标准的指导作用,会给上游部门造成一种工作已经完成的假象,最终导致下游部门得不到上游部门有力的支持,下游部门 的疑惑或新发现的知识也找不到合适的人反馈,只能自己做主了。

    • 不均衡和不平衡

    不 均衡常常伴随着波动、批量和排队的现象,会带来资源的闲置和过度利用交替出现的情况。年末电器促销是一种不均衡的情况,为准备促销,企业提前几个月加班生 产,资源过度利用,管理成本和次品率增加,库存成本增加。促销结束后,需求减少,库存成了滞销品,销售压力增加,生产进入淡季,生产资源未能充分利用。这 种由行业造成的销售周期并没有反应用户真实需求的变化(用户的需求是相对稳定的,并不会在年末激增),从企业角度看,这并不利于其利益的最大化和服务水平 的提高,从用户角度看,他们滞后或提前了消费时间,这可能导致购买了不合适的、甚至是多余的产品。

    在瀑布式软件开发中,整个过程被分为需求分析和设计等不同阶段,各部分工作被集中处理,而不是相对均衡地分布在整个过程中。真实需求的发现本是持续和渐进的,实现需求的各项活动也可以均衡分布在整个开发阶段。

    • 复杂和繁琐

    如果事情表现出异常复杂和繁琐的一面,很可能是出了什么问题。繁冗的文档和流程背后往往有保护局部和损害整体的影子。

    生 产一件产品过程中重复的加工步骤、重复的动作等等都增加了加工过程的复杂性,是浪费。但由于是生产有形的产品,这些浪费比较容易通过肉眼观察出来。软件则 不同,软件的开发过程和运行过程都不太容易观察,复杂和繁琐常常表现为难于应付的棘手问题,还有系统间复杂的交互过程、程序中重复的代码逻辑等等。有时复 杂性可能源于试图通过软件对异常复杂的业务逻辑进行自动化,这些业务逻辑中的复杂性对客户很可能是没有价值甚至是有反作用的,这种情况并不鲜见。

    • 僵化

    僵 化表现为对需求变化反应迟钝。这是一种障碍,它使企业无法满足客户的真实需求,这种障碍囤积着浪费,但其是不需要发生额外成本就能克服的。瀑布式开发过程 中,等待需求变化的常常是繁琐的需求变更流程,繁琐到了连客户自己都不愿提出发现的需求。这种对所发现的更有价值知识的僵化态度不断提醒着我们,它背后有 浪费。它使得软件与实际需求拉开了距离,反过来还鼓励客户在一开始绞尽脑汁将需要和不需要的东西一并提出需求来,为客户自己和项目组埋下浪费的种子。

    从上面的各种表现中我们不难看出量产后遗症的影子。

    总之,未完成的工作都涉嫌浪费,所谓“未完成的工作”就是指已经开始了的、但尚未交付给客户的工作,更进一步讲,是所有尚未给客户创造价值的工作。上面所有的现象背后都是一种阻碍工作迅速完成(阻碍价值迅速流动)的结构或力量。有的表现为工作的停滞,有的表现为加入一些多余的内容,拖延了工作的进展。

    考虑软件开发过程,狭义地讲,未完成的工作就是还没有Check In的代码。广义上讲,所有尚未给客户创造价值的工作,这包括在开发功能牵涉到的分析、设计、编码和测试等工作,包括某一严重Bug所对应功能的全部分析、设计、编码和测试等工作,还有为维护Jira上任务列表所进行了的各项工作等等。它们都是未完成的工作,都是潜在的浪费,认识这一点的价值在于鼓励我们积极面对市场的变化,采用能够让价值迅速流动起来的的交付方式,并努力清除妨碍工作迅速完成的一切障碍。

    敏 捷团队中的成员,强烈希望迅速看到自己的工作成果,看到下一环节乃至最终用户的反馈。团队中每一个角色的每一项工作都被最终用户的一个明确需求牵引着,为 了不让这个需求目标被淡忘,避免由于目标含糊不清而产生的浪费,敏捷团队通过短期迭代和频繁交付努力压缩着未完成的工作。

    精益或敏捷就是将未完成的工作(浪费)减少到最小的观念和行为。

    精益的5个原则(步骤)给了我们一个清晰的、循序渐进的思路来压缩未完成的工作。具体到软件开发领域,众多敏捷实践则组成了一个实用的工具箱,帮助解决在履行精益原则的过程中暴露出来的具体问题。


    收藏到:Del.icio.us