用户故事、开发任务与工作流块任务数据模式

在开发人员的日常工作中，编码工作主要包括了三种类型：用户故事（用户故事）、开发任务（ Task）和缺陷（ Defect）。尽管不喜欢缺陷，但是它是你生活的一部分，并且大部分的缺陷都与沟通相关，在这些缺陷中，团队成员对功能的假设产生了偏差。

 

一 个用户故事可以拆分为多个开发任务。一个常见的问题是：如何区别用户故事和开发任务？我们用海平面来进行区分，海平面即用户价值。项目目标是那高高的风 筝，它高高的飘扬，越过云彩，它是项目帮客户实现的商业目标，飘那么高，让客户瞅一眼就觉得激动万分；项目特性是那半空中的云彩，客户从风筝上下来，看到 的是项目所提供的大的特性，这些特性帮助客户实现其商业目标；接下来就是用户故事，是的，现在终于落地（海）了，用户故事是海上的点点小岛，它一半露在海 平面以上，另一半没在海平面下，客户看到的是海平面以上的东西，所以用户故事一定要包含用户价值，开发人员看到海平面以下的东西，所以用户故事一定要是可 评估的、可开发的，因为存在两种不同的角度看用户故事，所以用户故事一定要是可沟通的，围绕着海岛总是有很多的话题，例如，项目经理经常就会与客户就海岛 展开磋商，项目经理通常会说，时间来不及了，我们需要找出最有价值的海岛进行开发。而客户通常会说，不行啊，看人家海南岛，仅仅一个规划就把房价炒得那么 高，所有的海岛都要开发；开发任务则是海底的贝壳、扇类，它们是那样的美丽，以至于只有开发人员才能了解，当一个用户故事过大难以评估时，我们往往将它拆 分为多个开发任务，这些开发任务单独并不能为客户提供价值，只有当多个开发任务联合起来时才能显示价值，典型的，探索性技术开发都属于开发任务。是的，那 么结论是？

 

开发人员都是潜水员！所以，怪不得那么多技术社区冷冷清清，如果你不提供内容，就别指望其他人为你提供内容。

 

这样，当进行开发任务时，这些开发任务就与与之对应的用户故事构成了一个完整的对客户可见的价值域，作为开发人员，必须理解相应用户故事要解决的问题和验收条件，这些信息贯穿于所有开发任务的开发中，为用户故事和开发任务们所共享。

 

那么，对于工作流里的块任务，它需要能够定义变量，这些变量数据能够在其子任务中共享。

 

描述

块任务（典型的如子流程任务）能够定义变量，在一个流程实例里，其所包含的子任务实例能够使用该变量。

 

图 6-3块任务级别的数据可见性

如图 6-3所示，我们在块任务 C上定义了一个变量 M，此时，在一个流程实例里，与其对应子流程中的任务 X、任务 Y和任务 Z的实例在运行期都可以使用该变量。相似的，我们可以在子流程中定义了一个变量 N，那么子流程中的所有任务实例都可以使用该变量，根据不同的工作流系统实现， N也可以被块任务 C的实例所使用。

 

为什么需要块任务？

 

良 好的代码需要封装，需要职责分离，业务流程建模同样如此。在一个定义良好的流程里，相互连接且语义相关的任务往往被建模为子流程。例如，一个跨越多个部门 的复杂业务流程，一种比较好的方式是针对每个部门都建立起自己的子流程。从维护的角度看，这种建模清晰自然，各个部门也能自己维护自己的流程建模。由于任 务执行的上下文存在差异，那么针对各个子流程建立自己的执行环境就非常必要，在工作流系统里，这种执行环境的表现即为数据。

 

实现

为 保证子流程定义的复用和独立性，一般不直接在与之对应的块任务里定义其要使用的变量，采用的方式是在块任务定义里进行数据映射，即将块任务中的变量与子流 程中的变量进行一一映射，运行期父流程实例中的变量传值到子流程中的对应变量中，子流程实例执行完毕再将值传回。具体的实现将在下一节的交互模式里进行详 细说明。