我刚开始进入敏捷，是接触的Scrum。在某一次伟忠的分享里，看到了Kanban方法。后来又荣幸的参加了两次建昊老师的专门课，一次讲述的是Scrum，一次讲述Kanban，算是对这两个敏捷的主要方法论有了比较深入的了解。
今天被一个朋友启发，了解了一下scrumban的方法论，一时兴起来翻译一篇文章，来介绍一下。原文在这里:
https://www.smartsheet.com/scrumban-choosing-middle-ground-between-scrum-and-kanban
本文着力与从我的角度理解，而非100%翻译，若有需要请查看原文。
Scrum的优势：
改善排期：在原有复杂系统里，需求及其复杂，很难被排期。Scrum可以
减少错误影响：发现的错误会在下次被改正或重做
增强沟通-每日站会保证状态被实时同步，开发状态可以在任务板上随时查看
增强效率-每日站会增强了团队沟通效率
建立更好的客户关系-迭代规划有助于尽快向客户展示产品设计，并迅速获得反馈。客户可以感受到他的反馈对产品的改善
改善软件-变更不是打断，而是提升软件的价值
劣势：
范围蔓延-利益相关者倾向于增加越来越多的功能
无法应对大团队-Scrum比较适用于小团队
要求团队必须具备相关经验-成功运行Scrum 需要团队成员可以预估开发时间
不太适合“微观管理者”
交接可能变得麻烦-小的团队规模和短开发周期可能比较费劲
质量保证比较困难
Kanban优势：
改善资源分配-由于WIP限制，新工作只有在资源可用的情况下被拉入开发进程
简化项目管理-看板提供了极佳的可视化功能，简化了项目管理流程
减少打扰-需求变更不会影响太大，因为我们一直处于处理和改进流程中
更好的决策-工作流可视化有助于方便的了解工作处理流程，在变动时做决策更加容易
看板的劣势：
看板必须是正确的-看板必须实时更新，不更新的看板会出现巨大的问题。看板依赖团队成员的实时更新，如果没有每日站会的实践，实时更新会很难
维护一个看板稍显复杂-尤其是太多东西在看板上的时候，可能会引发混乱
缺少截止日期-没有开发截止时间，团队会落后于预期
Scrumban方法论
Scrumban方法论是由软件开发爱好者Corey Ladas在他的书《Scrumban: Essays on Kanban Systems for Lean Software Development》中提出的概念。他认为Scrumban是为了让开发团队从Scrum迁移到精益（依靠创建，界定，学习周期，持续改进和专注与提供给客户的最终价值）。Scrumban设计于替代Scrum，它的方法论包含了Scrum和看板的基础元素。是否替代Scrum或K俺班为Scrumban，取决于环境和组织的需要。
Scrumban方法论通常用于开发和维护项目。正常实践中，开发和维护项目需要很多同样的技能。
Scrum和Scrumban方法论的比较：
Scrumban的适用范围：
项目有极大的可能会变更或者重新排优先级
你希望在scrum开发过程中加功能
由于很多的问题，或者由于资源不足，无法准时交付；
工作是有事件驱动的，比如技术支持等优先级持续改变的项目；
团队致力于增加功能以支持现有产品；
Scrum已经在开发团队使用，但是你希望能引入某些看板原则；
你发现了scrum有些问题已经限制了团队的变更可能性；
你已经在kanban转型中，但是需要一些方法论的小改动以限制中断。
