写点什么

M 三兄弟-精益三人组

2008 年 3 月 10 日

关于软件开发中应用精益原则的讨论,大部分集中在识别和消除浪费(浪费在日语中叫作:muda)。同样,精益思考的目标是消除过重的负担(过重的负担在日语中叫作:muri)和不必要的变化(不必要的变化在日语中叫作:mura)。Muda,muri 和 mura 合称为“M三兄弟”。它们三个在一起就成了不谐调的组合。只有消除了这“M 三兄弟”,才能创造一个可持续的精益过程。本文讨论了这“三兄弟”的关系,并认为对于软件开发组织来说,要建立一个精益过程,第一步要做的事情就是消除额外的负担。

浪费

在精益思考(lean thinking)中,浪费被定义为:所有以客户的角度看来不增加价值并且可以移除的活动。例如,生产过剩、过渡加工、在制品,或者库存、缺陷、任务易手和任务切换、等待,以及没有用到的员工创造力。

从客户的角度来看,能增加价值的活动才能让产品品质得到提高。判断是否为增值活动的好办法就是问自己这样一个问题,“假如我是客户,我愿意为这个活动付费吗?”如果回答为“是”,那它就可能是个增值活动。例如,发现和理解客户需求,并写出代码。另外,正如后来 Allen C. Ward 所指出的那样,使用原型法来学习相关知识以便开发软件系统,这样类似的活动也属于增值活动。任何不创造价值而当前又无法消除的活动被叫做“非增值”活动。例如配置管理和项目计划活动。

敏捷宣言中提到“可工作的软件胜过全面的文档”,也就是强调整增值活动在软件开发中的重要性。通过消除浪费,我们可以更快更好地创造软件产品。

过重的负担

那么首先将关注点放在发现和消除浪费上面,有什么不对的呢?即使大部分传统开发组织从事的都是没有增加什么价值的活动,都是浪费;但是要想以精益的方式工作,正确的方法不是先对付浪费,而是要首先应对另外一个痼疾:过重的负担。只要大家疯狂加班,只要项目和团队有被大量工作压垮的可能,那么仅仅消除浪费就没有什么效果了。除非我们将工作量限定在组织能力所及范围之内,否则浪费就可能会悄悄返回。假设你正试着消灭缺陷,可项目却还是在重负之下,那么质量问题还是会重现,因为项目成员仍会感到压力过大以及过度操劳。事实上,过重的负担是在制品、等待和推迟、任务切换和缺陷等浪费的主要来源。

将需求限制在工作能力范围之内,正是 Scrum 和极限编程要做的事。让团队自己为一个迭代指定可行的工作量,过重的负担就会被制止,从而并有系统地避免它的发生。这样就达到了一个稳定的步伐。另外,Scrum 和 XP 建立了“拉”式过程和稳定的节奏,团队成员实际上就是从产品 backlog 上以“拉”的方式来获取需求,并以一种有规律的基准来将这些需求转化为产品的增量。

这种“拉”式过程的优点之一就是:除了避免负担过重,它还会使浪费和其它问题暴露出来。随着过多库存的消失,问题就会很快暴露出来。Scrum 意识到了识别和消除问题和障碍的重要性。它的每日 Scrum 会议就是识别问题的一种机制。

多变性

具有稳定节奏的“拉”式过程使得不必要的变数可视化,例如在迭代计划会议上,团队发现需求的大小和粒度不同,或者使用了多种不同的构建脚本。不必要变数的其它例子还包括:使用不同的开发工具,应用开发实践(如测试先行及重构)时的不一致性,以及不遵守编码标准等等。这类变数产生了诸如有缺陷的软件、过度加工以及返工等浪费。而规范和标准则消除了这些变数。

但是,并不是所有的变数在软件开发中都是坏事!例如,产品 backlog 中以不同的详细程度来表述需求,可以避免生产过剩, 过度加工和返工。通过创建原型来探索不同的技术和设计选择是一种必要的变化形式,这样可以获得相关的知识,以便做出正确的架构和技术决策。需要注意的是:要尽早进行有计划的组织试验,而不要孤注一掷于可能未加证实的设计理念,后者往往会导致后来重写软件。

总结

为了建立一个精益过程,必须从根本上改变传统的开发体系,从而建立一个正确的过程。对于软件开发组织来说,最好通过使用有节奏的“拉”式过程,以创建和 Scrum 和 XP 同样的过程。在日语中,这种根本上的改进叫做 **“改革(kaikaku)”** 。一旦建立了这种新的工作方法,浪费和变数肯定会被系统化地清除。因此,这种过程要逐步不断改进,在日语中就是所谓的“改进(kaizen)”。有规律的回顾会议会有益于反思和持续改进。总而言之,要建立正确过程首先就要减负,然后授权并鼓励团队义无反顾地消除浪费和不必要的变数。

Literature

  • Jeffrey K Liker: The Toyota Way. McGraw-Hill. 2003.
  • James M. Morgan, Jeffrey K. Liker: The Toyota Product Development System: Integrating People, Process and Technology. Productivity Press. 2006.
  • Mary and Tom Poppendieck: Implementing Lean Software Development: From Concept to Cash. Addison-Wesley. 2006.
  • Donald G. Reinertsen: Managing the Design Factory. A Product Developer’s Toolkit. Free Press. 1997.
  • Allen C. Ward: Lean Product and Process Development. Lean Enterprise Institute. 2007.
  • James P. Womack, Daniel T. Jones: Lean Thinking. Touchstone Books. 1996.

作者简介

Roman Pichler , 是一名独立咨询师及教练。Roman 的客户认为他具备丰富且不同的经验,能够帮助刚起步的创业公司,乃至很大的全球性企业实施精益思考和 Scrum。他还是《Scrum - Agiles Projektmanagement richtig einsetzen(dpunkt 2007)》一书的作者。

查看英文原文: The Three M’s - The Lean Triad

2008 年 3 月 10 日 10:511139
用户头像

发布了 100 篇内容, 共 16.7 次阅读, 收获喜欢 2 次。

关注

评论

发布
暂无评论
发现更多内容

CAP原理

知行合一

架構師訓練營 week6 作業

ilake

学习笔记:架构师训练营-第六周

四夕晖

2020.10.26-2020.11.01 学习总结

icydolphin

极客大学架构师训练营

极客 - 架构设计指导原则

jorden wang

架构设计原则

架构师课程第二周作业

文江

week2-作业1

Mr_No爱学习

LeetCode题解:90. 子集 II,回溯+哈希表去重,JavaScript,详细注释

Lee Chen

算法 LeetCode 前端进阶训练营

架构师训练营第六周作业

四夕晖

week2-作业

Mr_No爱学习

第二周作业

Hjh

架构师训练营第六周作业

xs-geek

极客大学架构师训练营

Architecture Phase1 Week6:HomeWork

phylony-lu

极客大学架构师训练营

第2周作业

Rocky·Chen

初始化文章

Yuchen

自我独白

架构师训练营 1 期 -- 第六周笔记

曾彪彪

极客大学架构师训练营

架构师训练营第六周学习总结

Gosling

极客大学架构师训练营

架构师训练营 Week6 - 课后作业

极客大学架构师训练营

第六周作业

Geek_ce484f

极客大学架构师训练营

Architecture Phase1 Week6:Summarize

phylony-lu

极客大学架构师训练营

第二周-学习总结

Geek_0b0f83

极客大学架构师训练营

第六周作业总结

Geek_ce484f

极客大学架构师训练营

架构师训练营第二周总结

Sandman

第二周作业

jingx

第六周作业

Meow

第六周作业1

Yangjing

极客大学架构师训练营

2周 作业

水浴清风

【架构师训练营第 2 期】第 2 周作业

知致

【第六周】课后作业

云龙

极客时间-设计原则

学习总结 -week2

Mr_No爱学习

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

M三兄弟-精益三人组-InfoQ