唐僧与
QA MM
在一个典型的项目团队里，包括了以下几种角色（帽子）：
PM（项目经理）、
BA（业务分析师）、
DEV（程序开发者）和
QA（质量保证人员），整个团队的目标是向客户交付价值。
那么，有一天，
QA MM来找我，我是开发人员。
MM说，一张图片没有正常显示，我想知道原因，同时想知道你能否修复。我的第一想法是，这不可能，一定是环境的原因。我说，好的，稍等。接下来，我张大嘴巴看到了
MM给我重现的
BUG：本该显示图片的位置一片空白，就像此时我合不上的嘴。这怎么可能呢？我想，这个功能完成的如此之得意，以至于测试用例里的数据都是以我的名字命名的。
几分钟后，或者更长，我叫来
MM，说，找到原因了。
我打开编辑器，光标在源程序的某一行闪烁，我说，最根本的原因在这里。我看到
MM的眼中闪过一丝迷茫。接下来，我却换到另外一个源文件，光标继续闪烁，我说，这里的程序因此受到影响。看得出，
MM有点发晕。终于，当我打开第
N个源文件并试图继续讲解时，
MM昏过去了。
当
MM苏醒过来时，我在她清澈的双眼中看到了一只清晰的唐僧。
MM肯定感到了不好意思，因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识，看得出，我很努力，我的语文老师也很努力，所以她委婉地说，能不能简单一点？
我想了想，说，测试驱动时测试数据不全导致程序少考虑一种情况。
MM说，能修复吗？
我说，可以。于是故事结束。
就
是这样，当我们执行一项任务时，围绕这项任务必然会产生许许多多的信息，这些信息对于该任务的执行者是必须的，但是对于其他人则不是，有效的沟通往往来自
于简练的表达即只表达对方需要和可以理解的内容，浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思：我之所以用这么多的细节信息来淹没
QA，实际上是不太情愿承认程序里有
BUG。
QA想要的结果很简单，是否是程序
BUG，能否修复。而开发人员则往往把自己的程序与自己关联在了一起，认为程序是自己的扩展，程序有
BUG则意味着自己有缺陷。这一关系明显是矛盾的，可是一些团队里开发人员和
QA能够和平相处，而有些团队却势如水火。
那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。
描述
任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。
图
6-2任务级别的数据可见性
如图
6-2所示，我们在任务
B上定义了一个变量
M，此时，在一个流程实例里，只有任务
B的实例才能使用该变量。
实现
存在两种实现方式，一种是如图
6-1所示的，在任务节点定义中声明变量，运行期初始化任务实例的同时初始化该变量并使用；
另一种是在流程定义级别统一声明变量，但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见，例如各个任务实例都会有参与者，我们在流程定义时声明一个名为
userid的变量，在流程实际执行时，各个任务实例都会独自保存有自己的
userid数据。