最近在学习实践精益Kanban办法，结合自己团队实践Srum的阅历，整理些资料二者的差异。相较于Scrum, 我更推重精益Kaban。
Agile是一套理论和准则，就像天边的北极星。Devops是一种软件开发和运维团队间自动化和集成进程的办法。当完结Agile和Devops办法时，Kanban和Scrum供给了办理这些杂乱作业的不同的实践。
简略来说，Kanban和Scrum是进行灵敏开发或项目办理作业的两个不同的战略或许办法论。
- Kanban办法意味着继续性与更好的流畅性。
- Scrum则是依据更短，愈加结构化的作业冲刺。
Scrum：一种结构化的灵敏办法
Scrum源自于橄榄球的一种争球办法。现在作为一种迭代式增量软件开发进程，一般应用于灵敏软件开发。Scrum将作业分解成较小的功用单元，并在周期性固定的时刻段内继续的交给。
- 把安排细分红小組、跨功用、自我安排团队。
- 把作业细分红细小、真实的交给成果，交排人员担任需求清单以及跟据重要性排优先等级，由团队估算每个项目相对工量。
- 把整个开发时刻分红固定时长的短迭代（一般于一至四星期），在每个迭代后演示新增可发布功用。
- 优化发布以及跟客户一同更新优先等级，依据每个迭代后发布的观察。
- 优化进程，在每个迭代之后进行回忆
在咱们考虑考虑选用SCRUM之前，先问自己一个问题：整个开发团队是否是专职团队，而且担任该项目。
SCRUM团队会许诺每个Sprint完毕都会交给产品或许价值。假如你的团队成员有肯能去做其他其他项目，那么SCRUM团队无法许诺每个Sprint的交给。别的，在选择SCRUM时，还需求考虑以下方面：
- 节奏
SCRUM着重的是快速交给，在每个Sprint完毕时交给用户可用的可交给物，每个Sprint一般2周最多4周，有着明晰的开端和完毕时刻。该结构的背面思维是利用短的时刻段逼迫把杂乱使命分解为小的user story.
- 要害方针
衡量一个SCRUM团队表现的要害方针是velocity（功率），即在一个Sprint中交给的story points的数量。该方针用以辅导后续Sprint中能够许诺完结的story points。幻想一下，假如一个团队每个Sprint中均匀完结35个storypoints，那么后续的sprint中咱们不会完结45个story points.
- 应对改动
一般状况下，SCRUM团队尽量不要在Sprint进程中进行规模改动。假如团队经过客户反应发现他们正在开发的功用没有他们以为的那么有价值，这种状况下需求改动该Sprint的开发规模，以便优先交给对客户最优价值的功用或价值。
Kanban：一种继续改善，改动灵敏的进程
Kanban办法开端起源于丰田的JIT（Just In Time），之后作为一种高效办理软件开发流程的技术和思维应用于互联网职业。Kanban办法以价值活动为中心，不断发现团队中的瓶颈工序，进行改善，使价值活动愈加顺利和快速。
**作业流程形象化 **
- 把作业细分红使命，写在卡纸上，贴在墙上
- 把栏命名好，來显示使命在作业流程中的狀況
约束“在制品”（work in progress，简称 WIP）
- 明确设定约束在每个状况下同一时刻能有多少作业使命
度量出产周期（即完结一个使命的均匀时刻），优化开发进程，缩短开发周期和使它更易于猜测。
发布办法
- 看板进程中，软件更新只需完结就能够随时发布，没有一个周期或许提前决议的日期。理论上，看板并不需求预先确认一个时刻点来交给一个使命或许软件更新。假如一个特性完结，不管早晚，都无需像SCRUM进程那样比及Sprint完毕再发布。
人物
- **整个团队对看板担任。**有些团队或许需求一个灵敏教练的人物来协助看板进程的顺利进行，可是不像SCRUM相同，有一个看板master, 来确保每件作业都平稳运转。看板进程中，整个团队相互协作，来担任交给看板上的每个使命。
要害方针
- 循环周期（Cycle Time）是看板进程的一种重要方针。它指的是一个作业项从开发到完毕所花费的均匀时刻。作业项循环周期的改善意味着团队的成功。
看板团队经常用来剖析项目发展状况的作业是累计流图（CFD）。它能够用来表示每个状况下的作业项的数量，然后协助识别出约束作业流的瓶颈。
应对改动
- 看板的作业流可以任何时候进行改动。任何时候都能够添加新的作业项，也能够暂停或删除正在进行中的项目，这一切取决有优先级。而且，假如团队交给才能发生改动，能够从头设定WIP（Work In Progress）约束，作业项也能够被随之调整。
比较不同，探究合适自己的办法
在团队的项目办理实践中，咱们往往将二者的优势结合起来综合的运用，以便协助团队更好的完结方针，而不是为了运用办法而运用办法。
相同点：
- 两者都符合精益和灵敏思考
- 两者运用”拉动式”安排日程
- 两者约束开发中作业数目
- 两者是透过透明度来驱动进程开进
- 两者会集提前及衡常的付运软件
- 两者依据自我安排团队
- 两者要求把作业细分
- 在两个状况下发布方案都是依据经验数据（速度／开发周期）继续优化
不同点：
体系规模
在讨论Scrum和看板之前，有必要澄清体系规模。在Scrum里，体系规模由产品的界说和完结的界说决议；而在看板里，看板体系的鸿沟界说了体系规模。
- Scrum的运作是环绕产品的，每个迭代开端从产品待办列表挑选进入下一个迭代的故事，迭代完毕将故事做到完结。故事的规模是由产品的界说决议的，故事在产品的规模内是端到端的。完结的界说表现的是故事可交给的程度，也就界说了价值流的结尾。
- 看板(Kanban)体系的鸿沟界说了价值流的规模，由此决议故事的规模。故事会流过整个看板体系，其结尾状况完结的界说也就适当于Scrum中完结的界说。
需求指出的是Scrum的体系规模界说一般是依据安排结构的，它涉及到产品的界说和团队的组成，产品待办列表要与团队相对应，因而体系鸿沟相对严厉；而看板的体系规模界说仅仅依据在统一的看板体系做可视化和办理活动，因而体系鸿沟相对宽松。这也跟两者不同的革新导入思路有关。
两者都有一个思维去尽或许地扩展体系规模，以利于办理全体的价值活动和完结。仅仅表现出来的对Scrum而言是产品界说的扩展和完结界说的扩展，而对看板而言是看板体系鸿沟的扩展。
在我看来，不管Scrum仍是看板，都期望协助到价值交给和继续改善，可是它们采纳了不同的办法。最显著的不同在于Scrum选用迭代而看板选用流。
Introduction to Jira Software Boards | Atlassian
价值交给
- Scrum和看板都致力于最大化价值交给，不管是选用迭代仍是流，要害都在于削减在制品。在制品由进行中故事的个数和故事的巨细决议。
- 当选用迭代时，约束故事的个数是直接的，迭代长度直接约束了故事的个数。当选用流时，约束故事的个数却是直接的。
**故事的巨细是另一个影响在制品多少的要素。**迭代会推动故事的拆分，因为在迭代完毕时要求能够将故事完结。然而，把故事拆得过小会使拆分变得不天然（也便是为了拆而拆），反而下降了那些拆分出来故事的价值。故事不能被无限地拆分，一个故事在有价值的前提下能拆多小一般存在天然的约束。选用迭代有或许会人为地破环故事的天然巨细和完整性，而选用流则会更遵循故事天然的颗粒度。
继续改善
**Scrum和看板都致力于继续改善，不管是选用迭代仍是流，要害都在于发明合适的应战来驱动改善。**当改善方针达成后，改善就会陷入停滞，而继续改善却需求永不停歇。Scrum和看板都是经过进步方针来再次发明合适的应战以使改善继续，可是进步方针的办法却不同。
**Scrum里最重要的改善方针是在迭代完毕做到完结。**这儿有两个变量，迭代长度和完结的界说。当经过改善做到迭代完毕完结后，咱们会看完结的界说是否能够扩展。扩展后的完结界说发生了新的应战，然后供给了继续改善的动力。当完结的界说现已到达能够交给时，咱们会看是否能够缩短迭代长度，这又能驱动进一步的改善。
看板的改善方针一方面来自于直接的在制品削减。经过在制品约束的下降，体系中更多问题会被暴露出来，然后驱动改善。另一个重要的要素是环绕前置时刻的改善，前置时刻的缩短对价值交给和进步灵敏性都有协助，因而是很好的改善方针。
革新导入
最终想说说的是关于Scrum和看板的革新思路, 根本在于改善（小改动）和变革（大改动）的平衡。当引进过大改动，由此发生的应战过大，结果拔苗助长。当过于保存引进过小改动，又使改动过于缓慢，甚至逐渐丧失了变革的才能。
Scrum的有用运作需求安排规划，它的第一步在我看来是变革，然后由每个迭代回忆驱动继续改善。看板尊重现有的安排结构，从现状动身，因而它的第一步更挨近改善，然后也是继续改善。对两者而言继续改善理论上引发改善或许变革都有或许，实践中发生更多的是改善。
**当革新涉及体系规模的扩展时，Scrum要求安排结构的改动，而看板要求的最小改动仅仅放在统一的看板上进行可视化办理，因而更能反映“或许的艺术”。**而当现有的安排结构约束了协作模式并最终影响到价值活动时，安排结构仍然需求被打破。
先导入Scrum仍是 Kanban?
从属性上来看:
Scrum 简略探讨不知道，处理杂乱项目，拿来开发新东西威力无比。
Kanban 是教咱们怎么自我反省，能够迅速消除糟蹋，而得到好的效能。
假如你是开发团队，当然是先从Kanban 开端。
先反省团队的根本动作，整理好了再来开端作新的东西，从事开发的动作，天然削减糟蹋。这是精益Lean 的好处。
(有太多开发团队，只晓得一意往前冲刺，忽略了自己在开发上的糟蹋，这会形成很难走得长远，尤其是Startup的团队尤其如是。)
假如你是运维团队，当然是先从Kanban 开端。
视觉化是最大的亮点，团队能够看见作业上的保护流程是一件适当有价值的事，针对个人亦是如此，人们常常因为养成习惯了，就一直继续做相同的作业，很少会有机会回过头来反省，哪里做得糟蹋了应该改善。
看板办法的第一步: 视觉化。正是团队能够拿来继续改善的根底。这一点对保护工做更显得珍贵。
假如你是测验团队，当然是先从Kanban 开端。
看的见以后才能够削减猜测的比例。测验团队在拟定测验方案之前，一定要对待测的产品或程序有满足的了解，才或许写出有用的测验事例，不至于糟蹋很多的测验资源，或做了过多的重复性测验。
你或许觉得古怪，为什么都是Kanban Method 先行呢?
其实原因很简略，因为它”单纯“，不是简略喔! 它没有想像上的简略，因为它能够演进得很有深度，可是它的意图很单纯，便是寻求效能。不像Scrum 的意图，是要来敷衍杂乱的项目开发作业，根本上的方向就彻底不相同的
相较于Scrum, 我更推重Kanban, 因为约束少，推动Kanban的进程自身其实是界说团队流程规矩的进程，不需求特定的人物，简略了解和承受。
将看板办法融入Scrum的开发进程才是上策
看板办法是一种流程操控，他不是一种具有齐备根底的办法学，尽管他的潜在发展适当可观，但目前他仍仅仅一种供给咱们产出高效能的流程操控法罢了。
他缺少需求描绘、没有齐备的会议规划、少了团队职责分配，少了许多许多软件开发上该有的办法，这一点让他看起来非常空泛，但便是这个特性也让他非常合适融入其它开法办法中，尤其是Scrum。
看板办法之父 David J. Anderson 是在Microsoft 公司推广灵敏开发法 Scrum 的时候发明看板办法的。**他原本的意图仅仅要求能够在最少阻力之下顺利在组职中推广灵敏式的开发办法罢了。**却因为他熟悉约束理论的运作而创始了看板办法Kanban Method。做出了对灵敏开发的精益Lean 一支的重大贡献。
也便是这样的典故，让看板办法Kanban Method能够非常简略的融入到Scrum的开发进程。
闻名的《 Essential Scrum 》 的作者Kenneth S. Rubin(它是2013年Amazon 灵敏理论最畅销书)，书中就很多的选用 WIP(Work-In-Process)的观念，实践的运用在作业看板上面。让Scrum在开发流程上削减了许多的糟蹋现象。
看板办法先行
因为它能够削减安排在推广灵敏上的阻力，它能让工程师以最好的节奏继续进行开发作业。又能将精益观念带入团队运作。
融入Scrum的开发进程
因为看板办法的流程操控办法是用来进步Scrum运转时的效能，让 Scrum 能真实用来克服杂乱的软件程序开发进程。
Scrum 的意图在处理杂乱的软件开发作业
许多人误把Scrum 当成加快软件开发的银子弹。这是错的!
它的意图不在加快开发(加快开发作业是开发工具的广告词)，它的意图是在处理杂乱的软件开发作业，让它进步成功率。在协助团队能够供给给客户真实要的产品，且让他在市场上具有实践的竞争力。这一点也正好是看板办法所缺少的。
开发团队千万别因为施行了看板办法而误以为需求把 Scrum 抛弃了，这是一种过错的想法，让他们相辅相成才能有更大的效益。
**先导入 Scrum仍是 Kanban? 二者之间并没有冲突存在，**都是通往灵敏开发的路径，就看你现在最需求的是那相同，那相同就先来吧
- 现已在运用 Scrum 作开发作业的人士，学习 Kanban Method 能够让他们进入精益的范畴，有所依据的继续寻求更好的效能。
- 先学会Kanban 办法 再跨足 Scrum 的人呢? 则能够看到灵敏开发在处理杂乱问题上的具体办法，真实懂得去寻求效能之外的正确性与方向。
实践共享 – 结合事务性质，继续改善，习惯外部改动
依据团队事务状况（服务交给类型），结合自己对两者的了解，以及实践中遇到的问题，画了如下图：
咱们遇到的问题：
- 需求不固定，经常面对随时刺进高优先级需求
- 客户反应需求快速处理，特别是阻塞性的
- 资源严重，担任平台模块多，事务差异较大
探究改善进程
- 紊乱期，团队新组成，需求没有得到有用盯梢
- 建造期，逐渐开端经过Jira盯梢需求，测验灵敏Scrum, 各种站会，评定会，评价故事点等实践，此时外部需求可控，从2周迭代发布（小瀑布）逐渐过渡到随时可发布状况 （伴随着树立了分支模型，分支模型也随之调整了两版，树立了和环境对应的继续交给流水线）
- 问题期，事务压力大，各种Scrum会议感觉作用不大，团队成员不需求参加一切需求评定，PO需求多个事务板块切换准备需求
- 调整期，推动研制人员专职担任某个模块，担任全体迭代把控，拆分红迭代火车，各负其责，把sprin当作一个个专题需求火车
- 改善期，尽管区分了职责鸿沟，可是外部需求/事务添加，积压严重（状况更新不及时），无法从宏观了解全体状况（整个看板都是满的），所以测验运用Kanban办法，整理事务流程，在原有流程不变状况下，明确界说团队协作规矩，制定不同纬度/人物重视的看板，同时树立个人/团队仪表盘，重视动态改动
- 需求看板 – 研制/产品司理重视
- Scrum迭代看板 （专心于内部开发迭代）- 研制同学重视
- 客户问题看板 （区分优先级泳道）
- 缺点看板 – 测验同学重视
- 运维/运营看板 – 包含技术债款，改善，支撑事项等
- 全体大局看板
经过上述进程，团队逐渐向 “自安排“团队演化，”分工有序“，简化花里胡哨的Scrum典礼, sprint变成了事务发布火车（区分迭代规模之用），把整个团队跑迭代变成了2-3人的“按照事务范畴区分的迭代”，放弃了故事点评价（实践证明似乎不太合适咱们），相比于scrum偏重于迭代间的改善，咱们更看重需求交给速度，不期望有挤压，下降外部刺进的需求或事项带来的干扰，让成员更专心。
总结
-
Kanban首要用来可视化你的作业，约束在制品，使其最大功率的活动。Kanban团队聚集在削减花在项目（或许用户故事）上的从开端到完毕的时刻。他们经过Kanban board 来完结它并继续改善他们的作业流。
-
Scrum经过设置称为冲刺（Sprint）的间隔去许诺需求承载的软件开发。它的方针是经过搜集和集成客户反应去发明一个产品的快速学习环。Scrum团队采纳特定的人物，发明特定的工件，执行特定的典礼来保持作业的推动。
| ** |
Scrum | Kanban |
|---|---|---|
| 规划 | 它有固定的方案。它专心于规划。它从 sprint 方案开端，以 sprint 回忆完毕。举办每日会议，以便团队了解接下来的进程、优先级以及从先前进程中取得的经验。 | 它没有固定的方案，也没有举办日常会议。在看板中，随时或许发生改动，即频频发生改动。 |
| 时刻线 | 在 Scrum 中，咱们处理具有固定继续时刻的冲刺，这意味着经过一些固定时刻后，咱们将向客户交给一些东西。 | 看板没有冲刺的概念，因而它没有将产品交给给客户的固定时刻表。 |
| 使命估量 | 在冲刺方案期间，决议从产品待办列表中提取多少活动并添加到冲刺待办列表中。例如，假如冲刺是两周，那么选择活动的数量，使它们能够在冲刺内完结，即在两周内完结。 | 它不估量使命。 |
| Scrum Master | 在 Scrum 办法论中，咱们有一名 Scrum 主管担任办理团队并每天主持会议。 | 在看板办法论中，咱们没有任何 Scrum Master。交给有价值的产品是每个人的职责。 |
| 适用性 | 这种办法适用于大型项目，因为大型项目能够分为多个冲刺。 | 首要适用于小型项目。 |
| 不断改动 | 在 Scrum 中，能够在较短的冲刺中轻松习惯不断的改动。 | 假如发生任何重大改动，那么看板办法就会失败。 |
| 本钱 | 在 Scrum 中，使命是估量的，即在一个 sprint 中进行固定数量的活动，因而项意图总本钱最小。 | 在看板中，没有估算使命，因而项意图总本钱不准确。 |
| 人物和职责 | 在 Scrum 中，Scrum Master 为团队成员分配了特定的人物，而产品担任人则告诉团队成员必须作业的产品方针。 | 没有为团队成员分配预界说的人物。一切团队成员都有职责协作交给有价值的产品。 |
| 出产力衡量 | 出产力是经过运用周期时刻或完结整个项目从开端到完毕所花费的时刻来衡量的。 | 出产力是经过冲刺速度来衡量的。 |
| 发布办法 | 每个冲刺完毕后的小版别。 | 它供给继续交给。 |
差异一：施行进程中重视中心的差异
Scrum施行的中心能够概括为“化繁为简”，从几个维度解释下：
- 团队人物的界说，将团队人员界说为三个人物，Scrum Master（首要担任消除妨碍，带领团队运作）、Product Owner（首要担任描绘产品远景，界说优先级）、Scrum Team（首要担任完结产品）
- 作业使命的拆分，将产品需求拆分红小的用户故事，并评价优先级
- 时刻的拆分，将项目周期拆分红固定时长的迭代周期，每个迭代交给一部分可检验的功用，一般迭代长度为1到4周
Kanban办法在施行的进程中更多重视的是可视化的价值活动，从几个维度解释下：
- 拉动式出产，下流作业完结后，主动拉动上游的使命移动
- 约束WIP（work in progress），明确设定约束每个状况下，同一时刻内有多少作业量，削减同一状况同一时刻内，使命和价值的堆积
- 可视化的价值活动一般是端到端的活动，直观的反映用户的价值（一般是可交给的用户需求），而且反映出在价值活动进程中的瓶颈和问题，不断为团队改善供给依据
差异二：约束WIP数量的办法不同
Scrum与Kanban办法都会约束在制品数量，不过约束办法有所不同，
- Kanban办法约束的愈加直接，同一状况同一时刻内的作业使命有最大约束；
- Scrum是直接性的经过迭代（sprint）来约束。约束WIP的中心意图是加快交给用户需求的价值活动。
差异三：对使命改动办理的不同
在Kanban办法的中，下流使命完结后（有显式化的拖动规矩），即可拉动上游使命下移，同时，只需出产力允许，即可新增需求。
在Scrum办法下，当每个迭代的sprint Backlog承认后，当时迭代是不允许新增需求的，新添加的需求能够表现在下个迭代的sprint backlog中。
差异四：改善依据的不同
- Scrum是以出产率作为方案和改善的依据，以迭代（sprint）数据作为依据，剖析迭代的相关数据（包含出产率、完结率等）；
- Kanban办法是运用出产周期作为方案和进程改善的依据。
Scrum和Kanban办法作为即灵敏又精益的典型代表，除了上述不同外，还存在许多相同点：
- 二者都和灵敏与精益相对应。灵敏中的继续改善思维在Scrum和Kanban都有所表现，而且是很中心的一个内容；精益中的拉动式出产在Scrum和Kanban中也都别离覆盖，Kanban办法表现的愈加直接，下流直接拉动上游的作业使命。
- 二者都重视尽早的交给价值，尽或许频频的发布可运用的软件。Scrum将整个项目周期拆分红多个迭代，每个迭代发布可检验的软件；Kanban办法在每个功用开发测验完结后就能够进行部署和发布。
- 团队状况都直观的反应在Scrum board和Kanban Board上，便利找到问题和瓶颈，并进行改善。
事例
**比较了Scrum与Kanban办法之后，怎么结合二者在团队中进行项目办理实践呢？这儿供给一个事例，**从迭代、版别、改动、改善四个方面来介绍
**迭代：**在Kanban办法中，并未规则明确的迭代，而在Scrum中是规则了固定的迭代周期。在咱们的团队中，迭代周期从一月一迭代，逐渐变为一月两迭代，到现在的两个天然周一个迭代，彻底固化了迭代周期的概念。
将杂乱开发周期很长的开发使命，分解成多个迭代周期，每个迭代周期交给一些可检验的软件或许功用。有利于削减危险，并更好的习惯改动，及时的依据反应调整作业方针。
**版别：**在迭代中，咱们以排入版别方案的功用点（story）作为作业重点，排入版别的story为交互现已完结的功用点（story），这些功用点能够直接进入开发和测验环节。这些story便是咱们当时迭代能够交给的功用或许软件。与此同时，产品、交互和视觉同学会继续拉取需求池中的功用点，开端进行规划，准备下个迭代版别中的内容。使整个价值活动愈加顺利。
**改动：**对待改动，咱们相同有自己的一套流程规范，既没有像Kanban办法相同，只需出产力允许，便能够新增需求；也没有像Scrum相同，版别内容确认，当时迭代根本不允许改动。
在实践进程中，当存在紧急需求，由产品司理发起，和各个人物进行评价危险和对现有版别的影响，并采纳相应办法下降因为需求改动对整个体系发生的影响，最终由项目司理发出改动告诉的邮件。
**改善：**咱们改善的依据之一是团队数据，因为咱们一切的使命都是经过JIRA进行办理，能够便利的拿个团队各种数据，包含：总作业量、总完结作业量、完结率、有用作业量、有用作业率、bug数、bug率等，对这些数据进行剖析，发现团队的问题，协助团队进行改善。
