迭代开发还是流开发（一）：迭代开发遇到的困难

迭代开发还是流开发（一）：迭代开发遇到的困难
基于Scrum的迭代开发已经很多年，很多团队会在2周一个迭代的周期频率下不断交付，基于跨职能的团队，同时迭代中不允许有变化的需求。但是有一些场景让这种迭代很困难，例如：
1) 紧急的技术支持
2) 临时增加的非常高的优先级的需求
3) 需求的批量小，导致无法2~4周一个迭代稳定发布
4) 估算非常难，导致不容易承诺，例如不清楚原因的bug修改，需要技术预研的任务，越来越庞大的系统导致事先未曾考量的任务出现的几率越来越大
5) 一些专家只对自己的技能擅长，导致计划扑克等团队估算形同虚设，同时他们在迭代中的任务很可能不饱满或者超值（他不能帮助其他人同时其他人也无法帮助他）
6) 由于大量增加和变化的需求，导致燃尽图对PO和团队已经没有意义
7) 市场的需要，2周的周期，太长了

对于以上的问题，我们可以有一些办法在Scrum中解决，例如：
#1：故事驱动开发
#2：多一些Buffer
#3：专家在任务不饱满的情况下继续以后迭代中可能会完成的与自己技能相关的任务，虽然这些任务不确定是否以后的迭代中需要
#4：…..

但是否有另一种开发方式可以比较好的适应这些场景，例如流开发？后续我们会讨论流开发以及“迭代和流”开发的可能结合方式。