问团队专注于任务，而不是用户故事。

EN

我有个好消息要告诉你:你确实有一个跨职能的团队！Scrum指南将跨功能团队定义为：

跨职能团队拥有完成工作所需的所有能力，而不依赖于不属于团队的其他人。

不要误解我的意思，重叠的技能对团队的发展是有帮助的，但是你有你需要开始的东西。像你这样的团队一直在传递商业价值。

你可能面临的挑战之一是，人们似乎在根据完成任务来衡量自己的成功。团队是否在评审中共享他们完成的用户故事？他们是否被要求解释为什么他们能够完成一半的待办事项，但不能完成一个？

我看到PO使用的一种技术是只向sprint添加一个项。当项目完成后，它们会添加另一个项目。PO对开发时间和速度的使用效率低下承担责任。这就强调，他们看重的是交付的价值，而不是忙碌。

WIP限制是另一种结构上的方式来加强同样的事情。冲刺目标也是如此。

听起来，团队所领导的只是与成功的样子相一致。

当你有一个用户故事时，有人抓住它，说“我可以实现那个用户故事并在一个合理的时间框架内交付它”，或者那个人说“那个用户故事是一大块令人不舒服的工作，所以我需要完成任务A、B和C，然后我可以实现用户故事”。

不管是谁抓住了用户故事，都要负责实现它。所以这个人应该创建子任务。这些子任务应该以足够的精确性来描述，这样所有的子任务都可以按照规格实现，用户故事就可以实现了。(故事要点应该分开。如果需要三个子任务，那么原始用户故事显然应该有相当多的故事点)。

如果您实现了子任务，然后无法实现用户故事，那么要么子任务没有提供用户故事所需的内容，要么它们没有得到足够好的配置。可能是由委员会设计子任务，由对任务本身感兴趣的人来设计，而不是对用户故事感兴趣；如果有人有很强的动机来正确处理子任务，而该人设计子任务，那么你会得到更好的结果，而这个人将负责整个用户故事。

更重要的是，子任务在QA接受时不像往常那样被计算为“交付”，而是当负责用户故事的人接受它们时。