看板方法经典读后感有感

　　《看板方法》是一本由David J. Anderson著作，华中科技大学出版社出版的平装图书，本书定价：69.00元，页数：280，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。
　　《看板方法》精选点评：
　　●在咖啡厅鏖战5个小时，一气呵成看完这本书，在实践了敏捷开发、精益创业4年左右的时间回头看这本书收获颇多。关键在于，这本书的目标是澄清看办法方法并提出在企业实施看板的解决方案，副标题很切合本书意图——科技企业渐进变革之道。
　　●重新认识看板，确实学到了很多
　　●提高效率，减少成本，看板方法值得使用，但故事说的啰嗦些，而
　　●三刷，一些有意思的点:1.小厨变异性根源，提升可预测性 2.大型看板项目引入泳道 3.WIP跟踪与持续改善
　　●最受启发的是，制度和方法论对效率的影响程度，是远超想象的。另外对于「浪费性」活动的总结也很到位：事物成本、协调成本、破坏负载。看板最重要的精髓，就是公开透明、锻造团队、提升可预测性。
　　●路宁是我的看板老师，从他身上学到的东西远比书中的精彩。
　　●非常经典
　　●约束理论，过程可视化，问题可视化，建立持续改进的组织文化
　　●或许是因为看板的方法论来源于大型制造业，所以即便本书针对的是看板方法与科技企业的升级方法论，依然还是可以看到很多制造行业的影子，如果是软件开发从业者读起来会觉得很难结合自身的经验产生共鸣感或是落到痛处。 从理论上来讲，对看板方法描述得很全面了，先掌握住看板理论精髓，再去实践中慢慢打磨吧。可以结合infoQ上对于看板和scrum的比较分析——后者是落在日常工作中的流程上的看板方法，一粗一细，也能了解个囫囵了。
　　●看完。书打四颗星，翻译打一颗星，这译文真是令人流泪…
　　《看板方法》读后感(一)：看板是什么, 不是什么
　　看板不是一种软件开发方法, 不是软件生命周期管理方法, 它是一种推动变革的方法, 甚至跟软件开发没有关系.
　　前提假设
　　任何方法都基于一些前提假设. 看板的前提是组织内对团队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。先来看看「能力受限资源」的例子：
　　华盛顿 SR-520 公路是连接西雅图与其市郊柯克兰（Kirkland）和雷蒙德（Redmond）两区的高速公路，每天有 8 个小时处于严重的双向交通瓶颈状态。经历浮桥跨过华盛顿湖前，这条高速公路由三车道变窄成双车道，导致高峰期只发挥了 20% 的吞吐潜力，堵车长达 7 公里。
　　「非即时可用资源」并非瓶颈，但是，它们看起来很像瓶颈。普吉特海湾的轮渡系统是一个典型的例子：
　　普吉特海湾的三个轮渡系统把吉赛普（Kitsap）和奥林匹克半岛（Olympic Peninsulas）与西雅图市区连接在一直。其中一个是连接埃德蒙兹（Edmonds）东侧和金斯敦（Kingston）西侧的处在 SR-104 公路上。在地图上，这条轮渡航线显示为 SR-104 公路的一部分。通常它被标记为「收费」，而不是明确说明「到这里你得上船摆渡」。开车到轮渡时，需要先付费，然后在一个等候区等候。等待时间大概需要 30 分钟，因为渡轮需要花 30 分钟时间渡过普吉特湾；之后渡轮还需要花 10 到 15 分钟卸下车辆，在返航前又需要花差不多的时间载上全部新的车辆。通常轮渡公司会投入两艘渡轮，因此每艘渡轮的运输时间差不多是 50 分钟一趟。在高峰时间，可能会投入 3 艘渡轮，把每次摆渡的等待时间控制在 35 分钟左右。
　　在我的团队，后台开发是「能力受限」，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