精益产品开发看板Word文档格式.docx
《精益产品开发看板Word文档格式.docx》由会员分享，可在线阅读，更多相关《精益产品开发看板Word文档格式.docx（22页珍藏版）》请在冰豆网上搜索。
看板信号由下游向上游传递，拉动上游的生产活动，使产品向下游流动。
拉动的源头是最下游的客户价值，也就是客户订单或需求。
图㈡看板拉动制造过程
图㈢是一个典型的看板——装在塑料套里的一枚卡片，包含的信息是“什么地方，需要什么产品，多少数量”
图㈢生产中的看板
1.2基于看板的拉动系统实现准时化
准时化又叫即时生产（Justintime-JIT）是丰田生产方式的一个支柱。
看板形成拉动系统，各环节根据看板信息，仅在在需要的时间，生产需要数量的必要产品。
这将带来生产库存的降低，甚至实现生产过程零库存。
库存又被称为“在制品（WIP——workinprogress）”，是已经开始但没有完成的工作，它们堆积在工序间或临时仓库中。
库存降低带来的直接收益是：
1）降低成本：
库存减少增加了运营现金的使用率，同时降低管理和仓储开销。
2）缩短交付周期：
消除或缩短产品在工序间的库存等待时间，缩短了从开始制造到交付的周期时间。
3）提高制造过程的灵活性：
在低库存水平下，调整生产的计划更加容易。
降低库存更重要的作用是暴露制造系统中的问题。
图㈣中的湖水岩石是一个经典隐喻，水位代表库存多少，岩石代表问题。
水位高，岩石就会被隐藏。
生产系统中库存多时，设备不良、停工等待、质量不佳、瓶颈过载等问题都会被掩盖。
库存降低后，这些问题都会显现出来。
没有了临时库存的缓冲，设备运转不良或停工等待立即会凸显出来；
没有了库存等待时间，上一环节输出的质量问题也能即时得到反馈。
这就是所谓“水落石出”，暴露问题是解决问题先决条件，不断暴露和解决问题，带来生产率、质量以及灵活性的提高。
图㈣湖水岩石效应
1.3自働化
自働化是丰田生产方式的另一支柱，它的准确含义是自动停机（Auto-No-Mation），指出现问题时（如某个环节有次品），机器能够自动感知异常，并立刻停机或停下整个生产线。
丰田认为，这相当于把人的智慧赋予了机器，称其为“人字旁的自动化”，所以用“働”而非“动”字。
图（三）比较了自动化与自働化在概念和实践上的不同。
图㈤自动化和自働化
自働化把质量内建于每一个制造环节，出现异常时，杜绝继续产出不合格产品，并且不把不合格产品输入到下一环节。
这就是“内建质量”（buildqualityin），而不是让质量依赖于最后的检测环节。
其次，自働化带来“停止并修正”（StopandFix）的文化，发生异常时，立刻停止生产，分析根本原因，并加以解决，防止问题的再次发生。
“停止并修正”是持续改善的基础。
2.精益产品开发的发展
以上我们简要介绍了精益制造（丰田生产方式）的框架和其中的看板实践，它既带来直接经济结果，又带来深层次的文化和思想变革。
精益是制造业的革命，是既大规模生产之后的全新范式。
精益思想的影响早已超越制造领域，精益服务、精益医疗，甚至精益行政都被广泛实践，产品开发也不例外。
然而，开发和制造特点不同，决定无法照搬精益制造的实践。
产品开发需要从自身特点出发，发展完备的实践体系。
产品制造
产品开发
影响
工作对象
具体、可见的物理产品
抽象、不可见的信息
产品开发的价值、价值流动不可见，管理价值流更加困难。
有必要采取适当的措施，可视化价值和价值流动。
完成单个任务的时长
固定——完成前后两个加工任务的时间相同，且可以精确预测。
不固定——每一个开发任务都是全新的，完成的时长不同，且不能完全预测。
在生产中可以追求或逼近零库存。
产品开发中，由于任务时长的不确定性，零库存可能会导致开发步骤间的等待。
不同任务的延期成本
相同
差别很大
在生产中一般采取先入先出（FIFO）的队列管理方式；
开发中用需要应用比先入先出更灵活的队列管理方式，以优化经济结果。
对可变性和错误的态度
制造是重复的过程，消除可变性能够提高质量。
不确定性（可变性）是产品开发价值的一部分，完全消除差异是不可能的
产品开发必须接受不确定性，并通过必要的试错来验证它们，以增加价值。
可变性不能完全消除，需要在考虑开发过程的可变性。
精益产品开发概念出现于上世纪90年代，2000年后逐步成熟。
这中间起到推动作用的代表人物有MaryPoppendieck，DonReinertsen和DavidJ.Anderson等。
他们促进了精益思想和产品开发特征的结合。
MaryPoppendieck是精益软件开发的早期推动者，她的思想在敏捷软件开发社区被广泛引用，2003年到2010年，Mary和他的丈夫TomPoppendieck先后在三本书中总结了这些思想，并提出了操作建议。
DonReinertsen致力揭示产品开发流的本质，并提出相匹配的原则方法。
在2010年出版的“ThePrinciplesofProductDevelopmentFlow”一书中，Don提炼了精益产品开发的175条原则，这可能是迄今为止对产品开发最本质和深入全面的阐述。
但面对175条原则，从哪里开始是一个问题。
2006年在DonReinertsen的启发和鼓励下，DavidJ.Anderson最早在软件开发中应用看板实践，其后不断完善，形成了看板开发方法，这是精益产品开发走向适用和普及的重要里程碑。
看板的推广速度超过任何其它敏捷开发方法，Versionone的调查报告显示看板是增长最快的敏捷实践，2011年使用了看板的敏捷团队占24%，2010年这个数据是18%。
2010年David在他的着作”kanban–SuccessfulEvolutionaryChangeforYourTechnologyBusiness”一书中，详细介绍了看板的价值、原则和实践。
书中总结了看板开发方法的五个核心实践，它们是：
可视化工作流、过程规则显式化、限制在制品数量、度量和管理流动、以及协同改进。
接下来，我们将以这五个实践为线索，介绍看板开发方法的概貌。
3.看板的五个核心实践
3.1核心实践1：
可视化工作（价值）流
产品开发的加工对象——信息——是抽象和不可见的，这提高了价值流的管理难度。
看板开发方法把可视化工作流作为基础实践，先让价值和价值流动具体可见，然后才是管理和优化。
图㈥是看板开发方法中的一个典型可视化案例，被称为看板墙（Kanbanwall）。
图㈥可视化工作流
图中的每个卡片代表一个价值项，如：
功能需求、缺陷、技术概念验证等。
它们所在的列，表示其所处的阶段。
这些价值项，每经过一个阶段（图中的列）都会产生新信息，价值得以增加。
例如，需求经过分析阶段，注入了新信息，价值更高。
价值流是价值项从左至右的流动过程，是信息的产出过程，也是价值增加的过程。
价值流动可能会被阻碍。
比如，编码因对第三方接口错误而无法进展；
测试因没有设备而停滞。
图中，红色卡片是对问题和阻碍因素的可视化。
标识阻碍因素并推动其解决，促进价值流动。
最终限制系统端到端流量的是系统瓶颈处的流量，改善端到端的价值流，必须从解决瓶颈问题开始。
发现看板墙上的瓶颈并不困难，找到最长的队列就可以了，这就和交通系统的瓶颈处，总是出现长长的等待车队是一个道理。
上图中的队列出现在测试处，不难看出，测试是价值流动的瓶颈。
价值、价值流，以及问题和瓶颈的可视化，是改善价值的起始，也是其它看板实践的基础。
3.2核心实践2：
显式化流程规则
显式化流程规则，是指明确定义和沟通团队所遵循的流程规则。
价值项的“流转规则”是看板开发方法中最典型流程规则，它定义了一个价值项从一个阶段进入下一阶段所必须达到的标准。
图㈦中，给出了某团队其中一项流转规则的实例，定义了从分析阶段进入开发阶段所必须达到的条件。
“流转规则”的显式化，让质量内建于各个阶段——这与精益制造中内建质量的思想是一致的。
除各个“流转规则”外，其它重要的流程规则也可以或者需要被显式化，如，团队的协作规则、优先级的定义规则等。
图㈦显程化流程规则
流程规则显式化更重要的意义在于，它是“持续改进”的出发点和结果的载体。
没有显式化的规则作为依据，讨论改进就没有基础，而变得主观和随意。
改进的结果通常也需要落实到显式的流程规则当中，让改进稳步进行，避免低效的反复。
显式化规则不是为了限定团队的工作方式，而是为了帮助团队更好的改进。
这就像，丰田的生产现场必须有明确操作规程，但如果这个操作过程长时间没有变化也同样是一个问题，因为，持续改进是精益思想的核心之一。
3.3核心实践3：
限制在制品数量
限制在制品数量是看板开发方法的核心机制。
如图㈧所示，列标题右面的数字标识了该阶段允许的在制品的最大数目（进行中和完成的价值项的和）。
在制品数目小于这个数字时，才可以从前一阶段拉入新的工作。
图中，分析阶段的在制品限制数目是3，而实际在制品数目是2，可以拉入新的工作。
测试阶段的在制品数是3，达到了上限，就不允许拉入新工作。
图㈧限制在制品数目
限制在制品数量形成一个与精益制造类似的拉动机制。
一个环节有空余的能力（在制品数目未达上限）时，从上游拉入新的工作，拉动的源头是最下游的交付或客户需求。
与产品制造类似，通过拉动系统可以：
1）加速价值流动：
限制在制品数量，减少了价值项在阶段间的排队等待，缩短了价值从进入系统到交付的时间，加速了端到端的价值流动。
2）暴露问题：
限制在制品数量，让湖水岩石效应产生作用。
它让过去被隐藏的问题，如团队协作不良、需求定义错误、开发环境低效、资源分配不均衡等得以显现。
许多号称使用“看板”的团队，并没有限制在制品数量，他们当然也不会得到上述收益。
精益制造通过看板向上游传信号，拉动生产。
而看板开发方法通过限制在制品数量形成拉动系统，缺乏这一核心机制就不成其为看板，对此，CoreyLadas?
这样描述“复印的美元不再具备货币的内涵，因此不再是钱；
同样，缺少在制品数量限制的看板墙，也不能叫看板”。
在制品数量的限制值及其演化，将在以后的文章中讨论。
3.4核心实践4：
度量和管理流动
快速、顺畅的价值流动是看板开发方法的目标。
快速流动带来快速的价值产出和快速反馈，它对业务成功至关重要；
顺畅流动，意味着稳定和可预测的价值交付能力，这与流动的绝对速度同等重要。
度量为改善价值流动提供方向参考，同时为改善的结果提供反馈。
看板开发方法没有定义特定的度量方法，累积流量图是实际应用较为普遍的一种。
图㈨是一个典型的累积流量图，左面的斜线是累积已经开始的价值项（如用户需求）数目，右面斜线是累积完成价值项的数目。
两条斜线的垂直距离表示某个时刻已经开始但还没有完成的价值项数目，也就是在制品的总计数量。
两条斜线的水平间距表示价值项从开始到完成的周期时间，也就是从概念到交付的响应时间，它是价值流动效率的一个重要衡量。
斜线的斜率反应的是价值交付的速率，也就是每周可以交付的价值项数量。
图㈨流量累积图
累积流量是一个综合的价值流度量方法，可以通过它得到不同维度的信息。
例如，我们设想限制在制品的数目，可以缩短周期时间、而对交付速率影响有限。
但实际效果如何还要通过事实来检验，通过实验和度量，图中的数据基本验证了这一假设，让改进更有方向，结果更可衡量。
同样的数据有不同的呈现方式，图㈩基于相同的数据，它突出了在制品数目和周期时间的变化趋势，以及两者的关系。
从图中可以看出，周期时间的降低略滞后于在制品数量的降低，这符合精益理论，因为只有在积累的队列被处理完后，对交付周期的改进才能够显现出来。
而图11反应的是系统流量（每周交付价值的数量）的变化趋势，为改进提供了信心。
图㈩在制品数目和周期时间
图11周流量图
以上只是一个度量实例。
度量不是目的，而是管理和优化价值流的手段。
对于特定的组织，度量什么应该由目标和现状决定。
3.5核心实践5：
协同改进（ImproveCollaboratively）
应用可视化、限制在制品数量、以及价值流度量，能够暴露产品开发中的问题和瓶颈。
但发现问题还不够，重要的是如何去解决它们，对此看板开发方法给出了两个建议——团队协作和应用科学方法和模型。
限制在制品数目本身就能够激发协作，例如在前面图㈧的看板墙，可能会出现以下的顺序场景
1）测试遇到问题（如输入质量太差）而被阻塞，在制品数量达到上限
2）因在制品数量达到上限，根据规则，测试不能从上游（实现）拉入更多的工作
3）实现阶段已完成的工作无法进入下游测试环节，实现阶段的在制品数量很快也达到上限
4）实现要想开始更多的工作，就必须关注下游的问题，并做出反应，如提高本环节的输出质量，或者是给予帮助
5）实现和测试的协作使价值流动更加顺畅
图12协同改进
图12是”kanban–SuccessfulEvolutionaryChangeforYourTechnologyBusiness”一书的封面插图，它反映了发生在看板墙前面的协同改进。
看板开发方法的基本假设是：
产品开发的目标不是单个环节效率的最大化，而是端到端价值流的提升。
看板通过拉动机制暴露了限制价值流动的瓶颈，并激发团队协作，改善价值流动。
解决瓶颈问题的方案可能在瓶颈处，如临时加班、分配更多资源、或相邻环节的支持等。
但很多时候解决瓶颈问题的方案在别处，例如提高瓶颈之前环节的输出质量，调整职责分配，甚至是重新设计工作流。
对于偶然出现的问题，只需要临时性解决方案。
如突发性高负荷，可以通过暂时的相互支持解决。
而对于系统性问题，如持续的负荷不均衡，则需要长期的方案和更加系统和科学的模型指导，如系统思考、精益思想、排队理论等，这些模型本身不属于看板方法的一部分，但它们让长期的改进有章可循，以后的文章，我将中深入地探讨其中的一些模型。
4.总结：
看板是变革方法
DavidJ.Anderson这样定义看板开发方法：
“看板定义了我增量、渐进地改变技术开发和组织运营的方法。
它的核心机制是限制在制品数量的拉动系统，通过它暴露系统运作（或流程）的问题，并激发协作以改进系统。
”
这当中的核心是，看板并不是一个开发框架或流程，而是引领变革的方法。
每个组织有自己特点，所面对的市场，使用的技术不同，经历和所处的阶段不同，他们值得也应该拥有适合自身特点的方法流程。
看板的实施正是从组织流程现状出发，首先可视化实际工作流并显式化流程；
在此基础上，限制在制品数量形成拉动系统以暴露系统问题和瓶颈，度量价值流动以发现改进机会；
并通过团队的协作，不断改进和演化出合适的流程、方法，实现一个高效、顺畅的产品开发价值流。
适应组织的具体情况，和发现合适的变革路径，这两点是敏捷实施的最大困难，看板给出了被证明可行的方案。
这可能是看板能够在国外社区迅速推广并成功运用的原因，而在国内，看板这方面的价值还远未被认识和发掘。
这篇文章之后，我们还会从不同的方面，更加深入地介绍精益产品开发。
它们是：
-价值篇：
解析产品开发中的价值和价值发现过程
-价值流篇：
解析产品开发中流动的本质，和价值流的管理
-可视化篇：
探讨面向价值和价值流的整体可视化方案
-看板实施篇：
通过案例介绍看板的实施步骤和实践细节
-变革篇：
从组织变革的视角讨论精益的实施、看板应用和持续改进
-……
感谢张凯峰对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。
也欢迎大家通过新浪微博（@InfoQ）或者腾讯微博（@InfoQ）关注我们，并与我们的编辑和其他读者朋友交流。
已经翻译成中文的我推荐两本
1.《精益开发实战》，这本书很简洁实用，从头至尾围绕一个成功的案例展开,读起来很爽，也提供了大量的实践操作方法。
2.《看板》，这本书据说已经翻译好了，六月份左右出版，值得期待。
这本是看板最权威的书，全面讲述了看板的理论和实践。
另外：
MaryPoppendieck有三本关于精益软件开发的书，第一和第三本都有中文，Mary的书是很好、很全面，问题是多停留在概念层面，没有实践的人理解起来有问题。
解析精益产品开发
（二）——产品开发中的价值
本文是《解析精益产品开发》系列的第二篇。
第一篇中我们介绍了看板方法，看板方法帮助组织持续改进，实现顺畅和持续的价值流动。
但是，只有基于正确价值的流动才有意义，这是精益产品开发的前提。
在本篇中，我们将揭示产品开发中的价值本质，并以此为基础，分享一个适合精益产品开发的价值定义和发现实践——影响地图（ImpactMapping）。
1.产品开发中价值的本质
传统项目管理强调预先定义、分解和估计价值，以此为基础计划项目，然后按计划执行就可以实现价值。
这一理念应用在诸如生产或建筑之类的工程项目上是有效的，但应用在产品开发上时就有问题。
以瀑布模式下的软件开发为例，在项目前段，通常能够按计划进行，但为了满足进度要求，往往会让风险后移；
在项目后段，风险和不确定性逐渐显现，项目出现困难和延期；
更有甚者，如果交付的产品不符合客户或市场的要求，再完美地符合计划也是没有价值的。
为什么在工程项目中有用的方法用在产品开发中就会出现问题？
其原因是产品开发和工程项目中价值的本质是根本不同的。
1.1信息是产品开发的价值载体，它与不确定性如影随形
工程项目（如生产或建筑）的产出是物理产品，价值由物理产品承载；
产品开发的产出是方案，价值由方案中的信息承载。
以“制作食品”和“制作食谱”来类比，产品开发相当于制作食谱，工程项目则相当于按食谱制作食品。
制作两份同样的食品，得到两份价值。
而制作两遍同样的食谱，不会产生两份价值，因为它没有产出新的信息，价值也无从谈起。
不确定性与信息及其承载的价值如影随形。
贝尔实验的伟大科学家香农（Shannon）最早用比特（bit）来度量信息，并奠定了信息理论的基石。
按信息理论，信息的量是对事件不确定性的衡量，表达为information=?
。
一个bit包含了0和1两种不确定性——
，而1个byte包含256（0-255）种不确定性，其信息量为8bits——
确定事件的信息量为0——
产品开发不可能排除所有的不确定性还保留任何价值。
正如管理学之父彼得?
德鲁克在其经典着作《管理的实践》中所述：
在所有关于未来的概念中，一定会失败的就是那些“十拿九稳”、“零风险”等“绝对不会失败”的概念。
每一次产品开发都必须与过去有所不同，这意味着不确定性和风险，也为产品注入信息，带来潜在价值。
TomDemarco在《与熊共舞》一书中把风险和不确定性比作熊，成功的产品开发是“与熊共舞”的艺术。
第一代iPhone采用了全新操作界面——多点触控、全新材料——大猩猩玻璃材质，和全新商业模式——运营商（AT&
T）深度绑定，这些尝试带来了技术、生产和商务上的不确定性，同时也成就了产品与众不同的体验和非凡的价值。
在技术、产品和市场快速变革的今天，挑战不确定性和风险已经成为企业交付价值获得竞争优势的不二法门。
自适应学习与国内在线教育
1.2和商业目标相关的信息才能带来价值
信息承载产品开发的价值，但只是潜在价值。
只有通过达成商业目标，信息才能成为真正的价值，组织也只应该在能帮助达成商业目标的地方承担不确定性。
设想，苹果如果在第一代iPhone中尝试4G（LTE）通信技术，会带来更大的不确定性，然而即使成功了，也不能带来价值，因为当时还没有与之配套的商用LTE网络，事实上，第一代iPhone甚至没有支持当时已经流行的3G通信技术。
与商业目标无关的不确定性不带来价值，而且可能是有害的。
GoogleWave刚推出时被Google和用户寄予了厚望，产品红极一时，但一年后却因未能吸引到足够用户而宣布停止开发。
Wave几乎加入了能够添加的所有功能，但用户并不买账，相反，过多的功能导致复杂的界面、模糊的定位和稳定性的缺乏，让用户远离Wave。
产品开发的目的是实现商业目标，而非完成功能。
产品的功能应该围绕有限和明确的商业目标展开，否则一方面会引发范围蔓延，造成项目执行和产品维护的困局；
另一方面却无法实现核心目标。
Wave引入过多的功能而牺牲了易用性和稳定性，但用户还是普遍的抱怨，它不能满足自己的应用要求，它什么都能做，但作为协作工具它比不上GoogleDoc或Zoho，作为社交工具它比不上Facebook或GoogleBuzz，作为通信工具它比不上Gmail或已有的IM工具。
ScottBerkun曾经成功领导微软数个重大项目，包括奠定浏览器大战胜局的InternetExplorer4.0，在其畅销书《项目管理之美》中他分享了一个曾经使用的需求管理实践——应用简单机制跟踪从目标到功能再到产品项的映射关系。
在这一机制下，每个工作项必须对应一个功能，每个功能必须对应一个目标，并且每个版本仅聚焦于有限数量的目标。
依据这一映射，团队可以明确判定一个新的工作项能否进入项目范围。
这既有效抑制了范围蔓延，又确保了核心目标的达成。
1.3价值要在开发过程中持续发现
产品开发是一个信息积累和知识创建的过程，团队持续获取业务需求、市场环境、实现技术等方面的信息，深化认知、明确价值。
近年来，业界在如何让这一过程更加有效方面的实践取得了很大进展。
1.3.1先期决策是传统项目管理的通用实践
传统项目管理强调预先计划和按计划执行。
如图㈠所示，团队拥有最丰富信息和知识的时刻是在项目的末期，这也是最可能做出正确决策的时刻。
然而与之对应的是，绝大部分的决策在项目的早期做出，如设定产品需求、承诺项目计划和确定技术方案等。
此时的决策只能依据有限的信息和知识做出，却成为后期项目执行的基准。
过早的决策成为后来的约束，也降低了应对变化的灵活性。
图㈠先期决策
1.3.2“延迟决策”比“先期决策”更符合产品开发的本质
敏捷和精益开发倡导“延迟决策”。
如图㈡所示，在迭代模式下，随着产品开发的进展，市场和技术环境发生变化，客户需求逐步清晰，成员对业务和技术的掌握越来越全面深入。
对应的，项目的决策也是分步做出的，项目启动阶段团队做出一些初始的决策，更多的决策则发生在后续迭代中，此时团队拥有更多的信息和知识，更可能作出正确的决策。
图㈡延迟决策
在《ThePrinciplesofProductDevelopmentFlow》一书中，Donald.Reinertsen说：
“产品开发
升级会员 