敏捷软件开发知识体系 ADBOK编写组授权发布
本文节选自《敏捷软件开发知识体系》一书，该书已授权****正版发布，PDF下载链接请见文末。如需转载请联系中国敏捷软件开发联盟ADBOK编写组，感谢敏捷领域专家张克强老师（@zhangmike）全力帮助****拿到该书电子版授权。
敏捷开发方法框架之与精益相结合
定义和特性说明
精益思想起源于丰田公司以“低成本、零缺陷、高质量和人性化生产”为特色的丰田生产系统（Toyota Production System, TPS），从90年代开始被很广泛的研究，其目标是了解客户的价值观，然后充分利用聪明、具有创造力的员工的时间和精力，以较少的努力提供更多的价值，即尽量避免复杂的东西。Mary Poppendieck和Tom Poppendieck根据对丰田精益的理解将精益引入软件开发领域，在敏捷软件开发社区中提出了精益软件开发的理念，通过在敏捷开发会议上的几次演讲，已经形成了被敏捷开发社区所广泛接受的概念。
精益的概念与原则
在精益制造或精益产品中，“精益”被定义为：
“一种系统的方式，通过不断跟进用户对产品的需求，持续的改进来定位和消除不必要的损耗” （精益制造指南，www.leanmanufacturingguide.com/）。在精益生产中，“精益”则体现为一种以最大限度地减少企业生产所占用的资源和降低企业管理和运营成本为主要目标的生产方式，同时它又是一种理念、一种文化。
精益思想有六个原则，他们更像是六个步骤，通过不断循环的过程最终将用户价值带入系统中，甄选排除流程中所有可能的浪费。这六个原则分别是：
- 价值
明确客户所期望产品或服务应提供的价值。以实现此价值为目的, 审视整个过程中的所有活动，同时帮助识别其中的浪费。
- 价值流图
针对一件产品、一项功能或服务，按时间顺序识别出为实现其价值而进行的所有活动，并确定出其中哪些是有价值的，哪些是浪费。
- 流动
消除价值流中的浪费，让有价值的活动一个接一个地流动起来。
- 拉动
确定价值流何时开始流动，因何流动。价值流应由用户的实际需求所拉动。
- 尊重他人
很多传统的开发起源于早期的制造业流程，将具体的工作定义和划分得很清楚，并且只需相对低级的技能要求就可以完成。而敏捷方法则更依赖于流程中个人的能力，并非开始时就定义得非常细致，而是通过他们细化到具体的项目、任务和业务环境中去。这就是为什么尊重他人在敏捷环境中是如此的重要的原因。
- 完美化
由于浪费是被不断发现和具化的，所以价值流中浪费的步骤不可能通过一次改善就得以彻底消除。完美化就是追求在实现客户价值的过程中引入最少的浪费，也即通过更精简的步骤、更短的时间和更少的必需信息来实现客户价值。当实现了一个阶段的目标后，根据当前的价值流状况设定一个新的目标，重新开始流动和拉动的过程，发现和消除更多的浪费，然后不断地持续这一改进过程。
敏捷开发正是借鉴于这样的精益制造，并将其原则应用于软件开发的过程之中。它所引入的，简单说来：就是检查软件开发过程中的所有步骤，并对每个步骤在整个过程中是否含有价值作出决定性的判断，从而做出对于客户来说是否真正有价值的判断。
图1 精益六原则
精益与敏捷的相互关系
敏捷和精益的相互关系如下图所示。
图2 精益与敏捷的关系
可以总结为以下几点：
（1）面向过程
精益软件开发相对于绝大多数敏捷方法都要更加的强调面向过程。
- 精益软件开发源于精益制造方法。Mary和Tom Poppendiek花费大量精力，将精益制造方法的原则转换至精益软件开发上来。由于精益制造十分强调面向过程——精益软件开发同样强调面向过程，但它更多是一系列的适用于其他开发过程（如敏捷、迭代、传统方法）的原则。它并没有直接定义流程，但它所强调迭代和适应性的改变流程是软件开发环境中所需要的。
- 传统的方式注重制度而非人的作用，敏捷宣言和原则在某种程度上来说是对严格定义流程方式如瀑布方式的一种变革。宣言中有一句话“个体和交互重于流程和工具”要更强调面向人而不是机械化的流程。现在的敏捷方法，如Scrum，意识到需要规范一些流程，然而相对于严格定义、机械化的流程，这种流程更依赖于拥有熟练技能和判断能力的团队成员。
（2）共通原则
如今的敏捷方法和精益软件开发方法都有很多共同的原则，例如：
- 以客户价值为重点
- 尊重他人并且赋予其相应的权利
- 强调不断地学习和持续改进
- 迭代开发的方式
- 设计到项目的质量和完整性
- 尽量在后期作出决定
- 减少浪费
（3）区别
如今的敏捷方法和精益软件开发的区别更多的是在实现方式，而并非在底层的原则上。因为他们并没有一开始就完全规定好做法，而是提供了很多灵活性，所以在实现方式上必然有很多显著的差别，但是在底层原则的差异则很少。以下几个例子足以说明他们之间的不同：
- 敏捷方法如Scrum，会在项目中通过回顾会议来做持续的改进，但可能并不强调面向过程，来将所学到的经验教训转换成对其他项目也有益处的流程。而精益软件开发则更强调定义清晰的流程（或一组流程）来跨项目被使用，并进行持续的改进。
- 精益软件开发的方式可以被应用到迭代甚至是传统的软件开发方法中，所以有时它会被认为是不“敏捷”的。但是在某些情况下，确实需要一个被严格控制、有规定流程来驱动的方式，这样的话，精益软件开发背后的原则可以被用来将其合理化。
另外，马丁.本斯（Martin Burns）和埃里克.高特斯曼（Erik Gottesman）也指出了在敏捷和精益方法之间的一些区别：
- “精益的实施者会更倾向于自动化的方法因为这样他们就可以使之标准化，而标准化又是精益方式的动力。但是一些敏捷者就会倾向于尽量少用工具，并试图不去建立跨项目的标准化流程。”
- “精益法则更趋向于强调“刚刚好”的思想：‘在生活的很多方面，会有这样的结果：如果做得过火了，就会变成一种弱点，或称之为物极必反’。在敏捷开发中，这就是一项技术活儿：要拥有始终创造出有价值、美妙事物的动力，但同时伴随着敏捷和精益的，是找到一个平衡点，在这样的平衡点之上，投入的开销再继续做下去也不会创造任何价值，即使是真正提高了质量也是一种浪费。如果对于开发人员来说有一条职业能力进阶的通道，那么第六级就是能意识到“刚刚好”的那个程度，并且止步于此。”
主要角色
精益方式并不强调定义角色，因为它没有直接定义流程，更多的是一系列适用于其他开发过程（如敏捷、迭代、传统方法）的原则。所以主要的角色可继承于原有的开发过程，但不排除针对以消除浪费的目的适当增加或减少特定角色。
主要活动和最佳实践
如上所述，精益方式更多是一系列的适用于其他开发过程的原则，它并没有直接定义流程，但它所强调迭代和适应性的改变流程是软件开发环境中所需要的。
主要活动
1.建立顺畅的开发流程
正如上文所述，精益软件开发的宗旨是每时每刻快速的、有效的、可靠的交付价值（Deliver Value Quickly, Effectively, Reliably – Every Time）。其本身并不提供一套完整的方法框架，而是通过在原有框架中经过精益思考、对应与精益的原则，按照要求从开发者或最终用户的视角上观察软件开发过程，发现其中无益于快速交付的行为，然后持续改进。
所以实现精益软件开发的核心在于：建立起一套完整的开发流程，然后建立一套测量流程的手段，不断持之以恒的改善流程，不断优化、坚持不懈。
不同的企业因定位不同，对于研发的价值理解也是不一样的，他们的流程和实现流程的工具肯定是不完全一样的。但个人认为软件开发人员应当向丰田公司的产品开发流程学习和借鉴。目前，丰田内部的精益开发步骤是这样的：首先，在客户需求的基础上，对工作进行分辨，区分出哪些部分是能够满足客户需求的有效部分。如果工作中的某些流程生产出的结果并不能满足客户的需求，便是一种浪费，就不是增值的流程和操作。因此，精益开发首先需要了解客户需求。此后，需要对工作流程进行细化分割，把流程分成更细微的步骤，并保证每个步骤都能满足客户的需求，增加价值。
其次是流程的标准化和可操作化，这是精益思想流程的基础之一。在软件开发过程中，每个企业的现状都不尽相同，因此产品开发的方式也不同。但精益思想提到如何关注研发流程，让管理流程“落地”，并且让流程规范起来，不再是像过去把好流程放在纸上，靠人去管理。于是，固化和标准化开发流程就是一个实现方式。
2.通过推行精益管理，建立以人为本的团队
精益思想提到另一个重要的关于人的因素是：团队是推进精益管理的关键。通过推行精益管理，建立一个基业常青的团队，调动起每一个员工的积极性，只有这样才能推动开发项目的各项工作持续发展。于是，是否能建立一个良好的团队则是企业能否有效实施精益管理的关键。
最后，精益管理的推进要以人为本，精益管理虽然有各种流程作为基础，但是运行这些体系和流程的是人。熟悉丰田精益方式的人都知道，丰田方式中一项很重要的内容就是人员管理，即“育成”。育是培育，成是成功，强调人才培养，把人才看作是人“财”。一项针对包括丰田在内的50家具有百年历史的全球500强企业的调查显示，这些企业的共同之处，就是拥有一支有共同的理想、共同的价值观、共同的行为准则的强大团队。
3.有效的技术和工具支持
精益思想软件项目开发的第三个精髓，就是用工具和技术来支持流程和人的工作。在引进新技术方面，丰田奉行的原则不是积极倡导新技术，而是使用可靠的、已经充分测试过的技术。工具和技术的意义在于支持流程，而不是驱动它；是加强人的工作，而不是替代人。
在这里与大家分享一个有趣的例子，工具并不一定是最新的高科技的东西，有时它可以是很直观的方法。“大屋”是丰田普锐斯首席工程师想出来的一个工程合作方式。通过它，可以把各个职能部门的工程师聚集在一个大房间里。在这里，他们把产品开发状态的信息打印出来，包括种种数据、成本、质量、进度等关键问题，贴在墙上，每个人都可以方便地查看、讨论。当他们在一个房间开会和沟通的时候，他们就更加融洽，交流得更好，更容易做出决定，从而缩短产品开发时间。“大屋”听起来很简单，甚至有点可笑，但是它支持了流程和人的工作，就是正确的工具和技术。
最佳实践
目前比较流行的精益方法的典型实践包括看板、诱因分析、过程改进、价值流等，而最常用的就是与敏捷框架相结合的看板方法（kanban）：假设在一个产品开发流中有客户团队、产品所有人、开发团队和QA团队，他们通过使用队列传递移交物来协调工作，以使得团队之间能异步工作，并维持一定的工作速度。如下图所示，看板中每一个“DONE”区域其实就是一个队列，其工作方式就如制造工厂中的“仓库”那样，并且看起来非常像TPS的看板系统。同时，它看起来就像在每条工序内同步的使用敏捷看板，而在贯穿各个工序的整个价值流上异步地使用持续看板。这样的看板系统甚至可以扩展至覆盖整个价值流，在这种情况下，看板即是价值流的一个生动的可视化体现。
在本例中，通过设定每一个区域的容量大小可以控制在制品（Working in Progress, WIP）的数量。而为了使其变成拉动式的系统，仍需要一种机制来使下游工序可以以某种信号通知上游工序开始工作。其中一种方法就是制定一条规则，只允许下游移动“DONE”区域中的卡片来通知上游工序开始工作；另一种方法就是定期召开“迭代会议”，来同步团队和团队之间信息的传递。在迭代中，一组用户故事的个数即为被限制在制品的数量，而最终处于Done区域中卡片的数量就对应于迭代中的项目“生产率”。这样的方式，我们称之为“精益+敏捷看板”，如下图展示的那样它可以与“敏捷看板”相结合。
图3 Scrum白板与看板相结合
工作流程
如下表所示，系统工程国际协会（INCOSE3）已研制出一系列系统工程的方法来支持精益方式的六项关键性原则：
谁应该使用敏捷与精益相结合的方法
开发人员与经营管理人员
很多敏捷方法强调以开发人员为中心，而精益软件开发则强调以经营管理为中心的方式。不过，现在它们已经开始慢慢向对方融合：
- 如今的Scrum已经不仅仅是以开发者为中心，转而提供了某种程度上的项目管理框架，并包含了类似于精益法则的原则用来减少浪费的流程方法。
- Mary和Tom Poppendiek已经将原来的精益制造法则运用到软件开发环境中，并采用和敏捷原则相一致的思想。
总的说来，精益软件开发原则提供了一种不仅仅以开发人员为中心的方式，而是从经营管理等更广阔的角度来看待敏捷的方法。所以无论是开发人员还是经营管理人员都适用敏捷与精益相结合的方法。