作为一个半吊子项目经理，周旋在技术与业务团队中是我的必修课。为技术团队做好第一道门板是我的职责之一，这并不是说我不关心项目的进度、质量，而是实在业务团队五花八门的需求太多了。随之而来的问题自然也就常见又头疼：响应时间（前置时间）长、初稿代码质量差、每个程序员并行项目过多⋯⋯技术与业务团队当然都很不满意。我们急需变革。
在这种情况下，我读到了这本《看板方法》。
作者表示，这本书是围绕着两个问题来写的：
1. 如何实现现在敏捷社区所称的可持续步调（sustainable pace），保护团队免受业务部门提出的无穷无尽的需求的困扰？
2. 如何克服其中不可避免的变革阻力，将敏捷方法成功推广到整个企业内？
这两个问题，正是我关心的。想必众多与我一样深陷在交付速率与需求过多问题中的项目经理也非常急于解决这两个问题。
看板是什么？
Kanban，最早是丰田生产方式及其改善方法的支撑机制，能够带来持续改进。本书的作者，David J. Anderson，则是将Kanban带入软件工程的第一人。他于2004年在微软实施了第一个虚拟的软件工程看板系统。
看板系统（Kanban system）来自一系列称为拉动系统的实践方法。看板（Kanban）方法指的是自2006-2008年间在Corbis公司涌现的渐进增量式的过程改进方法学。
在软件开发行业，看板起到权限授予者（permission giver）的作用，鼓励团队根据具体情境制订过程解决方案，而不是教条式地遵循某种软件开发生命周期过程定义或模板。
使用看板方法的好处？
1. 促成增量式的变革。
2. 降低变革中的政治风险。
3. 最小化变革过程中遭遇的阻力。
4. 发现改善的机会，而且其中不会涉及复杂的工程方法变更。
从哪些地方开始入手？
1. 减少在制品的数量，即减少进行中的工作项数量。这能增进与下游合作伙伴入运维部门等之间的信任。
2. 频繁发布。这能增进与上游合作伙伴比如市场营销部门等之间的信任。
3. 降低变异性。这将有利于实现资源平衡（并潜在地降低对人数的需求），且能减少看板令牌（Kanban tokens）、减少在制品数量，最终体现为平均前置时间下降。
4. 为了降低变异性而进行的改变，需要留有富裕时间。只有这样，团队成员才会有时间与精力对自己的工作成果进行反思和进步。
看板 VS. Scrum
公司也在尝试推行Scrum，但毫无成效。冷眼观察下个人感受是：Scrum对人的要求太高了。
首先，得有一个经验丰富的Scrum Master，才可能从小范围内对流程进行改变。
其次，得有最少一个精通业务&技术的产品负责人，才可能每周挑选出最符合业务部门经济利益的用户故事与Scrum团队开展有趣的讨论。
同时，整个Scrum团队的水准需要相对平均，并有着强烈的责任心，才可能让各种讨论发挥应有的作用，才可能出现主动承担任务的理想状态。
而这样的人，在国内大部分的公司里，是不太可能出现的。基于种种原因，即使是有这样潜力或能力的人也未必愿意表现出来。
而看板，要求的是必须要抵制住改变工作流程、职位名称、角色及其职责，以及当前在用的具体实践的诱惑。不要试图去改变团队成员与其他合作伙伴、参与者、干系人的内驱力、专业自豪感和自我心理（ego），主要要改变的是在制品的数量、与上下游业务间的接口及交互方式。
让技术团队的成员，业务团队的成员，各个利益相关的成员、团队乃至公司都在无声无息中渐进式变革，这就是看板的成功之道吧。
