Scrum和Kanban要如何选择
摘要：如果你的团队是产品导向型的，推荐使用Scrum；如果是研究导向型的，比如性能优化、编码优化等不确定性非常大的，推荐使用Kanban。其最核心的原则是结合实际情况在二者之间选择。
详细解答：
Scrum和Kanban两者都作为符合精益思想和敏捷的思考结果，他们之间必然会有一些相似点：
1、两者都限制开发中工作数目
2、两者都是通过透明度来驱动过程改进
3、两者都提倡提及时且稳定的交付价值
4、两者都基于自组织型团队
5、两者都要求把工作细分
6、两者都是基于经验数据持续优化
再来看看两者之间的一些区别：
下面结合实例来演示Scrum和Kanban这两种方法。
Scrum
在标准的Scrum流程定义中，有两个关键的产物：Product Backlog和Sprint Backlog，以及四个关键的会议：计划会议、每日立会、评审会议和回顾会议。
我们把Product Backlog分为需求和缺陷，其中需求部分使用Epic-Feature-User Story三级体系来表示。
Epic：史诗，表示比较大的特性，开发周期一般是1-3月，用于产品路线图的规划。Feature：特性，表示相对小一些的特性，开发周期一般是1-3周，用于产品版本的规划。User Story：用户故事，表示最小的用户场景，开发周期一般是1-3天，用于迭代规划。
在每个迭代开始时会召开计划会议，全员都会参加，这个会议最重要的事情就是确定Sprint Backlog，由Product Owner按照优先级介绍Product Backlog，然后团队决定是否把某一个条目放入当前迭代。
迭代进行的时间内，每天都会有10-15分钟的站立会议，团队中每个成员基于迭代任务板介绍前一个工作日所做的事情，以及遇到的问题。
迭代结束时召开评审会议，在评审会议上每个人基于产品演示自己在这个迭代中所完成的成果，团队成员可以针对完成的事项提一些建议。在评审会议结束后，团队成员会一起召开迭代回顾会，回顾会是Scrum迭代实践中的最后一环，也是最重要的一环，迭代回顾会将整个迭代形成了闭环。回顾会上大家提出的问题通过迭代回顾面板记录。
在Scrum实践中，大部分团队都会忽视版本管理，迭代是针对Scrum团队的活动行为，而版本管理是针对产品的，它定义的是一个批量的概念，用于版本进度管理和交付风险管理，明确在一个版本中的最终交付物，你可以创建版本并把它与迭代关联，或者只是单纯的设置某个用户故事/缺陷属于某个版本
Kanban
对于一个团队采用Kanban方法来管理是否能够成功，取决于使用Kanban后能否为你的团队带来以下几点改进：
1、帮助团队可视化整个链条的价值流动
2、帮助团队识别价值流动中的风险点
3、帮助团队度量价值流动中的各种浪费，并加以消除
因地制宜
讲完了Scrum和Kanban的基础知识，以及我们对于Scrum和Kanban的支持，来看看在实际团队落地时，如何结合实际情况在二者之间选择。
1、如果你的团队是产品导向型的，推荐使用Scrum；如果是研究导向型的，比如性能优化、编码优化等不确定性非常大的，推荐使用Kanban。
2、团队规模适中，5-9人左右，并且有跨功能团队成员，推荐使用Scrum；相反如果你的团队规模比较小，只有2-5人左右，推荐使用Kanban，相对效率较高。
3、产品或者项目交付是按照一定的周期来计算，比如每2周或每个月要求有一个新的版本，推荐使用Scrum；如果产品或者项目的交付不是按周期来计算，而是按照某个特定的事件为标志，比如性能提升了10%发布一个新版，推荐使用Kanban。
当然这些只不过是一点经验之谈，具体还要看团队的实际情况，因地制宜，来推动敏捷在团队的真正落地，而不是流于形式。
