测试状态机客户

Scrum中的讨论要用什么语言？

同一件事，状态机描述大家都没有意见，流程图发出却引起了一场风暴。这是怎么回事？...

前一阵子，在我们的某个scrum项目中发生了一件有趣的事情。由于测试人员前期在忙着前面的测试，开发人员先就某个功能做了一些设计。背景是客户在澳大利亚，产品经理在美国，美国还有一个合作的团队。产品经理并没有把客户的需求描述的非常详细，只是大概描述了一个场景。开发人员开始做设计，并将它们设计的状态机图发出来给整个scrum做评审。结果没有人有comments。看上去很美好的一个结果。

等测试人员开始审视这个功能时，发现有很多不清楚的地方。从状态机看不出什么，但是一讨论就有很多问题。测试人员干脆舍弃了状态机，从用户的角度画了个流程图。

这个流程图一经发出却引来了一场风暴。了不得了，第二天就收到了美国人无数条comments，一场激烈的讨论开始爆发了。虽然我们的理解和开发的理解完全一样，但是不同的表达方式产生了完全不一样的效果。大家突然就意识到其实我们的理解有很多的偏差，甚至以前美国团队和产品经理都没有想清楚客户的需求是什么。依据这个流程图，大家开始整理自己的思路，整理客户的需求，最后产品经理还把这个流程图拿给客户去确认需求。

相信类似的事情在你的团队中也时有发生。通常一个用户故事中讨论的时候，Team中很多人都已经忘记了它是个用户故事，开发人员立马就反映出要如何构建，测试人员立马反映出要做什么测试。导致在grooming的阶段大家各说各的，无法互相理解。最后真正的问题并没有讨论清楚。

PO应该是最适合的角色让大家都站在同一个角度来讨论，但是有时候PO不是那么得力时，测试人员就当之无愧的承担这个角色。因为他更接近客户的语言，只有用客户的语言来描述需求，大家才能把真正的问题暴露出来并解决掉。