有很多人问我Scrum和Kanban之间的区别是什么？他们分别运用在什么场景？我们可以很轻易的说出他们的不同点，比如Scrum更多的是用适应性的循环交付价值，而Kanban更多的是一个流的系统来推动价值交付。那么为什么我们不能更广泛的把两者的特点结合呢？答案是Yes。
那么今天我首先给大家讲一讲Kanban的四大基本要素。
WIP是有多少工作任务已经开始，但是还没有完成。简单说就是还有多少任务还在pending中。明显的如果有过多的停滞的工作，势必会影响到大家完成它们的效率。
无可厚非，敏捷项目的最终成败与看板本身是物理的还是电子的没有直接关系。所以本文不是讨论敏捷项目的成败，而是讨论：如果你用了看板，那么哪种看板更适合你？ 笔者基于辅导过的上百个敏捷团队的经验做了一些总结。
物理看板的优势。物理看板在一定的历史背景下确实发挥了很大的作用，大部分的敏捷教练一开始也是推荐物理看板，笔者也是建议一开始使用物理看板。
看板管理，常作“Kanban管理”（来自日语“看板”，カンバン，日语罗马拼写：Kanban），是丰田生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具。及时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。 在看板标示系统中常将塑料或纸制成薄板，将产品名称及数量写于其上，故此得名。及时生产方式的看板在生产线上分为两类：领取看板和生产看板，旨在传达的信息是：“何物，何时，生产多少数量，以何方式生产、搬运”。 看板的具体信息包括：零件号码、品名、制造编号、容器形式、容器容量、发出看板编号、移往地点、零件外观等。 Read more →
敏捷软件开发的神话之一在于它不需要文档，或者说文档并不实用。确实，可工作的软件胜于文档是敏捷宣言的核心价值之一。但是，注意句中的“胜于”一词。宣言并不是说不需要文档，而是说比起文档来说，可工作的软件更好。它的目标在于去除系统中的糟粕，取其精华来提升其价值。 Read more →
上篇文章说了QA与QC的区别，以及一种不太好的流程所造成的浪费，这篇对我所在团队的状况进行反思。
为什么这么多bug？
1个月200多个，按工作日平均下来1天10个，触目惊心。我认为原因很多，列举如下： Read more →
如果QA总是在Verify的阶段发现缺陷。那么有缺陷的不仅是你的软件，更是你的流程——Mary Poppendieck。
有一家很糟糕的餐厅，里面的厨师几乎总是把盐放得过多。顾客少的时候，他炒好菜会自己尝一下，发现太咸了，就再倒回锅里再加工一下；顾客多时，就不管那么多了，直接上菜，然后等不能忍受的顾客把菜拿回来，再加工，而就算那些能忍受的顾客呢，下次也不会再来了。
这样的餐厅有见过吗？我是没有，只见过偶尔放错盐的，没见过这么天天放太多盐的。
但是这样的软件公司，却一大把，他们天天都在重复着下面的故事：
1， BA分析好需求。
2， Dev开始默默写代码，同时QA开始默默的设计Test Case。
3， QA测试Dev完成的东西。
4， 发现defect，打开defect跟踪软件，提交一条defect，并assign给相关Dev。
5， Dev看到有assign给自己的defect，open它、修复它、再把Defect Assign回给QA。
6， QA发现有fixed的defect，问Dev，这个修复已经打包了吗？可以测了吗？得到肯定答复后，开始测试。
7， 一般来说，测试是会通过，于是这个需求终于做完了。如果还是没通过，重复3—7。
有问题吗？跟餐厅一样，看情况。
如果没有或极少defect，那从1到3，就结束了，没什么问题。
如果defect很多、或者有些defect一次没修完、或者defect在今天修复，明天又重现，那么问题就太严重了——我们将在3到7循环很多次。
QA不是QC
关于QA，我们全搞错了！很多公司的QA，其实都是做着QC的活。那么QA和QC的区别是什么呢？维基百科里QC的词条里有一句概括:
Quality control emphasizes testing of products to uncover defects, and reporting to management who make the decision to allow or deny the release, whereas quality assurance attempts to improve and stabilize production, and associated processes, to avoid, or at least minimize, issues that led to the defects in the first place.
简言之，QC的工作重心在于发现defect，QA的工作重心在于预防defect。怎么预防呢？通过“改善和稳定生产、以及相关的流程”。文章开头的7步流程需要改善的地方，这是QA的职责和价值所在。
Lean
把生产领域中的Lean介绍到软件开发领域的Mary所著《Lean Software Development》一书中说：
如果你总是在Verify的阶段发现缺陷。那么有缺陷的不仅是你的软件，更是你的流程。
那么上面的流程究竟有什么问题呢？首先它存在太多的不必要的浪费，Lean第一原则就是“消除浪费”，Mary的书中介绍了7种软件生产中的浪费：
看看我们的流程：
7种浪费，几乎全占满了。
注：我的良师，中国敏捷软件开发实践的先行者之一，目前亚洲唯一一个CSC(与有荣焉)，曾告诫我说，不是所有浪费都要消除，比如Sprint中的Slack，松弛时间，就是一个好的敏捷实践；又比如，重构也是必要的浪费。但我觉得，对于一些浪费太多的组织，怎么强调“消除浪费”都不过分。
改进的流程
对于文章开头的流程，如果我们希望到第3步就结束，那也许会有很多需要改进的地方，比如代码质量、设计能力……，而从流程上，那么很重要的是第2步。
回头想想餐厅的例子，对于那个炒菜总是太咸的厨师，会有什么建议呢？很简单，我会建议他不要再炒完菜后才对放盐量进行检测，那已经太晚了，应该在事先制定一个大致的放盐标准（可以借助工具——勺子、经验、和其它厨师的交流……），以最大程度降低菜太咸的概率。
所以第2步里，QA设计Test Case和Dev写代码的行为，都不能“默默地”去做。QA不是到验证的时候才是主角，QA一开始就是主角。测试不仅是炒完菜后去尝，测试是QA在前期参与到Dev的开发工作中去，是与Dev沟通需求的验收条件，是提供QA的专业视角，帮助Dev开发出几乎没有defect的软件出来。
QA和Dev一起做完大餐后，要进行的除了一些探索性测试，只是验证一下放盐标准是否恰当而已（不恰当？改善它。）
下篇将从此篇理论出发，反省一下我所在团队Kanban的用法，顺便说说TDD。
多年来，我们一直使用PivotalTracker作为我们的敏捷软件开发流程管理工具。一直以来我们都对PivotalTracker非常满意。无论什么时候，只有我们有新的想法，无论想法有多抽象多模糊，我们都把它写成Epic记录在系统的Tracker里面。当我们准备开始要实现这个想法的时候，我们通常会把它分解成更加详细的用户故事。一旦我们的用户故事足够涵盖到这个想法的所有内容的时候，我们就把这个Epic删除。然后，我们会把这些用户故事打上这个Epic的标签，这样我们就知道它们是从哪里来的了。
Read more →
如今在大多数的软件开发组织中，没有专门的维护工程（SE）团队来关注已发布产品的维护和支持。工程（研发）团队除了完成产品的功能开发外，要花费同样的时间来完成维护任务。然而，支持服务品质协议（SLAs）的维护支付的客户通常都很严格，所以比起研发，维护工程经常有更高的优先权。然后遵循scrum的工程团队由于维护工程问题的大量涌入以及对于迅速解决问题的需求，他们无法成功地递交承诺的功能。在功能开发和修改bug中挣扎反作用于团队士气和工作积极度。
以下基于scrum的选择是由小组成员提出建议来克服在这些情况下发生的问题的。 Read more →
Scrum-ban是一个Scrum和Kanban的开发模型。Scrum-ban尤其适合于那些维护的项目或者经常会有用户故事变更或程序错误的项目和系统。在这些项目中，Scrum模型中规定时间的sprint显然就不能够满足项目的需求了，但是Scrum中的每日站会和其他一些工程实践还是可能根据团队的情况加以运用。可视化的工作进度和对未完成的并行用户故事和任务的限制都是Kanban的法宝，通过这两样法宝，能够指引团队以最少的时间完成用户故事和修复程序错误以及保证团队每个成员都能持续地投入到工作中。
为了能够清楚地展示工作的每个阶段，在同一个地方工作的团队通常会使用便签纸或者一块大的白板。而分布式团队通常会使用工具软件，如Assembla，ScrumWorks或者安装上GreenHopper的JIRA来帮助团队更好地了解各个用户故事、缺陷和任务所处的状态。
最简单的办法就是把任务或者用户故事划分成以下三类：
候选
进行中
已完成
如果有需要的话，团队可能添加更多的状态，例如，“已定义”，“完成设计”，“完成测试”或者“已交付”等等。划分更细的状态能够帮助团队在遇到瓶颈又不能改变并行任务的最大限制的时候更有效地解决问题。同时，更具体的任务状态划分也能够使团队成员更专注在特定的工作环节上。
对于最大并行未完成工作的数量并没有一个通用的值，每个团队需要根据自身的情况来设定。如果这个值设得太小，有可能会导致很多团队成员有太多的时间在空闲状态；如果这个值设得太大，那么就有可能会在同一时间出现大量的未完成的工作，从而导致每个任务完成的时间大幅上升。这里给出的建议是，每个团队成员同一时间不能进行超过两个任务，另一方面在同一时间所有团队成员不能都有两个任务。
Scrum和Kanban最大的不同就是，Scrum把工作划分成固定长度的周期——sprint中，而Kanban则以持续工作的方式进行。从表示任务状态的表格来看，Scrum会在每个spirnt把表格清空，而Kanban则一直沿用同一个表格。从团队组成来看，Scrum强调的是跨职能团队，团队成员需要是多面手，而Kanban则更强调专职团队。
由于Scrum-ban是新的开发模型，因此并没有太多的参考资料。就目前来看，Kanban至少已经被Microsoft和Corbis采用了。
几天前，我就Matthias的关于Scrum强制团队只能在sprint结束之后才能发布，而Kanban则更灵活的帖子发表了看法。
我想知道Scrum和Kanban的不同，我很疑惑为什么有人抱怨Scrum把规则定得太死，不够灵活等等。于是，我参加了David Anderson的Kanban中级课程。
结果，David的课程让我大开眼界。David表示Kanban并不是去改变什么东西，而只是将工作流程可视化和将隐藏的政策公开讨论而已。Kanban通过加入并行任务的限制，使得公司需要进行的改变慢慢地涌现出来。David说Kanban和Scrum的不同就在于，Kanban所引起的改变是自发的，Scrum引起的改变是被动的。革新由于革命。
首先，我要承认的是我真的非常喜欢精益的思想。我对David能够把这种思想融入到软件开发中感到十分敬佩。有趣的是，和我一起上课的人里面有人把我认出来了，而且他们觉得很奇怪，我明明是Scrum的支持者，为什么我会出现在这里呢？
从1994年起，我就开始相信学习精益理论非常有用。当我在2002年知道Scrum以后，我就确信Scrum能够处理精益理论解决的问题。我认为David这种优雅地将精益思想引入到软件开发世界中来的方法是朝着正确的方向迈出了坚实的一大步。
但是，在这课堂中十分困扰我的是居然没有人提及一些在我讲授的课程里经常提及的问题，例如：
如果大家愿意创建任务版怎么办？
如果团队成员之间不想合作怎么办？
如果大家不想坐在一起怎么办？
如果管理层反对这样的工作方式怎么办？
我该怎么样创建一个发布计划？
我该如何计算出项目成本？
我见过有些人没有成功连续完成3个Sprint，经常找不到Product Owner，或者团队经常被打扰的问题无法解决。然后，这些人就说Scrum没有办法解决这些问题，Kanban才是更好的解决方案。恕我不客气地说一句，就在Kanban倒在无数无法解决的问题前的时候，Scrum的支持者们已经给这些问题提供了解决方案。
今天，Scrum的实践者们已经懂得了如何：
管理大型项目
解决大型团队的问题
解决团队之间的依赖关系
使用Scrum构建大型架构的框架
在项目开始之前计算项目成本
快速有效地进行估算
还有很多很多
在David的一本书中解释的著名的“泳道”模式，是为了管理大型企业的模式。这个模式是我2004年在德国WEB.DE的时候为4个Scrum团队发明的。直到今天，我还在用这种模式来管理180人的团队。从2005年起，我在我的所有课程中都会解释这种模式。
但是，无论是Scrum，还是Kanban，还是ASD，还是Crystal都无法解决下面的这个问题：人们害怕改变，尽管他们已经看到问题所在。很多人，包括Scrum Master，都需要一个领路人来让他们变得更好。
使用Kanban，Crystal或者ASD的人都必须说服他们的团队或者管理层他们建议的方法是真正能够带来改进的。Ken Schwaber总是说：“行动才是最好的证明。”我必须承认的是，我也不大明白，David能够让人相信使用他推荐的方法，而不是单纯他们自己本身的能力能够解决问题。
我认为David就是一个天才，一个天生的领导者。我承认以他提倡的方式开展一个新项目会比使用Scrum看起来更加简单。Kanban可能在某些环境中更加有效，当然我们也可以在实施Scrum的时候使用Kanban中的某些方法。
其实，Scrum，Kanban，Crystal和ASD在核心上是非常类似的：找出障碍和问题的来源，然后有针对性的行动。
我的建议是按照你认为能够符合你当前情况的方式进行。你可以先使用Kanban然后在其中应用一些Scrum的内容，或者先使用Scrum然后在其中应用一些Kanban的内容。例如，为任务定义Service Levels是解决分组工作的很好的办法，或者让循环周期可见度更高。这些都是对Scrum很有用的补充。
我所关心的是，我们想要改变我们公司成员的工作方式。我们想要给他们授权，我们想要让他们高兴和给他们最好的，因为他们热爱他们所做的事情。
然而，更常见的是，在很多Scrum团队中，有的人默默离开，有的人行为根本不像成年人，有的人只愿意被动地接受别人指派的任务。正是这些人，通常会在我的课程里面问类似“我们真的有必要分割任务吗？如果我们不能完成所有用户故事怎么办？如果一个用户故事本应该是8个故事点而被估成5个点怎么办？”的问题。
我认识很多Scrum实施顾问经常会把他们的客户引导这些问题上面来，因为他们只懂得回答这些问题，或者更不幸的是，他们害怕使他们的客户面对更加麻烦的流程问题。这些顾问败坏了Scrum的名声，因为他们不敢向他们的客户提出一些有可能让他们感到不自在的问题。于是，为了保住他们的客户，他们选择了沉默。
当然，有时候我们会损失一些客户。因为客户对我们呈现出来的真相感到恐惧。我们并不迷信Scrum，我们只是做我们认为对的事。我们是很务实的！我们坚持真相和让事情更透明。那是因为Scrum虽然简单，但是却很难用好。
作者:Boris Gloger
原文地址：http://www.agileweboperations.com/scrum-or-kanban-it-does-not-matter
