是时候引入一些Kanban的实践了
先介绍下背景，我所在部门负责公司一个产品的开发工作，其在上海有2个正在使用scrum框架的团队，其中一个主要做大规模的新功能的开发，另一个，也就是我所在的团队，主要关注小的改进和缺陷修复，特别是一些紧急的需求和bug。
(对像这样长期区分团队职责的方式，个人有些不同的想法，但这并不在我现在的影响范围，也不是这次我们关注的范围。)
一段时间来，我们经常发生这样的情况：在产品签单或上线过程中会提过来一些很急的需要或BUG，甚至需要在一、两周内就要放出的新功能或hotfix。这种情况出现后，迫于压力，PO和SM只好告知大家现在的情况，然后团队被迫修改iteration backlog，该加进来的加进来，该挪走的挪走。另外，这种频率越来越高的变化不光让团队疲于调整计划，更让团队在潜意识中对planning meeting中的预估都趋向于保守，这就让少数没有紧急工作的sprint又过于轻松，也就是团队工作的张弛幅度过大。
基于这样的情况，越来越感觉Scrum框架不适合我们团队的现状。
回想以前看过的Henrik Kniberg关于Kanban的精彩分享，为什么不试一下那？
几周前，试着和团队解释Kanban和其使用方法，得到大家同意后，我们开始试着引入一些Kanban的实践来替代Scrum框架安排我们的工作计划。
经过头两周的尝试，大家在回顾中一致认为在吸取了一部分Kanban的实践后，团队更加适应现在的情况：
- 用Kanban替代原有的迭代计划后，团队应对频繁变化的能力让人满意；
- Kanban对WIP数量的限制让团队更关注缩短单个Story的开发周期，并且每个人都试着随时push工作的进行；
- 对WIP的限制很容易暴露出团队中配置的缺陷；
- 舍弃了之前相对保守的计划，大家一个接一个的放手去做，让团队产出增加了；
- PO尽量让story不超过MMF(minimum marketable feature)，让story普遍瘦身了许多（额外的收获）；
同样，团队也遇到了一些新问题，现在来看最经常碰到的是：有时Limited WIP会让团队工作停滞下来。
在我们的团队，有多种原因都引发过这个问题，比如说有限的资源让我们团队配置并不很理想、连续几个实现和验收工作量很不平衡的工作、队员请假。为此我们也专门讨论过一些应对的方案，如设置backup、next list的预选取等，是否有效还要看后面实际工作情况。
