如何评价Kanban方法？（软件开发）
有bug追踪系统谁还要看板我用cynthia
如何评价Kanban方法？（软件开发）有bug追踪系统谁还要看板
我用cynthiakanban是拿来做过程改进的，用来发现软件开发过程中的哪一个环节是瓶颈，从而着力解决问题。这个命题太大了，长话短说，最近的感觉就是Kanban根本没办法进行有效的项目管理，即同意 @Antinomy Yang 的观点 只能用来发现过程的中的问题。
因为Kanban没有监督控制进度的机制啊。
但是我也发现Kanban有个好处，我们现在的team是单一技能多项目团队，Kanban至少在多个项目和资源管理上是有一定效果的。总体上我不太看好看板在软件开发里的应用，价值有限，不如 Scrum。
软件开发不是汽车生产
丰田的看板：
Kanban
现在敏捷开发里用的看板，其实并不是丰田的看板，差距很大。
起源于 1950 年代的丰田看板系统（或方法）是用于生产制造系统，从消费端（如零售店）来拉动（pull）生产部件、零件的实时流动，通过看板（卡片）的记录和传递，可以发现整个生产制造流程的瓶颈，尽可能减少各个生产、仓储环节的库存和浪费，从而实现 JIT（Just-In-Time，即时）与精益（Lean）生产和制造。这确实是一种了不起的思想方法，几十年来在生产制造领域被证明是行之有效的。
然而，软件开发，尤其复杂的系统设计（Design）和研发，是生产制造（Production）么？这个我们应该先搞搞清楚，Design 与 Production 不是一回事吧。
设计与生产最大的区别在于：在生产环节，比如汽车的制造量产，几乎整个流程的所有细节都是明确、固定的，具有普遍的确定性（centainty）；而复杂软件开发，由于处在设计阶段，存在大量的不确定性（uncertainty）。
软件看板与丰田看板的区别
以下是几张经典的丰田式看板卡片（Kanban or Kanban card）：
上图的看板卡片是 Seton 公司销售的商品，旁边的一段描述准确地解释了什么是看板：
下图是一张实际的看板：
丰田看板主要是用来在整个产品供应链（supply chain）中让上家零部件供应方向下家需求方供货的，请求供货部件的名称、数量（QTY）和供货时间期限（约束，Lead Time）等是其中的重点信息。
再来看一下敏捷软件开发中的看板（简称软件看板）：
上图其实是看板板，而上面摆放的各种软件看板其实就是用户故事卡片（user story cards）和故事分解后的任务卡片（task cards）。
问题来了，软件开发的任务卡片或故事卡片与丰田看板（卡片）是一回事吗？
结论
。。。没有银弹。看板在研发过程中有它的价值，但也不应该把看板当成一个框，什么都往里面装。scrum是管理
XP是软件开发办法
看板不是一套方法论。只是在你已有的方法论系统上如果出现了问题，通过看板来发现问题，然后解决。理论是，通过看板来发现问题积压在哪个环节了，消除浪费。
消除浪费，消除浪费，消除浪费。
和有没有bug追踪系统无关。我感觉看板方法挺不错，让工作流动起来，专注完成！首先，我赞了张恂的答案，他的回答是不错的。我的意见比较相似，补充一些如下：
如上是我对看板方法作为一种方法论、一种主张的疑问，这不代表我反对看板方法里面的那些具体实践。欢迎看板专家看到这个答案之后和我联系交流，我非常愿意学习和了解更多看板方法，以及其他人对看板方法的看法、理解和经验，查看我的知乎个人档案，可以找到我的联系信息。关于专业的第一答
现在的project正好从Scrum转型到了Kanban或者说是Hybrid模式。
各位老师之前的答案中好像没有怎么提到Scrum和Kanban比较重要的一个不同，那就是Scrum是有时间框架的(sprint)，是对要开发的产品有一定掌控并且可以做一段时间的计划的(sprint planning)。而Kanban的精髓在于有limit in WIP但是不在乎backlog的动态性，这种属性对于BAU work, bug fixes这种你基本不能作出什么靠谱的计划只能来一个对付一个的工作来说就非常好用了。
比如我们现在的project到了最后测试阶段，各个team都在support UAT，但是在sprint planning的时候你根本就不知道有多少个bug会出现，所以把这种support搞成一个user story就有点牵强。但是用Kanban的话，即可以不让team over commit (有WIP limit), 又能很容易的看到瓶颈在哪里，还能督促Product Owner去更好的做prioritization.
不好意思人长时间在国外，接触agile也是在国外所以有些词不知道怎么用中文表示比较准确。欢迎大家讨论。看板在精益生产中是为了控制在制品库存、平衡生产线以及促成拉式生产的，你们程序猿也有这问题？关于看板的起源：
看板（Kanban，来源于日语）最初是丰田汽车公司的大野耐一于20世纪50年代发明的；当时是从超级市场的运行机制中得到启示，将看板作为一种生产、运送指令的传递工具而被创造出来的;这个看板管理当时跟JIT（Just In Time）结合构成著名的丰田生产方式（TPS—-Toyota Production ）。也就是凭借这个TPS，丰田完成了从“全日本第一”到“全世界第一”。
经过60多年的发展和改进,今天所谈的看板管理大多是指精益看板之父 David J. Anderson 发扬的管理方法，它既继承了丰田体系的精髓，又增加了诸多针对现代团队，企业管理非常有益的看板实践方法。现代化的看板系统始于2004年,最早是在微软的XIT软件维护团队中实施（当时的看板系统还使用了电子化的跟踪工具），得益于这个先河性的看板系统实施, 微软的XIT团队在生产率上有了超过200%的 提升,前置时间减少了90%,在可预测性上也有了大幅 提升。
看板管理有哪些优势：
通过使用看板系统,我们可以将团队的在做任务（work-in-progress）限制在一个设定的能力阈值内,根据已完成任务的交付速率来平衡 交给团队的工作需求(demand on the team)。这样做可以获得可持续完成任务的步调,让所有人都可以实现工作与生活之间的平衡。
正确的流程、良好的纪律性、强有力的管理及良好的领导力,这些因素加在一起,才是一个团队能做好事情的根本。并非只有拥有最好的人才才能产出世界一流的成果 。团队的信任与默契程度对于结果的影响往往到大于团队中个人的能力。
如上图所示，团队协同工具Worktile 让工作更简单 本身 也正是得意于这种信任与默契的产物，这一切都是受益于看板管理。所以我们现在做的就是希望将这种行之有效的方法，这种简单高效的工作理念与大家一起分享。
我用cynthiakanban是拿来做过程改进的，用来发现软件开发过程中的哪一个环节是瓶颈，从而着力解决问题。这个命题太大了，长话短说，最近的感觉就是Kanban根本没办法进行有效的项目管理，即同意 @Antinomy Yang 的观点 只能用来发现过程的中的问题。
因为Kanban没有监督控制进度的机制啊。
但是我也发现Kanban有个好处，我们现在的team是单一技能多项目团队，Kanban至少在多个项目和资源管理上是有一定效果的。总体上我不太看好看板在软件开发里的应用，价值有限，不如 Scrum。
软件开发不是汽车生产
丰田的看板：
Kanban
现在敏捷开发里用的看板，其实并不是丰田的看板，差距很大。
起源于 1950 年代的丰田看板系统（或方法）是用于生产制造系统，从消费端（如零售店）来拉动（pull）生产部件、零件的实时流动，通过看板（卡片）的记录和传递，可以发现整个生产制造流程的瓶颈，尽可能减少各个生产、仓储环节的库存和浪费，从而实现 JIT（Just-In-Time，即时）与精益（Lean）生产和制造。这确实是一种了不起的思想方法，几十年来在生产制造领域被证明是行之有效的。
然而，软件开发，尤其复杂的系统设计（Design）和研发，是生产制造（Production）么？这个我们应该先搞搞清楚，Design 与 Production 不是一回事吧。
设计与生产最大的区别在于：在生产环节，比如汽车的制造量产，几乎整个流程的所有细节都是明确、固定的，具有普遍的确定性（centainty）；而复杂软件开发，由于处在设计阶段，存在大量的不确定性（uncertainty）。
软件看板与丰田看板的区别
以下是几张经典的丰田式看板卡片（Kanban or Kanban card）：
上图的看板卡片是 Seton 公司销售的商品，旁边的一段描述准确地解释了什么是看板：
- Kanban card system is specially designed to record movements of materials through a process, increasing productivity
- Kanban is a visual signal to trigger an action
- The Japanese word "kanban" is loosely translated as ?card you can see?
下图是一张实际的看板：
丰田看板主要是用来在整个产品供应链（supply chain）中让上家零部件供应方向下家需求方供货的，请求供货部件的名称、数量（QTY）和供货时间期限（约束，Lead Time）等是其中的重点信息。
再来看一下敏捷软件开发中的看板（简称软件看板）：
上图其实是看板板，而上面摆放的各种软件看板其实就是用户故事卡片（user story cards）和故事分解后的任务卡片（task cards）。
问题来了，软件开发的任务卡片或故事卡片与丰田看板（卡片）是一回事吗？
结论
。。。没有银弹。看板在研发过程中有它的价值，但也不应该把看板当成一个框，什么都往里面装。scrum是管理
XP是软件开发办法
看板不是一套方法论。只是在你已有的方法论系统上如果出现了问题，通过看板来发现问题，然后解决。理论是，通过看板来发现问题积压在哪个环节了，消除浪费。
消除浪费，消除浪费，消除浪费。
和有没有bug追踪系统无关。我感觉看板方法挺不错，让工作流动起来，专注完成！首先，我赞了张恂的答案，他的回答是不错的。我的意见比较相似，补充一些如下：
- 首先要确定大家说的是同一个东西：软件行业说的看板方法，是David J. Anderson所著书籍《看板方法 (豆瓣)》那个
- 这个看板方法号称融合了精益思想、TOC约束理论和敏捷的实践
- 从该方法的主张来说，他们认为自己并没有主张具体的看板板格式，但实际上以他们的主张切入企业时，由于他们并不要求改变企业当前的流程，而是把当前的流程记录到看板板上，所以会导致看板板上就是类似于瀑布的那种阶段移交式的样子。
- 我最大的困惑或者说怀疑在于：在生产制造行业，由于其质量控制的特点，通常在发现缺陷时，都是搁置或直接抛弃该缺陷零部件，使用下一个零部件即可，不大存在为了产出某个价值，重复返工该价值所设计的某个零部件的情况。然而对于软件行业来说，要产出价值（软件功能），当我们发现缺陷时，我们无法或极少会搁置、抛弃该零部件（例如，废弃该段代码，重新开发），然后在看板板上的流程中向后返工，例如从测试进入开发再返工，这是两个行业的本质区别。
- 当然，很多看板方法专家会说，当价值进入例如测试阶段发现问题，需要重新修改代码时，卡片仍然停留在测试栏，然后开发人员要去协助测试人员解决该问题，并强调这是看板方法所需要的一种共同解决问题的理念。然而例如我们对比Scrum框架，该框架的要求不是在出现问题时，而是一直都需要是团队共同前进、共同解决问题，这种做法不是更好吗？而且如果是停留在测试栏，等待开发人员协助解决，那么双方的绩效度量如何做呢，这个情况是开发没做好，还是测试没做好？开发没做好那为什么还要留在测试栏位？如果是测试问题，那么回退返工这个问题在看板方法里如何解决？如果强调团队协作，为何不从始至终强调，而只是在出现问题的时候强调？
- 如果我们说强调协作，大家一切解决问题，那么开发、测试等各种职能不需要做太多区分的话，等同于把看板方法所提倡的那种看板板进行调整，各职能在看板板上的体现 -- 也即那些阶段全部收拢（因为人员都收拢，一起协作了，那么区分阶段也没有太大意义了）的话，那就只剩下需求栏、进行中栏、完成栏，那这不就是Scrum所提倡的任务板吗？那么看板方法与众不同的地方，使得它不是其他方法的地方到底在哪里呢？
如上是我对看板方法作为一种方法论、一种主张的疑问，这不代表我反对看板方法里面的那些具体实践。欢迎看板专家看到这个答案之后和我联系交流，我非常愿意学习和了解更多看板方法，以及其他人对看板方法的看法、理解和经验，查看我的知乎个人档案，可以找到我的联系信息。关于专业的第一答
现在的project正好从Scrum转型到了Kanban或者说是Hybrid模式。
各位老师之前的答案中好像没有怎么提到Scrum和Kanban比较重要的一个不同，那就是Scrum是有时间框架的(sprint)，是对要开发的产品有一定掌控并且可以做一段时间的计划的(sprint planning)。而Kanban的精髓在于有limit in WIP但是不在乎backlog的动态性，这种属性对于BAU work, bug fixes这种你基本不能作出什么靠谱的计划只能来一个对付一个的工作来说就非常好用了。
比如我们现在的project到了最后测试阶段，各个team都在support UAT，但是在sprint planning的时候你根本就不知道有多少个bug会出现，所以把这种support搞成一个user story就有点牵强。但是用Kanban的话，即可以不让team over commit (有WIP limit), 又能很容易的看到瓶颈在哪里，还能督促Product Owner去更好的做prioritization.
不好意思人长时间在国外，接触agile也是在国外所以有些词不知道怎么用中文表示比较准确。欢迎大家讨论。看板在精益生产中是为了控制在制品库存、平衡生产线以及促成拉式生产的，你们程序猿也有这问题？关于看板的起源：
看板（Kanban，来源于日语）最初是丰田汽车公司的大野耐一于20世纪50年代发明的；当时是从超级市场的运行机制中得到启示，将看板作为一种生产、运送指令的传递工具而被创造出来的;这个看板管理当时跟JIT（Just In Time）结合构成著名的丰田生产方式（TPS—-Toyota Production ）。也就是凭借这个TPS，丰田完成了从“全日本第一”到“全世界第一”。
经过60多年的发展和改进,今天所谈的看板管理大多是指精益看板之父 David J. Anderson 发扬的管理方法，它既继承了丰田体系的精髓，又增加了诸多针对现代团队，企业管理非常有益的看板实践方法。现代化的看板系统始于2004年,最早是在微软的XIT软件维护团队中实施（当时的看板系统还使用了电子化的跟踪工具），得益于这个先河性的看板系统实施, 微软的XIT团队在生产率上有了超过200%的 提升,前置时间减少了90%,在可预测性上也有了大幅 提升。
看板管理有哪些优势：
通过使用看板系统,我们可以将团队的在做任务（work-in-progress）限制在一个设定的能力阈值内,根据已完成任务的交付速率来平衡 交给团队的工作需求(demand on the team)。这样做可以获得可持续完成任务的步调,让所有人都可以实现工作与生活之间的平衡。
看板也为质量和过程中出现的问题 供了可见性,使得缺陷、瓶颈、变异性以及经济成本等因素 对工作流与交付速率的影响变得更明显。单就使用看板来限制在做任务这一做法,就能促成更高的质量和更高的效能。流程改进和更好的质量结合在一起,有助于缩短前置时间(lead time), 提高预测性和准时交付能力。
通过看板建立团队稳定的任务节奏,实现始终如一的可靠交付,这能够帮助团队与客户、依赖的相关部门、供应商、价值流下游合作伙伴建立信任关系。而信任关系对每一方都是非常重要的。
然而看板方法最诱惑的在于：她提供了一种工具,让我们可以解释(和辩护) 为什么与众不同更好,为什么在那种情境下某种与众不同的选择才是更正确的选择。
正确的流程、良好的纪律性、强有力的管理及良好的领导力,这些因素加在一起,才是一个团队能做好事情的根本。并非只有拥有最好的人才才能产出世界一流的成果 。团队的信任与默契程度对于结果的影响往往到大于团队中个人的能力。
如上图所示，团队协同工具Worktile 让工作更简单 本身 也正是得意于这种信任与默契的产物，这一切都是受益于看板管理。所以我们现在做的就是希望将这种行之有效的方法，这种简单高效的工作理念与大家一起分享。
Kanban方法最初起源于丰田的JIT（Just In Time），之后作为一种高效管理软件开发流程的技术和思想应用于互联网行业。Kanban方法以价值流动为核心，不断发现团队中的瓶颈工序，进行改进，使价值流动更加顺畅和快速。可从以下几个维度参考：
一.实施过程中关注核心
Kanban方法在实施的过程中更多关注的是可视化的价值流动，从几个维度解释下：
- 拉动式生产，下游工作完成后，主动拉动上游的任务移动
- 限制WIP（work in progress），明确设定限制每个状态下，同一时间内有多少工作量，减少同一状态同一时间内，任务和价值的堆积。
- 可视化的价值流动通常是端到端的流动，直观的反映用户的价值（通常是可交付的用户需求），并且反映出在价值流动过程中的瓶颈和问题，不断为团队改善提供依据。
二.限制WIP数量的方式
Kanban方法限制直接，同一状态同一时间内的工作任务有最大限制。
三.对任务变更管理
在Kanban方法的中，下游任务完成后，即可拉动上游任务下移，同时，只要生产力允许，即可新增需求。
四.改进依据
Kanban方法是使用生产周期作为计划和过程改进的依据。
以上答案来自我厂屈鹏飞老师的博文巧用Scrum与Kanban
网易云免费体验馆，0成本体验20+款云产品！
更多网易研发、产品、运营经验分享请访问网易云社区。
责任编辑：
