精益软件开发的七种浪费

取自Shigeo Shingo的丰田精益制造。与制造业进行对比,是因为比起想象一个软件,我们更容易想象制造一辆汽车。

制造 软件开发
在制品库存 部分完成的工作
过度生产 额外功能
额外的过程 重复学习和手工动作
运输 任务交接
移动 人员任务切换
等待 延迟
缺陷 缺陷
  1. 部分完成的工作。就像一辆组装了一半的车,还缺个轮子,它是无法上路使用的。借助自动化测试的保护,建立能够容易和安全地修改的软件。这样就能灵活应对变化,及时生产。不用在4S店里停着很多车。
  2. 额外功能。做很多没人用的镀金功能,求大求全。
  3. 重复学习。不了解之前的历史,就总是在重复地以前的步骤,于是有了软件考古学。明明可以一步完成甚至自动化手段,非得靠人工来做,或步骤繁琐。明明一个团队公约可以让大家达成一致理解,却一次次犯低级错误。
  4. 交接。只给一本手册和一部车,别人是学不会开车的,因为很多隐性知识并没有在文档中体现。每次交接都丢失了一些隐形知识,积少成多。2次交接后还剩25%,5次交接后还剩3%。瀑布模式强制了这种交接。比如开发把工作移交给运维,每个人都对整体缺乏责任感。
  5. 人员任务切换。一种是个人的多任务切换,要不断要记住同时开展的各个事项,而且每件事的完成时间都拉长了。另一种是人员不稳定,经常被调来调去,团队没有机会磨合达到高效状态。
  6. 延迟。开发人员每15分钟就要做一次重要决定,你无法在文档中找到所有的必要信息。如果程序员不理解代码,基本功缺失,决策就会延迟。另外,不同团队的协作也会导致时间在“找人”中消逝。不合理的依赖与耦合关系也造成延迟。
  7. 缺陷。缺陷意味着返工,甚至价值损失。我们的目标是预防大于追踪缺陷,这需要纪律性,才能在短的时间段中争取一次性地做对。用自动化测试和面对面沟通来代替需求规格书吧,用持续集成阻止“破窗”效应吧。

在精益思想里有 Muri(过载), Mura(波动),Muda(浪费)的说法。精益不只是讲浪费的事情。对于智力型工作,比如IT开发,想要顺畅流动,除了考虑消除7大浪费,要考虑系统过载的比如996加班带来的疲劳和响应力下降;另一方面,别幻想将智力型工作完全地拆分成同样粒度的任务来减少波动,而是要从规范性(代码规范、界面风格、团队公约、DoD、CI纪律等)来减少波动,少出意外,防呆,从而提高规范性。

“Implementing Lean Software Development: From Concept to Cash”, by Mary and Tom Poppendieck


觉得本文有帮助,长按二维码进行微信打赏