唐僧、QA MM与工作流任务数据模式
唐僧与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能够和平相处，而有些团队却势如水火。
?
那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。
?
描述
任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。
?
