看板方法读后感锦集

《看板方法》是一本由David J. Anderson著作，华中科技大学出版社出版的平装图书，本书定价：69.00元，页数：280，特精心收集的读后感，希望对大家能有帮助。

《看板方法》读后感(一)：看板是什么, 不是什么

看板不是一种软件开发方法, 不是软件生命周期管理方法, 它是一种推动变革的方法, 甚至跟软件开发没有关系.

前提假设

任何方法都基于一些前提假设. 看板的前提是组织内对团队capacity达成共识. 团队能做多少事是系统隐含的不变量, 所有其它决策都不能破坏这个不变量. 一旦投资方认为团队capacity还有潜力可挖, 则各种限制将失去意义.

为什么看板五大特征首要的是可视化？

要推动变革, 需要避免遭遇强大的阻力. 把现状暴露给所有人, 有助于抑制暗地的抵触, 促进解决问题的主动性.

避免遭遇强大阻力的另一措施是小步前进. 可视化当前价值流有助于识别最重要的瓶颈和浪费. (大卫安德森这么谨慎, 可能与他最初引入看板方法所在的两家公司有关, 都是臃肿官僚的机构, 都是有稳定市场稳定产品的公司)

要对团队Capacity 达成共识, 可视化当前状态也是第一步.

更多观点: http://liguanglei.name/blogs/2014/04/09/kanban/

《看板方法》读后感(二)：“只有当方向正确了，速度才是最有用的”

David这本看板的专著帮助我澄清了在软件/产品研发里实施看板系统的诸多概念和困惑。在此我想结合以前为客户实施转型的经历写两点感受最深刻的感受。

第一，看板只发现问题，无关乎如何改进。

看板不遗余力地为项目引入“透明度”，不仅是工作内容的透明，还包括过程（工作流）的透明。透明带来的最大好处是能够让所有问题暴露在阳光下。

在进行改进的时候，看清形势和问题并不容易，让所有人都认可形势和问题更是难上加难了。看板是一种的相对客观公平的手段，容易被团队内多数成员所接受。

第二，看板可以带来渐进式的改良，真正在组织种产生最终的变革。

看板的理论虽然繁杂，却几乎都关注于如何“发现问题”，并没有强制实施者用什么手段解决问题。因此，它不会要求一个能力很差的团队实施TDD，也不会让一个隶属于等级森严的组织内的一个团队完全丢弃预先计划和设计。

看板的实施者要根据看板所揭示的问题，审时度势，与团队一起找到能够被团队和更高层面的组织所接受的改进方法。这种方法不会让团队产生强烈的抵触，以更柔和的方式进行改良，但只要积少成多，最终还是可以产生大的变革。

最后，正如这本书的前言所讲，“只有当方向正确了，速度才是最有用的”。当我们希望在组织中引起变革的时候，只有看到了最关键的问题，接下来的努力才会带来效果。看板正是发现问题的有效手段。

《看板方法》读后感(三)：一本必须反复咀嚼的书—《看板方法》 读后感

首先我必须向《看板方法》的翻译作者章显洲老师致以深深的歉意。在今年年初本书即将上市的时候，面对素未谋面的热心读者的请求，章老师非常热诚地答应赠书给我，并在邮寄之前还专门向我核对地址。今年三月我收到了章老师的赠书及赠言：上善若水、大道至简。收到书后，我开始研读。因为过完春节后工作调整，异常繁忙。而我不是一个很善于利用碎片时间的人，所以读完一遍觉得不够，直至现在读完第二遍，才能上交这样一份读后感。

《看板方法》是一本讲述全新方法论的书，但是既能讲清楚理论，又能提供清晰的可实际操作指导，这是我看过为数不多的书之一。

我在开发团队中担任过产品经理、项目经理的角色，开发团队人数规模在10人以下或10人之上均有，全本地化团队或异地团队也有，因此遭遇过各种困境。在看书的过程中，每每看到有关这类困境的讲述时，顿时心有戚戚焉。比如：公司高层部门直接指定或要求承诺未知（完全是不合理的）交付时间；负责开发的员工为了赶工超负载工作至无法承受而离开团队；初始开发质量低下导致后期返工增加成本，造成巨大浪费；产品涉及多个部门协调成本很高，导致具体需求悬而未决；交付缺乏预测性，交付节奏差导致客户抱怨频繁；各种需求前置时间过长，多次无意义排序导致项目推进缓慢。

如果你所在的团队也存在这些情况，那么我很郑重地向你推荐《看板方法 科技企业渐进变革成功之道》。

启动看板方法的关键要义是，变化要越少越好。“你必须要抵制住改变工作流程、职位名称、角色及其职责，以及当前在用的具体实践的诱惑。不要试图去改变团队成员与其他合作伙伴、参与者、干系人的内驱力、专业自豪感和自我心理，主要要改变的是在制品的数量、与上下游业务间的接口及交互方式。”

有过公司或团队变革失败的经历，我非常看好这种渐进式的变革。在阐明如何使用这种方法好处的同时，书中还提到保障这种渐进式变革实施的措施。1、精心设计的工作项卡片；2、每日站立会议；3、服务类别的设置；4、用数据说话的运营会议及会议把控；5、各类成本的控制；以及其他措施。这些指导让我在打算尝试看板方法的时候，信心倍增。

看板方法有两条基础性的原则：一是限制在制品数量，另一是仅当有可用产能时才通过信号卡传递机制来拉动工作的流动。围绕这两条原则，书中详尽地阐述了看板方法中的各个环节，比如，如何建立良好的交付节奏（高风险或高价值的工作项，全按时交付而且，交付活动还在以可靠的节奏持续进行。）；如何建立良好的输入节奏（进行优先级排序的事务成本越低越好。）；如何设置在制品限额（为工作流中的在制品限额选择合适的大小。千万不要为了一味追求敏捷性或质量而牺牲可预测性。）。在这些环节的讲述中，书中还通过事例来形象生动地说明，比如用SR-520公路车流量的例子来说明瓶颈问题，让整个书读起来一点都不枯燥。

其实看板方法，真的就是一个方法。当你遇到困境想要寻求解决方法的时候，不妨把这本拿出来再认真看看，又可以得到新的启示。正如本文标题所说，这是一本值得反复咀嚼的书。

最后，特别赞一下本书的编辑和排版，字体大小合适，段落清晰。每个章节有总结，有专业词汇的索引，非常实用。

《看板方法》读者&章显洲老师的粉丝：Lily

二0一四年八月八日

《看板方法》读后感(四)：看板的理论阐述

读《精益开发实战》时知道了看板方法，当时的粗浅理解是「可视化管理」，因为我个人更喜欢电子看板，团队迟迟没有引入「物理看板」，2015 年使用「电子看板」半年后还是回到了基于甘特图的老路。由于缺乏理论基础，总是在按照传统的项目管理思路使用看板，新瓶装老酒，感觉怪怪的。

David Anderson 在《看板方法》开篇以春天樱花季去东京皇居东御苑公园游玩的经历说明「看板并不只供制造业使用」，由此引出两个核心概念：Pull System 和 Work-In-Progress Limit。公园本身就是一个拉动系统，游客便是在制品。游园的高峰期，通过发放卡片的方式来控制园内的人数，当所有卡片发放完时，新到的游客必须在园外的桥上排队等候，等待其他游客离园后回收的入园卡。

第四部分以「公路」和「海湾轮渡」为例说明 Bottelnecks。先来看看「能力受限资源」的例子：

「非即时可用资源」并非瓶颈，但是，它们看起来很像瓶颈。普吉特海湾的轮渡系统是一个典型的例子：

在我的团队，后台开发是「能力受限」，7 人项目组只有 1 人负责后台，既要设计 DB、REST API 还要对接 iOS / Android 和 Web 后台的功能开发。我本人是「非即时可用」，A 项目产品经理找我评审需求时，我可能在和 B 项目架构师评审设计；B 项目找我讨论下个月工作计划时，我可能在做 S 项目发布……使用物理看板后，站立会议拉动卡片时我们俩将被标注为阻塞（Block），想想还有点儿小紧张呢 :D

再次回到东京皇居东御苑公园的例子，WIP Limit（游客上限）在这个示例中是确定的，但是在软件项目中任务通常无法精确估算，和朋友讨论时我经常被问到：

* 有些功能半小时能修改完，有些要一两周，怎么统一；

* 今天刚确认的需求明天又变了；

* ……

David Anderson 在书中把上面的问题称做：Variability。

第 19 章作者深入讨论了「变异性的根源」，分为「内部变异」和「外部变异」。结合 19 章重新阅读本书第三部分，就能够理解作者为什么提出了 Value Stram / Work Item Type / Delivery Cadence / Prioritization / Class-of-Service / Operations Review 等关键活动了。

最后，David Anderson 在书中介绍的看板方法起源于「维护项目」，对于产品研发型项目如何应用看板还要进一步学习，希望能够在下一本书《看板实战》中找到答案。

原文链接：http://www.jianshu.com/p/9735dfdfe87a