上一次的Lean and Kanban China Meetup活动，现场收集了很多问题，但是没有时间一一解答。选取问得比较多的问题，分期给大家解答，也供所有童鞋学习。 本期着重解答精益基础方面的问题。

Q: 有什么渠道扫扫盲，对精益和看板不懂啊。

A: 精益来源于日本丰田生产系统，看板在丰田生产系统里作为实现拉动式生产的工具。在生产行业看板已有几十年的悠久历史。看板方法涌入软件行业是近些年。很多软件人误以为看板就是scrum任务板，每天站会上看着，就是看板J。 请跟踪我们的微信公共帐号 精益和看板，参加我们的社区活动lean and Kanban China Meeup (每两月一次)。一些大会也有看板案例的分享，还有会前培训、公开课等。这些信息都会在微信公共帐号里发布。

Q: 在制造式生产业，如何推行精益，会带来什么价值呢？

A:  精益生产管理，是一种以客户需求为拉动，以消灭浪费和不断改善为核心，使企业以最少的投入获取成本和运作效益显著改善的一种全新的生产管理模式，其价值已被业界广泛认可。在生产制造业目前有两种系统广泛推行：精益生产系统，精益六西格玛系统。在软件行业有一个误解，认为精益从生产制造业来，所以对软件行业也不适合。其实，在精益生产系统之上发展的精益思想和精益管理原则在各个行业广泛应用，如产品开发、医疗、政府、服务行业，软件等。很多敏捷元老从精益生产系统得到灵感，发展了敏捷方法。

Q: 看板会对程序员自身的工作有什么帮助呢？　

A:  不论什么角色的人，甚至一个非IT行业的普通人，精益思想和看板方法都有是有益的。　有一本在非IT界流行的畅销书《Personal Kanban- Mapping Work Navigating Life》，介绍了个人看板系统只需要两个实践：可视化工作流程，限制work in progress，就能产生巨大作用，　帮助我们在选择启动一件事的时作更明智的决定，有效权衡个人的 时间、精力和产能，安排各种事务的优先级，集中精力完成一件事，再开始下一件。这些对于在软件开发流程中的程序员也是一样的道理。在软件里，看板有六个实践，要多于个人看板（只有两个）的实践，其效果也更明显。比如，可以避免业务向程序员推动需求，赶进度开发；减少程序员多任务切换；鼓励程序员跨职能帮助其他角色的成员，从而有助拓宽个人业务能力；鼓励团队成员自下而上涌现领导力，而不是自上而下指派任务；还提供了一种闭环改进的机制，可以帮助程序员有效识别出系统问题，作出自下向上的改进。

Q: 能讲解一下精益提高项目管理的方法，比如接力棒是如何识别的呢？

A: 这不是如何识别接力棒的问题。接力棒一个比喻来解释精益思想。比如在4*4接力赛跑里，决定胜负的是将接力棒从第一跑者传送到终点的最快的团队，大家都盯着运动手里的棒，没人介意一个人跑的时候，另外三个人站着。按照传统管理方式，这是对资源的极大浪费，传统管理者恨不得人员利用率到100%。想象一个人跑的时候，其他人也在跑，这样接力棒什么时候才能到终点呢？　精益思想对传统管理思想有巨大的挑战，它关注接力棒的价值和周期时间，而不是运动员的利用率。

在软件项目里你可以将接力棒理解为一个有价值的工作项。团队的最高目标是快速交付有价值的工作项，而不是监督工时，追求团队人员的利用率。

Q: 看板的工作流程：analysis->development->testing->Releasing->Done. 貌似看板把人带回了瀑布模型时代。所以，看板是不是适合瀑布开发流程呢？

A: 看板没有规定软件研发工作流程，很多样例里的顺序研发流程analysis->development->testing->Releasing->Done,　是一个样例而已。看板的第一个实践：可视化工作流程，是要求团队理解现在的实际工作流，可视化在看板墙上。决不可以照搬任何 团队、任何教科书上的工作流程，因为那不是你的”as in” 流程。如果可视化后感觉像瀑布，可能是您现有的流程是以工作项为单位的顺序流程。这不是看板的问题，看板只是面镜子而已。

给个比喻， 一个女人照镜子，如果发现自己在镜子里很臃肿，是自己臃肿呢，还是镜子是个哈哈镜？认为看板把人带回了瀑布模型，就是认为镜子是个哈哈镜。

使用看板方法，要求团队基于现有的流程，识别问题，逐步渐进式改进。如果发现现有的顺序开发流程是有问题的，可以做出改变，如引入验收测试驱动开发等，那时你的看板就不像瀑布了。