整体上来说，可能会的。下一步怎么解决？使用Scrum框架，要明白Sprint的含义，冲刺。所以要组成全职能团队，冲着共同目标前进，而不是用传统的职能团队管理方式。所以想要达到理想的效果，还是应该让团队专注一个项目。从公司角度来说，应该展示出Scrum团队单个带来的好处，然后根据公司的业务、体制，和领导沟通，将Scrum推广到整个公司。这样就不会出现文中提到的单独团队影响整体的效率了。

欢迎大家讨论交流~

不建议放到计划会议上，原因如下梳理会议上讨论出的需求设计，在碰撞出新思想之后，产品负责人可以重新好好设计下。梳理会议上会发现一些需求的依赖，需要在迭代之前解决，可以在梳理会议后去解决，然后再召开新的梳理会议去继续讨论。如果在计划会议上发现这种拦路虎的话，那么计划会议无法进行下去了。需求梳理之前，只能预估需要的时间，所以花费的时间不确定，有可能比较长。放在上一个迭代中开的话，一次讨论不完，可以再召开一次。如果放在计划会议上开的话，会导致计划会议时间太长，后面还要做任务认领，团队会很疲惫。梳理会议上澄清完需求的话，在上一个迭代的末期及下一个迭代计划会议之前，团队也都大概知道接下来会有什么需求，会有时间去思考一下。如果只在计划会议上澄清的话，在下一个迭代的计划会议之前，团队会迷茫。最后，梳理会议的时间点，可以设置在上一个迭代的中后期，比如两周的迭代的话，可以放在第二周周三左右，其他的迭代周期可以参考。虽然Scrum Guide上没有说明梳理会议，但是LeSS框架下有明确的梳理会议及大致的时间点，我觉得比较合理。

不建议Scrum Master同时承担团队内的开发测试等工作。因为身在其中，工作有了交集，则不好做出指导，给出意见。对于一个5-9人团队的Scrum Master来说，有时确实工作不够饱和，常见的做法是一个Scrum Master对应两个团队。对于很多小公司来说，就一个团队，5-7人，这是很常见的，这种情况下公司很难说专门有一个人只负责Scrum Master的工作，这时我们推荐兼职做Scrum Master的人尽量不是做开发、测试的，比如她是一个做UI设计的。当然了，这是在迫不得已的情况下的选择。

赞同黄药师的观点，依然要开评审会议。节奏是很重要的，每个迭代固定时间做的固定的事情要坚持。我认为敏捷里很重要的一个就是自检，评审会议不仅是给客户演示，也是团队一起分享该迭代的劳动成果，所以无论结果怎样，我们仍需要这一仪式来一起分享，审视。