本期继续暨上一期对上一次Lean and Kanban China Meetup现场问题的解答 ，汇集了看板方法的问题。
Q: 有了看板方法，团队如何更好地共同合作呢？
A: 看板是团队上下游之间很好的合作框架。简单列举一种常见场景：
每日站会上，很多工作项堆在“测试中”状态栏，已经到达了该状态栏的WIP上限。这时候，按照传统的工作方式，开发人员会继续拿新任务开发，扔给测试人员测试。但是在看板里，如果开发人员忽略测试瓶颈，不断拿新任务开发完成，由于“测试中”状态栏任务量已经达到WIP限制，所以开发完成的任务是无法流到下游“测试中”状态栏里。记得接力棒的寓意，团队最高目标是尽快交付有价值的工作项。所以这时明智的决定是，开发人员不要拉动新任务，反而应该去帮助测试人员。如果不合作，“开发”状态栏也会很快达到了WIP，如图所示，开发人员即便闲着，没有办法再拉动新任务，所以这时必须帮助解决测试问题，让工作项流动下去。
Q: 能将 Scrum和看板的区别，优缺点对比一下吗？
A: 这是第二次Lean and Kanban China Meetup的内容之一，欢迎大家参加。这里可以简单解释一下：
-
最跟本的区别是在变革方式不同。 Scrum属于改革性变革，需要根本改变组织的架构、角色、流程、文化。看板属于渐进式变革，初始要尊重组织现有的架构、角色、流程、文化，通过识别瓶颈、工作不均、浪费，度量任务周期时间实施增量渐进式变革，逐步打造组织的持续改进文化。
-
关注点不同。scrum关注每个迭代完成的增量都是是潜在可交付给客户的。看板着重在工作流的管理，努力是工作项平滑流动，以持续缩短有价值工作项的周期时间为最终目标。
-
流程不同。Scrum框架比看板有更多规则（三个角色，五个事件，四个工件），把事件、角色和工件绑在一起，控制着它们之间的关系和交互；看板更灵活一些， 六大实践由浅入深。业界团做scrum but的团队很常见, 很少见团队在做kanban but. 但是看板应用有浅深之分，六大实践用得越多，越彻底，看报的应用就越深些。
但是二者也有很多共通性。不管Scrum还是看板，都是流程工具，各有所长。泛泛地比较比较二者哪个好，没有意义，团队或组织可以根据自己项目的需求，选择不同的工具方法，或结合使用成Scrumban。
Q: 任务大小不同，如何估算平均周期时间 (lead time) 呢？
A: 在看板里，估算不是必须的， 而是依据不同的类别的工作项，设定目标周期时间。目标周期时间的设定是根据长期的历史统计得出。
根据统计过程理论，对于某一类工作项，尽管其大小有所不同，但是在长期的时间内，如果过程没有变化，团队切分任务的方法没有变化，其周期时间是在一定上下限内浮动的。但是如果任务大小差别过大，会导致周期时间浮动的上下限范围过大，造成项目可预测性差。 看板强调提高系统的可预测性，也要求将任务切分，比如大的Epic切分成 story，等，如果同时保留Epic和story两个类别，设置 目标周期时间和统计平均周期时间时要区别对待。
Q: 看板遵循的是什么样的节奏呢？
A: 看板是以事件为驱动的，发布计划、部署上线、过程改进活动可有各自的节奏，不排斥像scrum那样都以一个sprint为单位，但原则是将不同的活动解耦，不一定都遵循一个节拍，甚至可以按需做部署上线和发布计划。
Q：敏捷有个价值观：individuals and interactions over processes and tool．看板是不是强调了流程，弱化了人的主动能力和协作呢？
A: 这是对看板的误解。 看板的精髓思想是精益，精益的一大基石就是”Respect People”。
看板流程是轻量化的经验式流程，在WIP限制下团队不密切合作最终会导致生产线停滞；看板鼓励从下向上的领导力，每日站会上，大家主动识别系统瓶颈、浪费、工作量不均等问题，不需要某个领导来指挥；对于识别出的问题，自发启动会后讨论，马上解决。所以，反之，看板强化了团队的主动和协作。
网友评论